Implement support for roles in the backend

[robsavoye]

Currently the database and backend has no support for roles, so this will need to be added. The initial roles would be these:

Based on the experience in Dominica, I suspect we'll need the following roles:

• Admin (all permissions for everything on the server)
• Group (Organisation) Admin (all permissions within a group, so they can create, edit, process, or delete projects for their own agency, but not see or mess with projects by another group; so for example the Red Cross admin can do everything with the Red Cross' projects but not see or mess with Save the Children's projects)
• Field Admin (cannot create projects, but can unlock tasks unilaterally—we saw the need for this during the Dominica mapping when mappers locked tasks, didn't map them, and no one other than the mapper who locked them could force-unlock them to access the QR codes)
• Field Mapper (select tasks and mark them complete)
• Validator (select tasks, download the submissions, mark them validated or rejected)

[krtonga]

I originally took the db schema from TaskingManager. A few things to note:

A DbUser has a role which is a UserRole, currently READ_ONLY, MAPPER, and ADMIN. Talking with Ramya of HOT, it is important that there is a READ_ONLY, as it is sometimes necessary to block a certain bad actor.

There is also a DbTeam for an organization and DbProjectTeams. I would have to check with a TaskingManager expert to see how these are used in the original.

The project_allowed_users secondary table is also defined, and used for private projects, to define specific mappers that can map a given project.

[dicksonguantai]

@krtonga and @robsavoye I would like to give a shot to this. I like the idea of this project and coincides with my interest.
I am an outreachy applicant and would use it a contribution.

[spwoodcock]

FMTM Roles

We discussed this morning.
I think the roles Rob proposed are ideal - we just added one more role:

• Super Admin - not a db role, the person that has ssh keys and direct database access.
• Admin - permission for everything on FMTM, but no database access.
• Organisation Admin - all permissions within an organisation, to create projects, grant project admin roles, but not mess with other organisation projects.
• Project Admin - can modify / delete project, grant permissions to field admins, mappers, etc.
• Field Admin (associate project admin, with a nicer name) - cannot delete or modify the project, but can grant users access to projects, and unlock tasks.
• Mapper - can map tasks and that's it (default).
• Validator - can modify tasks worked on by mappers, download all submissions, push data to OSM.

Now the question is, how does this fit in with Tasking Managers idea of Team based permissions?

The end goal is to have a user management module that handles all of this - it needs to work for both FMTM and TM (either using the same schema, or having a mapping between the two).

TM Roles

• The first level of roles is an enum: mapper, admin, blocked user (read only).
• Mappers are granted admin rights by another admin.
• Levels of admin:
  • Organisation
  • Team
  • Campaign

We may have another meeting with @ramyaragupathy to clarify and discuss how to best map FMTM --> TM roles.