Control access (StR31)

[tmfrnz]

Original requirement:

Stakeholder requirement: StR31 "Control access"

I want to: control the access that is granted to both registered and non-registered users and to specific information

So that: security breaches are avoided

Supporting info:

• After authenticating users, access needs to be controlled (potentially via role-based provisioning).
• Non-registered users will be granted view access only, to all information.
• Registered users will, by default, have view access only and to all information. However, edit access may be requested during the user registration process.
• An administrator will be able grant edit (add, modify, delete) access.
• An administrator may also restrict access to specific information only (e.g. for MoJ users: full edit access to recommendations/actions/indicators; for users from agencies responsible for actions: edit access to progress updates for indicators only).

likely requires #31

[tmfrnz]

Additional info:

• can we limit Contributors and Managers to specific treaty bodies only (then just Contributor or Visitor/Guest to all other content?) instead of Managers being able to edit all treaty bodies. Do we also remove user administration from Manager role?

can use the user_categories table to assign users with treaty bodies (that are stored as categories), then limit users' editing privileges to recommendations, actions and indicators that are (directly or indirectly) linked to that category. now will either need to store the treaty body taxonomy id in config or add a e.g. needs_user_category_relationship field to the taxonomy table

• can Managers create accounts (instead of users registering accounts then Managers granting them roles) then send link to log in (and must change password)

should not be required if using AD (#26)

• also report to monitor account with no activity. also ability to make accounts inactive without deleting them

could allow archiving of users (as part of #13)