Permissions list for the system
In MyAEGEE, the permissions system is used. Main concepts:
each permission has the scope. It can be on of three: global (applies to every body), local (applies only to the body you've got this permission from) and join_request.
each permission has the action (which defines the action that can be done) and the object (what object this action can be done on)
permissions can be attached to circles, if the person is a member of the circle, he has this permission
if a circle is attached to a body, and the permission's scope is local, a user only can do action on this body, not on the others
circles can be inherited, e.g. if there's a circle, and it has a parent circle, then it inherits all its permissions
List of the permissions in the system
oms-core-elixir
Permission name | Description |
|---|---|
Create new bodies. | |
Delete a body. | |
Delete the membership status of any member in any body. Try to not grant this permission to many people, there is a locally scoped version of it for board-members. | |
Delete membership status from members in the body that you got this permission from. | |
Update any body, even those that you are not member of. Try to use the local permission instead | |
Update details of the body that you got the permission from. This version currently is filtered, so you can not edit the name and legacy key with it. | |
Change the data attached to a body membership in any body in the system. This data currently is a comment only. | |
Change the data attached to a body membership in the body you got this permission from | |
View body details, like name and address etc, excluding the members list and other internals. Is assigned to every user in the system. | |
View the members of any body in the system. Be careful with assigning this permission as it means basically disclosing the complete members list to persons holding it | |
View the members in the body that you got that permission from | |
Creating bound circles in any body of the system, even those you are not member in | |
Creating bound circles to the body the permission was granted in | |
Assign a parent to a bound circle. This only allows to assign parents that are in the same body as the circle to migitate permission escalations where someone with this permission could assign his own circle to one with a lot of permissions | |
Create recruitment campaigns through which users can sign into the system. | |
Create a bound campaign. You must hold this permission in the local that you want to bind this campaign to. | |
Delete a recruitment campaign | |
Delete a recruitment campaign which is bound to the body that you got this permission from | |
Edit recruitment campaigns | |
Update a campaign in the body which you got this permission from. | |
View all campaigns in the system, no matter if active or not. | |
View recruitment campaigns attached to a body | |
Add anyone to any circle in the system, no matter if the circle is joinable or not but still respecting that bound circles can only hold members of the same body. This also allows to add yourself to any circle and thus can be used for a privilege escalation | |
Add any member of the body you got this permission from to any bound circle in that body, no matter if the circle is joinable or not or if the member wants that or not. This also allows to add yourself to any circle so only give it to people who anyways have many rights in the body | |
Delete any circle, even those that you are not in a circle_admin position in. Should only be assigned in case of an abandoned toplevel circle as circle_admins automatically get this permission | |
Delete any member from any free circle, even those that you are not in a circle_admin position in or even have member status. Should never be assigned as circle_admins automatically get this permission | |
Delete any member from any circle in the body that you got this permission from, even those that you are not in a circle_admin position in or even have member status. Should never be assigned as circle_admins automatically get this permission | |
Allows to join circles which are joinable. Non-joinable circles can never be joined | |
Allows you to join joinable circles in the body where you got the permission from | |
Add any orphan circle in the system as a child to any circle you are circle admin in. | |
Assign a parent to any circle. This permission should be granted only to trustworthy persons as it is possible to assign an own circle as child to a parent circle with a lot of permissions | |
Assign permission to any circle. This is effectively superadmin permission, as a user holding this can assign all permissions in the system to a circle where he is member in | |
Update any circle, even those that you are not in a circle_admin position in. Should only be assigned in case of an abandoned toplevel circle as circle_admins automatically get this permission | |
Update membership details of members of any circle, even those that you are not in a circle_admin position in or even have member status. Should never be assigned as circle_admins automatically get this permission | |
Update membership details of members of any circle in the body that you got this permission from, even those that you are not in a circle_admin position in or even have member status. Should never be assigned as circle_admins automatically get this permission | |
List and view the details of any circle, excluding members data | |
View members of any circle, even those you are not member of. Should only be given to very trusted people as this way big portions of the members database can be accessed directly | |
View members of any circle in the body that you got this permission from | |
Create free circles | |
Allows users to request joining a body. Without these permissions the joining body process would be disabled | |
Process join requests in any body of the system, even those that you are not affiliated with. | |
Process join requests in the body that you got the permission from | |
View join requests to any body in the system. This could disclose a bigger portion of the members database and thus should be assigned carefully | |
View join request to the body you got this permission from | |
Create members to any body of the system, even those you are not member or board in | |
Creates a member to the local that this permission was granted in | |
Update any member in the system. Don't assign this as any member can update his own profile anyways. | |
Update any member in the body you got this permission from. Notice that member information is global and several bodies might have the permission to access the same member. Also don't assign it when not necessary, the member can update his own profile anyways. | |
View all members in the system. Assign this role to trusted persons only to avoid disclosure. For local scope, use view_members:body | |
Allows you to see the member profile of people who are applying to the body you got this permission from. | |
View information about all members in the body. This does not allow you to perform a members listing, you might however hold the list:body_memberships permission to perform a members listing of the members in the body | |
Create payments in the body you've got this permission from. | |
View payments for the body you've got this permission from. | |
Create new permission objects which haven't been in the system yet, usually only good for microservices | |
Delete a permission, should generally happen very rarely as it could break the system | |
Change permissions, should generally happen very rarely as it could break the system | |
View permissions available in the system | |
Remove an account from the system. Don't assign this as any member can delete his own account anyways. | |
Delete any member in your body from the system. This allows to also delete members that are in other bodies and have a quarrel in that one body with the board admin, so be careful in granting this permission. The member can delete his own profile anyways | |
Allows to suspend or activate any user in the system | |
Allows to suspend or activate users that are member in the body that you got this permission from |
oms-statutory
Action is always one of the event types (agora/epm/spm).
Permission name (scope:action:object | Description |
|---|---|
global:manage_event:<event_type> | Create statutory events, edit them, manage pax limits for the event (e.g. how many envoys/delegates/etc. from each body can apply), publish/unpublish events, delete events. |
global:manage_applications:<event_type> | See all applications, mark them as accepted/rejected, confirmed/not confirmed, attended/not attended, registered/not registered, departed/not departed, see all of the listings, apply disregarding the deadline. |
global:apply:<event_type> | Apply to the statutory event disregarding its deadline. |
global:use_massmailer:<event_type> | Use massmailer for this type of statutory event. |
global:manage_incoming:<event_type> | See incoming listing of the applications with required fields, set confirmed/not confirmed and attended/not attended for the applications. |
global:manage_juridical:<event_type> | See JC listing, set registered/not registered, departed/not departed for applications (for calculating votes) |
global:update_memberslist_status:agora | See Network Director listing, mark people as present/not present on members list. |
global:approve_members:<event_type> | See all boardviews and set board comments/pax types for participants. |
local:approve_members:<event_type> | Same as above, but only for the body the user have got this permission from. |
global:set_memberslists_fee_paid:agora | Set how much fee the local paid for the member for the Agora. Useful for Financial Director. |
global:manage_candidates:agora | See all candidates (even rejected/pending), accept/reject candidates |
global:manage_plenaries:agora | Create, see, update and delete all plenaries for Agora. |
global:see_plenaries:agora | See all plenaries for Agora |
global:mark_attendance:agora | Mark people as attended/left for plenary. Should be combined with the permission above. Needed for people with badge scanners. |
global:manage_question_lines:<event_type> | Create and edit question lines, edit and delete others' questions. |
oms-events
Action is always one of the event types (nwm/rtc/es/local/other/wu/ltc).
Organizers of the event can add other organizers, edit event once it's not published, delete event once it's not published, see all of the applications and accept/reject participants.
Permission name (scope:action:object | Description |
|---|---|
global:approve_event:<event_type> | Publish events of this type. |
global:manage_event:<event_type> | Edit and event even after it's published |
local:approve_members:events | See boardview for all events for the body you've got this permissions from and all applications from it, write board comments. |
oms-discounts
Permission name (scope:action:object | Description |
|---|---|
global:manage:discounts | Create, edit and delete integrations, add codes to the integrations, create/edit/delete categories (the ones on /discounts). |
alastair
Permission name | Description |
|---|---|
General usage permission for alastair, but with restrictions. WIth this you can manage your own events, shops, and recipes | |
Have full access to all alastair functions, including editing ingredients, other peoples recipes, etc |