Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

In MyAEGEE, the permissions system is used. Main concepts:

...

Permission nameDescription
global:create:bodyCreate new bodies.
global:delete:bodyDelete a body.
global:delete_member:bodyDelete 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.
local:delete_member:bodyDelete membership status from members in the body that you got this permission from.
global:update:bodyUpdate any body, even those that you are not member of. Try to use the local permission instead
local:update:bodyUpdate 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.
global:update_member:bodyChange the data attached to a body membership in any body in the system. This data currently is a comment only.
local:update_member:bodyChange the data attached to a body membership in the body you got this permission from
global:view:bodyView body details, like name and address etc, excluding the members list and other internals. Is assigned to every user in the system.
global:view_members:bodyView 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
local:view_members:bodyView the members in the body that you got that permission from
global:create:bound_circleCreating bound circles in any body of the system, even those you are not member in
local:create:bound_circleCreating bound circles to the body the permission was granted in
local:put_parent:bound_circleAssign 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
global:create:campaignCreate recruitment campaigns through which users can sign into the system.
local:create:campaignCreate a bound campaign. You must hold this permission in the local that you want to bind this campaign to.
global:delete:campaignDelete a recruitment campaign
local:delete:campaignDelete a recruitment campaign which is bound to the body that you got this permission from
global:update:campaignEdit recruitment campaigns
local:update:campaignUpdate a campaign in the body which you got this permission from.
global:view:campaignView all campaigns in the system, no matter if active or not.
local:view:campaignView recruitment campaigns attached to a body
global:add_member:circleAdd 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
local:add_member:circleAdd 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
global:delete:circleDelete 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
global:delete_members:circleDelete 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
local:delete_members:circleDelete 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
global:join:circleAllows to join circles which are joinable. Non-joinable circles can never be joined
local:join:circleAllows you to join joinable circles in the body where you got the permission from
global:put_child:circleAdd any orphan circle in the system as a child to any circle you are circle admin in.
global:put_parent:circleAssign 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
global:put_permissions:circleAssign 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
global:update:circleUpdate 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
global:update_members:circleUpdate 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
local:update_members:circleUpdate 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
global:view:circleList and view the details of any circle, excluding members data
global:view_members:circleView 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
local:view_members:circleView members of any circle in the body that you got this permission from
global:create:free_circleCreate free circles
global:create:join_requestAllows users to request joining a body. Without these permissions the joining body process would be disabled
global:process:join_requestProcess join requests in any body of the system, even those that you are not affiliated with.
local:process:join_requestProcess join requests in the body that you got the permission from
global:view:join_requestView join requests to any body in the system. This could disclose a bigger portion of the members database and thus should be assigned carefully
local:view:join_requestView join request to the body you got this permission from
global:create:memberCreate members to any body of the system, even those you are not member or board in
local:create:memberCreates a member to the local that this permission was granted in
global:update:memberUpdate any member in the system. Don't assign this as any member can update his own profile anyways.
local:update:memberUpdate 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.
global:view:memberView all members in the system. Assign this role to trusted persons only to avoid disclosure. For local scope, use view_members:body
join_request:view:memberAllows you to see the member profile of people who are applying to the body you got this permission from.
local:view:memberView 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
local:create:paymentCreate payments in the body you've got this permission from.
local:view:paymentView payments for the body you've got this permission from.
global:create:permissionCreate new permission objects which haven't been in the system yet, usually only good for microservices
global:delete:permissionDelete a permission, should generally happen very rarely as it could break the system
global:update:permissionChange permissions, should generally happen very rarely as it could break the system
global:view:permissionView permissions available in the system
global:delete:userRemove an account from the system. Don't assign this as any member can delete his own account anyways.
local:delete:userDelete 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
global:update_active:userAllows to suspend or activate any user in the system
local:update_active:userAllows to suspend or activate users that are member in the body that you got this permission from

...

Permission name (scope:action:objectDescription
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).

...

Permission name (scope:action:objectDescription
global:manage:discountsCreate, edit and delete integrations, add codes to the integrations, create/edit/delete categories (the ones on /discounts).

alastair

Permission nameDescription
global:use:alastairGeneral usage permission for alastair, but with restrictions. WIth this you can manage your own events, shops, and recipes
global:administer:alastairHave full access to all alastair functions, including editing ingredients, other peoples recipes, etc