Permissions for Organizations

[oliverroick]

• Define actions for organizations (create, edit, list, archive/unarchive, role assignment)
• Write permissions policy fragments for project permissions for initial fixed roles

Roles and Permissions:

• SUs can create organisations and edit their information.
• OAs can edit the details of the organisations they administer, SUs can edit the details of all organisations.
• OA+s can archive an organisation.
• OA+s can list all organisations (searchable, sortable, filterable list).
• OA+s can manage the user membership list for an organisation, adding or removing members and assigning roles to users within the organisation (as well as user-level permissions).

[oliverroick]

@ian-ross I started putting together some policies for organisations, they are pretty simple, let me know if I'm missing something.

Organisation actions

• org.list
• org.view
• org.create
• org.update
• org.archive
• org.view-archived
• (org.delete)
• org.users.list
• org.users.add
• org.users.remove

Policies

Default for all users

{
  "clause": [
    {
      "effect": "allow",
      "object": ["organization/*"],
      "action": ["org.list", "org.view"]
    }
  ]   
}

Sysamdin

{
  "clause": [
    {
      "effect": "allow",
      "object": ["organization/*"],
      "action": ["org.*"]
    }
  ]
}

Organisation admin

Depending on how we define organisation admin roles.

When an organisation admin is a top level role, i.e. they can manage all organisations is the platform.

{
  "clause": [
    {
      "effect": "allow",
      "object": ["organization/*"],
      "action": ["org.*"]
    }
  ]
}

When they can manage specific organisations only

{
  "clause": {
    "effect": "allow",
    "object": ["organization/habitat-for-humanity"],
    "action": ["org.*"]
  }
}

[ian-ross]

These are almost right, I think, but it's not quite possible to write correct policies yet because I need to do this "collective actions" thing I mentioned to you. The actions certainly look about right, though. Stick what you have so far in a policies directory somewhere (in config?) and I can work them over when I do the project policies. They'll going to need to be integrated into role-oriented policies anyway, so they'll cut across the way we're currently breaking work down.

[wonderchook]

What would the workflow look like if a user signed up for Cadasta and wanted to create their own organization? I suppose this is mostly a workflow/interface thing. Just want to make sure it could work at this level too though.

[oliverroick]

I presume somebody (a superuser) needs to authorise them to do so, unless we want any user to be able to create organisations.

There are two options:

1. The user signs up and requests to be an organisation admin. I imagine — if the user has no permission to create an organisation — a form to request to be promoted to organisation admin, which is shown instead of the Create Organisation form. Super users (or whoever can assign the role) receive an email with a link to approve/reject.
2. The superuser invites the soon to be organisation admin to sign up and assigns the role during the invitation process.

[ian-ross]

I like both of those options, and I think we should eventually support them both. I especially like the idea of generalising option 1 so that any time a user gets a "permission denied" message, they're given the option of requesting the permission (I could probably come up with some algorithm to select somehow the "nearest" administrative user who's able to give them the permission -- might be a project admin, might be an organisation admin, might be a superuser). I think that could be quite neat.

A related but different point is that the initial permissions policies for organisations will be derived from some platform-wide defaults, and initial permissions policies for projects will be derived from the "project template" for the organisation, which will also initially be copied from a platform-wide default. After that, organisation and project policies can be edited as needed.