Personal tools
You are here: Home Solution Areas Application MyMeeting Acctune MyMeeting Documentation Managing Permissions

Managing Permissions

by abdullah last modified Jan 15, 2010 06:02 PM

How to manage what the users of MyMeeting can do in the system depending on their roles and groups.

Permissions in MyMeeting is how the administrator is able to control who can do what in the committee. Permissions are actually based on tables of the database of MyMeeting because each table represents different parts of the committee. In the interface the tables are represented as Models. The models available are:

  1. Committee
  2. Committee Todo
  3. Group
  4. Users
  5. Workflow
  6. Model Workflow
  7. Project
  8. Announcement
  9. Template
  10. Meeting
  11. Attendance
  12. Meeting Todo
  13. Decision
  14. User Status
  15. Group Status


And the list of permissions that can be granted is:

  1. Create
  2. View
  3. Edit
  4. Delete
  5. Approve
  6. Disapprove


So if a user has been granted the permission to View the Attendance model but not Create or Edit or Delete it then that user will only be able to view the Attendance available in that committee but would not be able to do any other thing like edit, delete or add new Attendance. The permission can be given using a few criteria which are:

  1. All : everyone who is registered in that committee
  2. Owner : the user who owns that particular item in the table. For example Owner of 'User Status' would be the user who have to update his status on a certain decision
  3. Invited : users who was invited to that particular meeting. So some committee might like that the meeting details (decisions, status, comments) can only be viewed by users who was actually involved in that meeting only so the administrator would be able to restrict their access using this rule
  4. Attended : this is like above except it is even more strict (ie only users who actually attended the meeting will be given permission)
  5. Role:<user role> : grant permission if the user has this particular role in the committee
  6. Group:<user group> : grant permission if the users belongs to this particular group in the committee


As an examples take the default permission for 'User Status' in MyMeeting. The permission is given as thus:

  • create = role:admin,owner
  • view = all
  • edit = role:admin,owner
  • delete = role:admin
  • approve
  • disapprove


So according to the permission given above, only users who have the role of admin (usually the administrators) and owners (the person who was assigned in the decision) can create and edit the user status in that committee. Everyone in that committee can see the status (view = all) and only the administrator can delete the status (delete = role:admin) , although actually in MyMeeting there is no way to delete a user status once it has been submitted. The approve and disapprove permissions has not been implemented in any way in MyMeeting for now.


Permission given is read from left to right and would be applied to the first rule found relevant to the user. For example if a permission was written like this:


then the steps the system would take would be:

  1. Check whether the users is in the managers group. If the users is in the managers group then the user would be granted permission for that action. If not then on to the second step.
  2. Check whether the user in in the marketing group. If the user is in the marketing group then the user would be denied permission (the exclamation mark negates the permission) for that particular action. If not then on to the third step.
  3. All users who was not granted or denied permission by step 1 and 2 are granted permission

So in other words the rule above would grant permission to anyone who is a manager or that person is not from marketing.


Document Actions