Agree initial rules/roles for data model access

[isedwards]

As an OpenCDMS core developer, I need agreement on the initial set of rules/roles that we will implemented for Controlled Access)

Given that different NMHSs may implement different roles, a first implementation may demonstrate three roles:

• No access (default)
• Administrator (full access)
• User (example limited access)

[isedwards]

Hey team! Please add your planning poker estimate with Zenhub @chinedu117 @david-i-berry @scottylad501

[isedwards]

Using code developed in the previous sprint (currently in the opencdms-data-layer repository), we should initially implement three roles in the policy file: None (access to nothing), Admin (read/write everything) and User (limited access to something)

TASKS

• TDD: write failing tests showing that rules are not ALL initially enforced (Acceptance Tests)
• Move oso code from opencdms-data-layer repo to new pyopencdms and refactor to work with new models using imperative mapping
• Confirm whether it is possible for oso to create/manage the additional tables that are required using resource_role_class
• Decide whether additional tables required to enforce access control can have a table prefix (e.g. access_ or rbac_ - if all new tables are for RBAC)
• Refactor policies to make tests pass

[david-i-berry]

The following roles are defined in SURFACE:

1. "Guest"
2. "Data Entry Clerk"
3. "Instrument Technician"
4. "Climate Officer"
5. "Climate Administrator"
6. "Meteorologist"
7. "System Administrator"

[scottylad501]

@david-i-berry

Allow me to explain the permissions of each role

1. "Guest" - This user was/is given to our stakeholders, basically anyone outside wanting data access would sign a user agreement before hand and be given access to login to the application. They can only view the map and view a restricted amount of data via station report, Station compare and Spatial Analysis. Data restriction are:

• 7 days of RAW data
• 31 days of hourly data
• 1 year of daily data
• no restrictions on yearly data

2. Data Entry Clerk - The lowest user level, it's basically an observer or a student given the task of data entry. In addition to the Guest user they have access to the data entry forms. However they are not able to export data.

3. Technician (i would rename this to simply Technician) - Guest privileges, Station Metadata section, Maintenance section, and Django backend.(if we could have restricted some of the Django backend access we would have) - all the work needed to check that stations are operating properly is needed here for the technician. For the django backend all the options reltaed to automatic file ingestion. Does not have access to Data Export feature

4. Climate Officer - Guest, Data entry clerk, may or may not get technician roles, it depends on training - but here this person is able to validate data coming into the system. Basically quality control checks for the data. Has access to data export feature. Data export allows the user to create an export job via the UI for any station for any time period. there is no restrictions on the amount of data that can be exported. A record is kept of who made the data export request.

5. Meteorologist - is weird user role, they are strictly operational so - they do not have data entry permission, nor do they have django backend and access to maintenance, BUT they have access to all products and have access to data export. So in once sense they have access to the entire dataset, but at the same time they are prevented from making any technical changes to the data/instruments/stations.

6. Climate Administrator - is basically one step down from the System Administrator - confirms the validation done by the climate officer. In essence has access to the entire system but cannot create a new user.

7. System Administrator - all roles and privileges