Authorization
From Pentabarf
This page is intended for discussing the authorization scheme for Pentabarf 0.3
Contents |
Authorization in 0.2
There is a list of privileges. These privileges can be assigned to different groups (developer, admin, committee, reviewer, submitter). The groups don't have any other meaning than being an abstraction for the privileges.
Every person in the database can be member of any number of groups (or none). The privileges a person has are inherited from the group memberships.
Basically there are 3 domains for which you can have permissions: Person, Events and Conferences (and Valuelist, Localization, Roles and Login for administration stuff). Every table or view in Pentabarf is assigned to one of these domains. For persons and events there are separate permissions for own_person which obviously is your own person entry and own_events which are events you have a certain role in.
Limitations
- It is not possible to assign per conference permissions.
- Persons in the committee group of one conference can see the personal data of all persons
Authorization for 0.3
The idea is to have both global and local permissions so submitters would still be able to submit for all conferences but it would also be possible to limit access to certain conferences.
Couple permissions to other objects
per event permissions
This is already implemented in 0.2.x and works quite well. Persons who have a certain role at an event are allowed to modify it.
per conference permissions
conference roles could be defined which resulted in permissions on the objects of the conference.
per track permissions
track roles would allow assigning per track permissions. I see some some minor issues here because the track is not a mandatory attribute of an event, but in combination with other permissions this should be useful.
per room permissions
This equivalent to the track permissions.
