Help - Security
Example 1: Conference organizers
Each conference has some people who should have a complete control of all the things that happen in the system. To get that exists a role "Conference organizer" who has most of the available permissions, such as "View statistics", "Edit proposals" and "Manage payments". This role is applied to the whole conference.
Example 2: Panel reviewer
In those conferences with panels there are users who can review proposals not of the whole conference but of their panel. The system has a role "Reviewer" with several permissions such as "Accept proposals" and "Reject proposals". If this role will be applied globally to the conference the user will be able to accept or reject all the proposals submitted and it is not the desired behavior. For this reason, when the role "Reviewer" is associated to this user, it is linked only to some panel/s. Then he/she will be able to accept or reject the proposal of this panel. If the organizer wants the reviewer to read all the proposals submitted he/she can create other role with the "View proposal details" permission and linked globally (not to their panels) all the reviewer users.
Example 3: Evaluators of a conference without panels
In a conference with panels the evaluators often are associated with a concrete panel so the security configuration is simple (an evaluator role assigned to a panel). In a conference without panels the role management change a bit. In this example, the evaluator user will have the "Evaluator" role for all the proposals he/she has been assigned by the reviewers.
The security system in tucongreso.es is based on three important elements: users, roles and permissions.
All the pages are protected so only those users with the required permissions can access them.
The system has more than 50 different permissions like: show statistics, edit user, send proposal, accept proposal, ... (Figure 1). In order to avoid making a large number of individual permission assignments, the system makes use of roles. A role is a combination of permissions. Each user is assigned a role rather than individual permissions (Figures 2, 3 and 4). Each of these roles is associated to a set of permissions (Figure 4) so ultimately the set of permissions that a user has is obtained from his/her role.
This common security system based on users, roles and permissions has been changed a bit so it can be adapted to the needs of the system. The changes have been made in the association between users and roles. Normally this association is simple but in the system can be:
- by conference: the role is applied in all the conference. If the permission is related to a proposal (e.g. proposal acceptance) the permission will be applied to all the proposals sent.
- by panel: the role will be applied to all the proposals sent to some panel. Then, if the role is linked to the Pragmatics panel and the role has the permission of rejec proposals the users with this role cannot reject the proposals of a different panel, only the proposals of the panel linked.
- by proposal: the role is applied only to the proposal selected. If the role has the permission of delete a proposal the user can only delete this proposal.
- by full text: igual que el anterior pero con textos completos.
The following examples will explain better the security mechanisms.
Example 1: Conference organizers
Each conference has some people who should have a complete control of all the things that happen in the system. For this purpose, there exists a "Conference organizer" role that has most of the available permissions, such as "View statistics", "Edit proposals" and "Manage payments". This role is applied to the whole conference.
Example 2: Panel reviewer
In those conferences with panels there are users who can review proposals not of the whole conference but of their panel. The system has a role "Reviewer" with several permissions such as "Accept proposals" and "Reject proposals". If this role were applied globally to the conference the user would be able to accept or reject all the proposals submitted, which is not a desirable situation. For this reason, when the role "Reviewer" is associated to this user, it is linked only to some panel/s. Then he/she will be able to accept or reject the proposal of this panel. If the organizer wants the reviewer to read all the proposals submitted he/she can create an additional role with the "View proposal details" permission which is then linked globally to the whole conference.
Example 3: Evaluators of a conference without panels
In a conference with panels the evaluators are often associated with a concrete panel so the security configuration is simple (an evaluator role assigned to a panel). In a conference without panels the role management changes to some extent. In this example, the evaluator user will have the "Evaluator" role for all the proposals he/she has been assigned by the reviewers.
