MartinWahnschaffe commented 5 years ago

Situation Description

Based on #830.

General idea is to get rid of fixed user roles and replace them with user rights only that can be combined in a configurable user role. The default user roles would be based on the existing SORMAS user roles.

create a concept for this (mockup + data schema)
discuss with RKI

Consider:

define if user role has access to web and/or app
limit the available user rights for each role based on availability for web and app. E.g. deletion, import, export, archive, etc. are only available for the web app
add user interface to edit assigment of user rights to user roles
display default configuration in hover info
find a proper name for user right and user behaviours/assignments
maybe use user right groups / user feature to have something between the general persons and the granular user rights (e.g. case investigation). At least in the UI

Proposed Solution

List: https://app.moqups.com/3NUENEwuOE/view/page/ab4eb9432 Edit: https://app.moqups.com/3NUENEwuOE/view/page/a46f29001

Task list

Preparation

[x] #2802
[x] #2805
[x] #2804
[x] #8318

User Role Configuration

[x] #4461
[x] #5058
[x] #4462
[x] #4463
[x] #5059
[x] #8910
[ ] #9015
[x] #9645
[x] #9734
[x] #9905
[ ] #10083
[x] #10200
[ ] #10295
[x] #10305
[x] #10310
[x] #10410
[x] #10339
[x] #10538
[x] #10548
[x] #10563

User Right Backend Checks

[x] #7820
[x] #5056
[x] #5057
[x] #445
[x] #8592
[x] #8352
[x] #8508
[x] #8527
[x] #8531
[x] #8539
[x] #8540
[x] #8541
[x] #8543
[x] #8926
[x] #8920
[x] #8989
[x] #8992
[x] #9045
[x] #10438
[x] #10451
[x] #10735

Additional Information

This was more a task before, before we decided to introduce epic. Now as an epic this is open again to point out what needs to be done to complete the epic.

Result summary from the concept phase is here, but now copied to this description.

Add short documentation for this: https://github.com/hzi-braunschweig/SORMAS-Project/blob/development/docs/SERVER_CUSTOMIZATION.md#user-role-configuration

bernardsilenou commented 4 years ago

@MartinWahnschaffeSymeda : With respect to your point 2 (limit the available user rights for each role based on availability for web and app. E.g. deletion, import, export, archive, etc. are only available for the web app), What is the challenge if we do not limit the user roles. What I mean is that the a user with the rights of the current informant/ SO will be able to use the web application also. Every role (which will be a combination of cert in rights) will be able to use the web. In addition to this, certain roles, like informant will have the additional option to use the mobile version or SORMAS.

MateStrysewske commented 4 years ago

Additional questions:

[x] How do we migrate from the current model to the new model on the existing systems?
[x] Which user rights are incompatible with each other?
[x] How exactly do we store the user role configurations in the database (probably a JSON column)? Do we use a cache? JSON vs JSONB?
[x] Check the users_userroles table of the Nigerian system to see which combinations of user roles are currently being used

MateStrysewske commented 4 years ago

Current concept: Store a UserRole entity in the database that has a "name" column, a "default" column (boolean, true if it's a default SORMAS user role; default roles should not be deletable from the UI) and a "userrights" JSONB column which contains a single key/value pair with the names of all user rights that are enabled for this user role as an array.

Operation to select all user roles with a specific user right: SELECT * FROM table_name WHERE column_name @> '{"attribute_name": ["value"]}';

Operations to add/remove elements to/from the array: UPDATE table_name SET column_name = (SELECT jsonb_set(column_name, '{attribute_name}', (column_name->'attribute_name') || '"new_value"') FROM table_name AS t WHERE t.id = table_name.id) UPDATE table_name SET column_name = (SELECT jsonb_set(column_name, '{attribute_name}', (column_name->'attribute_name') - 'removed_value') FROM table_name AS t WHERE t.id = table_name.id)

MateStrysewske commented 4 years ago

Current user role combinations in the Nigerian system:

Admin & National User: 13
Surveillance Supervisor & Case Supervisor: 13
Surveillance Supervisor & Contact Supervisor: 9
National User & National Clinician: 4

Further combinations that are only set for one user:

Surveillance Supervisor & Event Officer
National User, Surveillance Supervisor & Event Officer
Surveillance Supervisor, Contact Supervisor & Event Officer
National Observer & Contact Supervisor
Contact Supervisor & Event Officer
Surveillance Officer & Contact Officer
National User, Case Supervisor & Contact Supervisor
National User, Surveillance Supervisor & Contact Supervisor
National User & Lab User

Initial thoughts:

Admin & National User can easily be done by adding a custom user role that combines the user rights of a National User with the configuration rights of an Admin
Surveillance Supervisor & Case Supervisor can easily be done by cloning the Surveillance Supervisor role and adding the case management user rights to it
Same goes for any combination of Supervisor roles (e.g. Surveillance Supervisor/Contact Supervisor or Surveillance Supervisor/Event Officer) because those do not conflict in terms of infrastructure assignments
National User & National Clinician are basically Surveillance Supervisor & Case Supervisor on a national level and thus should not result in any issues
National User & Lab User is probably fine as well because there should be no contradicting assignments here - "Assign to Country" and "Assign to Laboratory" should not result in issues
We have a potential conflict for combinations of Supervisor and National Observer roles because those have different visibility rights; such a role combination is not possible with the current system and either needs a functionality that allows users to switch between multiple roles or an additional user right that allows users to view, but not edit data of the whole country

MateStrysewske commented 4 years ago

New mockups: https://app.moqups.com/3NUENEwuOE/view/page/ab4eb9432 https://app.moqups.com/3NUENEwuOE/view/page/ad7b3a18e

MateStrysewske commented 4 years ago

Additional request from Ghana: We should probably make sure that the "Admin" role is not deletable and that there is a specific user right that allows/prevents the creation of "Admin" users (see #1475)

MartinWahnschaffe commented 4 years ago

Clean up / refinements to be done before this:

2215

DONE: