Permissions requirements

[fyliu]

This is a work in progress for permissions requirements.

• Suggested to be a team exercise in Discuss our requirements for permissions #150
• Permission Types definitions

Examples

Cases involving roles and data models:

Contributor (normal user)

• a contributor needs to be able to edit their own user profile, but not the user.status field, since that data belongs to the organization, and not the other user profiles.

Project Admin

• a project lead needs to be able to update the project they are leading (row in the project table for their project), but not be able to update the other projects (rows belonging to other projects).

Cases involving roles only:

Global Admin

• an admin needs to be able to act on all tables.

Requirements for permission system

• must be able to set permission for each model field (table column)
• each CRUD action has its own permission
• higher permission level inherit the permissions from everything below it

[fyliu]

What permission types are useful for v0.1?

• We definitely need memberGeneral, which is the basic level of membership.
• We need some kind of admin that can approve users into memberGeneral. I assume we need to approve people to become memberGeneral since anyone is free to create an account on the cognito user pool and therefore can create a valid user in our system. We don't want this category or freely-created users to have access to any non-public data. See Missing Permission Type #147
• We need an "unverified user" type with no permission. See Missing Permission Type #147

[ExperimentsInHonesty]

@fyliu and @ExperimentsInHonesty we do need an unverified user so that people who have not yet, accepted TOS, accepted GitHub Invite, etc, do get invited to join projects. Once they do or accept all the required items then they become memberGeneral. And memberGeneral can be invited to see projects that have open roles.

[fyliu]

What is the process for an "unverified user" to become memberGeneral?

I assume this:

• accepts TOS
• completes checklist (who checks off the list? an admin?)
• gets promoted to memberGeneral (does the system do the promotion of an admin? I assume an admin? or an admin can manually promote even if it will generate warnings about the checklist?)

[ExperimentsInHonesty]

No one can be promoted, even manually, without doing the checks.

The self-service is a built-in filter to make sure people have the minimum level of technical knowledge necessary to be successful at Hack for LA.

Checklist of things the unverified user has to complete in order to become a memberGeneral:

• Agree to the code of Conduct
• Creat user account on VRMS (will be expanded to ask all the info necessary for onboarding)
• Log into Onboarding meeting on VRMS
• Accept GitHub Invite
• Provide Slack ID
• Mark GitHub membership public

Screenshot of onboarding form

[ExperimentsInHonesty]

We need to annotate this sheet https://docs.google.com/spreadsheets/d/1x_zZ8JLS2hO-zG0jUocOJmX16jh-DF5dccrd_OEGNZ0/edit#gid=1572339087

[fyliu]

This was a useful exercise. We now know that we need a permissions system that can handle per-column (model field) access control within a model. We're going to start out by specifying permissions for each CRUD action separately and only on the project table. We set the minimum permission level for each column and anyone with a higher level permission can also perform that action.