...
To see a list of permissions, visit https://oms.aegee.org/permissions, It is thinkable that new microservices can add a new set of permissions to the system to handle specific functions.
Permission contexts
There are different objects in the system that get permission differently, in total there are 4. They can be checked through the /my_permissions request on each of the objects.
- Global for general requests only the global permissions are regarded. For this the user gets assigned all auto-assigned permissions and all global permissions that he received through any circle membership. All other permission contexts take this as a basis
- Body for body-related requests additionally all local permissions that are aquired through membership in a bound circle of that very body are added to the permission list.
- Circle in case it is a bound circle, all body permissions the body that the circle is bound to are added. For free circles, nothing is added. Circle-admin status however brings some additional permissions.
- Member member-based request additionally get all body permissions of all bodies the member is part of. So only in case the requesting member and the requested member have bodies in common, permissions will be added. If you are requesting yourself, you get full permissions.
Future permission system improvements
- Extending scoping options. Instead of just local and global we could also use a body type of a local as scope.
- Explicit triggers for contexts. Currently it is hardcoded which additional permissions e.g. a circle_admin gets, it would be nice to have a trigger object with a many to many on permissions that dynamically adds permissions on requesting the associated context