DO NOT LEAVE COMMENTS HERE, COMMENT ON THE RELATED ISSUE decidim/decidim#2056
Here's a list of what permissions each module has, and what actions it is able to perform.
Actions, in the context of this document, are what users can do, normally through the admin panel. Usually, an action will require a permission to perform that action, which can be allowed or denied based on different criteria. For example, users can edit proposals (action), but cannot edit those proposals created by a normal user (permission).
Permissions are usually based on these criteria:
- User roles, including but not limited to:
- Organization admin
- Participatory space admin
- Participatory space collaborator
- Authorship of the resource the action applies to (see previous example of the proposal)
There's a Participatory space moderator user role, which can only moderate resources for a given participatory space. This role is not taken into account in this document. Admins and participatory space admins can always moderate resources. Participatory space user roles can only perform actions for the participatory space they are related to.
Actions are categorized in permissions. Each role can have multiple permissions.
Permissions are checked against the Feature
.
Action | Related ability | Who has permission to perform this action |
---|---|---|
Create result | manage |
|
Read result | view |
|
Update result | manage |
|
Destroy result | manage |
|
Preview result | read |
|
Create result timeline entries | manage |
|
Create child results | manage |
|
Export results | manage_sensible_data |
|
Create status | manage |
|
Read status | read |
|
Update status | manage |
|
Destroy status | manage |
|
Permissions are checked against the Feature
.
Action | Related ability | Who has permission to perform this action |
---|---|---|
Create project | manage |
|
Read project | read |
|
Update project | manage |
|
Destroy project | manage |
|
Preview project | read |
|
Add attachment to project | manage |
|
Action | Related ability | Who has permission to perform this action |
---|---|---|
Create debate | manage |
|
Read debate | read |
|
Update debate | manage |
|
Destroy debate | manage |
|
Permissions are checked against the Feature
.
Action | Related ability | Who has permission to perform this action |
---|---|---|
Create meeting | manage |
|
Read meeting | read |
|
Update meeting | manage |
|
Destroy meeting | manage |
|
Close meeting | manage |
|
Add attachment to meeting | manage |
|
Configure meeting registrations | manage |
|
Export registrations | manage_sensible_data |
|
Invite user to meeting | manage_sensible_data |
If registrations are open: - |
Pages are created and destroyed together with their Feature
. Permissions are checked against the Feature
.
Action | Related ability | Who has permission to perform this action |
---|---|---|
Edit page | manage |
|
Proposals created from the admin are considered official, and a special setting needs to be activated so that official proposals can be created.
Official proposals cannot be edited.
Action | Related ability | Who has permission to perform this action |
---|---|---|
Create proposal | manage |
|
Read ("preview") proposal | read |
|
Answer proposal | collaborate |
|
Export proposals | manage_sensible_data |
|
Export comments | manage_sensible_data |
|
Add proposal notes | collaborate |
|
Surveys are created and destroyed together with their Feature
. Permissions are checked against the Feature
.
Action | Related ability | Who has permission to perform this action |
---|---|---|
Edit survey | manage |
|
Export user answers | manage_sensible_data |
|
From these tables we can conclude that the list of actions users are able to perform, at least in the admin section, is reduced to this list:
- Read/preview a resource
- Create a resource
- Update a resource
- Create a child resource
- Destroy a resource
- Export data
- Moderate resources
There are two actions, though, that don't fall in any category of this list:
- Configure meeting registrations
- Invite a user to a meeting
We can group these actions to some categories (permissions):
Action | Permission |
---|---|
Read/preview a resource | view |
Create a resource | manage |
Update a resource | manage |
Create a child resource | manage |
Destroy a resource | manage |
Export data | manage_sensible_data |
Moderate resources | moderate |
Configure meeting registrations | manage |
Invite a user to a meeting | manage_sensible_data |
Additionally, we're adding a collaborate
permission so that some of these actions can be performed by a role between full-access admin and reader. For eaxample, Proposals uses this permission roles can answer proposals and add private notes to them.
For the public part, we'll drop the authorization system and we'll move the logic to the controller.
Each participatory space can define their own user roles, and for each of them apply some permissions.
Role | Permissions on Space A | Permissions on Space B |
---|---|---|
Admin | read , manage , collaborate , manage_sensible_data |
read , manage , collaborate , manage_sensible_data |
Collaborator | read , collaborate |
read |
Imagine we have one instance of each participatory space, and each of them have proposals set up. In this situation, A user with the role "Collaborator" could create proposal answers and leave private notes in propsoals of the space A instance, but would ot be able to perform these actions onb propsoals of the space B instance because their would not have the rquired permissions.
@andreslucena I think you're pointing on the right direction. In addition to your commet I would suggest that modules should be also able to propose roles composed by several permissions.