Permissioning policies

Roles

The current release of the platform has a set of fixed permissioned roles: super-user (SU), organization administrator (OA), project manager (PM), data collector (DC) and "ordinary" organization members (OM) and project users (PU). In addition, there is a "default" policy applied to all users: for users not assigned other more specific roles, this policy lists all of the permissions that the user has; for users assigned more specific roles as well, the default policy lists the permissions available to the user for all entities not covered by a more specific assigned policy. (This means that the default policy is assigned to all users at creation; subsequent assignment of roles to users supplements the permissions provided by the default policy.)

The roles have the following properties:

• The super-user (SU) role is platform-wide: if this role is assigned to a user, the user acquires wide permissions for all entities stored on the platform.

• The organization administrator (OA) and "ordinary" organization member (OM) roles are specific to a single organization: when either of these roles is assigned to a user, the organization in question must be specified and the user acquires permissions only for entities that are part of that organization.

• The project manager (PM), data collector (DC) and "ordinary" project user (PU) roles are specific to a single project within a single organization: when any of these roles are assigned to a user, the organization and project in question must be specified and the user acquires permissions only for entities that are part of that project within that organization.

Policy files

For each of the roles described above, there is a single JSON policy file in cadasta/config/permissions. There is also a default.json default policy file, giving the permissions assigned to users who do not have any explicit policy assignments. The full list of policy files is thus:

File	Role
data-collector.json	DC
default.json	Default
org-admin.json	OA
org-member.json	OM
project-manager.json	PM
project-user.json	PU
superuser.json	SU

The way this is intended to work is as follows:

1. All users are assigned the default policy.

2. When users are assigned roles, either globally (SU), for a specific organization (OA, OM) or for a specific project within a specific organization (PM, DC, PU), these permissions are "stacked" onto any existing permissions that the user has. A user could thus be a PM in one project, a DC in another, and have the permissions provided by the default policy for all other entities in the platform.

Permission assignments

The following table and notes show the assignment of permissions to these fixed roles. An "X" in a column indicates that the role has the permission generally, an "O" in a column indicates the the role has the permission for a specified organization, a "P" in a column indicates the role has the permission for a specified project within a specified organization, a "+" in a column indicates that the role inherits the permission from the default policy, and numbers refer to notes below the table.

This table is based on what's currently in the JSON policy documents. This may not be RIGHT. If anyone sees any inconsistencies, or things that seem wrong, please ask!

Action	SU	OA	PM	DC	OM	PU	None
Organizations
org.list	+	+	+	+	+	+	X
org.view	+	+	+	+	+	+	X
org.create	1	1	1	1	1	1	1
org.update	X	O
org.archive	X	O
org.unarchive	X	O
org.users.list	X	O
org.users.add	X	O
org.users.edit	X	O
org.users.remove	X	O
Projects	SU	OA	PM	DC	OM	PU	None
project.list	+	+	+	+	+	+	X
project.view	+	+	+	+	+	+	X
project.view_private	X	O	2		O
project.create	X	O
project.update	X	O	P
project.archive	X	O
project.unarchive	X	O
project.download	X	O	P
project.users.list	X	O	P
project.users.add	X	O	P
project.users.edit	X	O	P
project.users.remove	X	O	P
Questionnaires (4)	SU	OA	PM	DC	OM	PU	None
questionnaire.view		O	P
questionnaire.add		O
questionnaire.edit		O	P
Parties	SU	OA	PM	DC	OM	PU	None
party.list	X	O	P	P	O
party.view	X	O	P	P	O
party.create	X	O	P	P
party.delete	X	O	P	P
party.update	X	O	P	P
party.resources.add	X	O	P	P
Spatial units	SU	OA	PM	DC	OM	PU	None
spatial.list	X	O	P	P	O
spatial.view	X	O	P	P	O
spatial.create	X	O	P	P
spatial.delete	X	O	P	P
spatial.update	X	O	P	P
spatial.resources.add	X	O	P	P
Resources	SU	OA	PM	DC	OM	PU	None
resource.list	X	O	P	P	O
resource.view	X	O	P	P	O
resource.add	X	O	P	P
resource.edit	X	O	P	P
resource.archive	X	O	P	P
resource.unarchive	X	O	P	P
Party relationships	SU	OA	PM	DC	OM	PU	None
party_rel.list	X	O	P	P	O
party_rel.view	X	O	P	P	O
party_rel.create	X	O	P	P
party_rel.delete	X	O	P	P
party_rel.update	X	O	P	P
Spatial unit relationships	SU	OA	PM	DC	OM	PU	None
spatial_rel.list	X	O	P	P	O
spatial_rel.view	X	O	P	P	O
spatial_rel.create	X	O	P	P
spatial_rel.delete	X	O	P	P
spatial_rel.update	X	O	P	P
Tenure relationships	SU	OA	PM	DC	OM	PU	None
tenure_rel.list	X	O	P	P	O
tenure_rel.view	X	O	P	P	O
tenure_rel.create	X	O	P	P
tenure_rel.delete	X	O	P	P
tenure_rel.update	X	O	P	P
tenure_rel.resources.add	X	O	P	P
Users (3)	SU	OA	PM	DC	OM	PU	None
user.view	X
user.list	X
user.update	X

1. Any user can create a new organization. When a new organization is created, the creating user is assigned the OA role for the new organization.
2. A PM may view private projects that they created, but no others.
3. These are administrative actions allowing access to private user data (email, real names, etc.) and so are restricted to super-users.
4. Permissions don't seem to be set up for questionnaire manipulation. These permissions appear only to be used in the questionnaires API (i.e. not anywhere in the HTML views that set up quesionnaires for projects). This needs review.