Discuss our requirements for permissions

fyliu commented 1 year ago

Overview

We need to discuss our needs for permissions and turn them into requirements.

Action Items

[ ] [team discussion] what do we need?
[ ] Make notes in discussion topic #159
[ ] record the scenarios and convert them into requirements

Resources/Instructions

Keep in mind that this will be converted into acceptance criteria (requirements), so try to define all cases so that the software won't be missing anything crucial.

Examples (already copied into #159)

Cases involving roles and data models:

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).
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.

Cases involving roles only:

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

ExperimentsInHonesty commented 1 year ago

From the spreadsheet name	description
adminGlobal	Can CRUD anything
adminVrms	Can R anything and update permissions for users to the level of Admin Brigade
adminBrigade	Can CRUD anything related to a user or project assigned to their brigade
adminProject	Can Read and Update anything related to their assigned project
practiceLeadProject	Can R and U anything related to people in their practice area (must attend lead events)
practiceLeadJrProject	Can R and U anything related to people in their practice area (should attend lead events)
memberProject	Can Read anything related to their project that is visible
memberGeneral	Can express interest in a project's open role if they are the role
unverifiedUser	A User who has not completed all the pre and onboarding steps

ExperimentsInHonesty commented 1 year ago

We are currently annotating this spreadsheet: PD: Table and field explanations

It will likely take 3 more hours to finish the annotation.

ExperimentsInHonesty commented 1 year ago

We need to document different permissions

What are we publishing in the public API What are we publishing in the private API with authenticated users, and what usage level do they need to have.

ExperimentsInHonesty commented 7 months ago

Updated version of this table name	permission
adminGlobal	Can CRUD anything
adminVrms	Can R anything and update permissions for users to the level of Admin Brigade
adminBrigade	Can CRUD anything related to a user or project assigned to their brigade
adminProject	Can Read and Update anything related to their assigned project and see some team member contact info (name, role, slack, phone if texting ok, github handle, linkedin, preferred email). Can update a users team status.
practiceLeadProject	Can R some team member contact info (name, role, slack, phone if texting ok, github handle, linkedin, preferred email) related to people in their practice area (must attend lead events). Can update a users team status.
practiceLeadJrProject	Can R some contact info (name, role, slack, phone if texting ok, github handle, linkedin, preferred email)) related to people in their practice area (should attend lead events). Can update a users team status.
memberProject	Can Read anything related to their project that is visible including (name, role, slack, github handle, linkedin). Can update their own team status
memberGeneral	Can see all project open roles and express interest/or withdraw interest in a project's open role if they are in the practice area
unverifiedUser	A User who has not completed all the pre and onboarding steps

ExperimentsInHonesty commented 7 months ago

user

id	name_first	phone	texting_ok	preferred_email
1	Admin	555-222-3333	TRUE	admin@something908.com
2	Sarah	555-235-8989	TRUE	sarah@something908.com
3	Bob	555-456-7890	FALSE	bob@something908.com
4	Alice	555-765-4321	TRUE	alice@something908.com
5	Joe	555-468-5656	FALSE	joe@something908.com
6	snoop	555-555-5656	FALSE	snoop@something908.com
7	Ralph	555-555-8888	TRUE	ralph@something908.com
8	Claire	555-555-6666	TRUE	claire@something908.com
9	Mary	555-555-2222	FALSE	mary@something908.com

permission

user_id	project_id	practice_ area_id	permission_type_id	granted	ended
1	1	1	1	2023-12-01
2	1	2	2	2023-12-01
2	2	2	2	2024-01-01
3	1	3	3	2023-12-01
4	1	3	3	2023-12-30
4	1	3	4	2023-12-01	2023-12-30
4		3	5	2023-11-01	2023-12-01
6	1	3	4	2023-12-01
5		3	5	2023-12-01
7	2	3	4	2023-12-01
8	1	3	3	2023-12-01
9	1	4	4	2023-12-01

permission_type

id	name
1	adminBrigade
2	adminProject
3	practiceLeadProject
4	memberProject
5	memberGeneral

practice_area

id	name
1	admin
2	pm
3	research
4	design

project

id	name
1	website
2	people depot

ExperimentsInHonesty commented 7 months ago

[x] @Neecolaa will update the comment above with actual table names
[x] next meeting, we will check to see if the tables exist already
[x] next meeting write out the test cases to see if the middle ware for doing FLS can be done
[ ] make an issue for FLS testing

ExperimentsInHonesty commented 7 months ago

Use cases and tests for FLS feasibility

unverifiedUser

Update any user information for themselves
- name
- phone
- texting_ok
- email

memberGeneral

same as unverifiedUser

N/A to additional tests currently because we have not created open roles table for this test

memberProject

See the names of the other team members and their
- name practice area (tells you if they are a designer, researcher, PM, etc.)
- permission type (tells you their role on the team)

practiceLeadProject

Old permission do not impact new permissions: User 3 (Bob) sees user 4 (Alice) as practiceLeadProject, not memberProject (because she got a promotion and her old permission was ended and a new one added)
See a roster for their project team and practice area only: User 3 (Bob) sees the names of the other team members on project 1 (website and no other teams, e.g. not 2 people depot). Also, user 7 (Ralph on People Depot) should not show up as he is in the People Depot project.
- name
- practice_area
- permission_type
- phone
- texting_ok
- email
See the following information for all project 1 (website) team members. User 7 (Ralph on People Depot) should not show up as he is in the People Depot project, and Sarah who is in both project 1 & 2 will show up.
- name
- practice_area
- permission_type
Remove a user in their practice area from team: Update user 6 (snoop) to end his permission (memberProject) on his project (1 website).
Cannot remove a user in another practice area. User 3 (Bob) cannot remove user 9 (Mary) from team, because she is in another practice area (design) from Bob (research)
Add a user to a team/promoting user in their practice area: Add user 5 (Joe) to end his current permission (memberGeneral) and add a new permission to make him memberProject of the website project. practice_area id remains the same.
Demote a user in their practice area: add a new permission for user 8 (Claire) for memberProject and end permission for practiceLeadProject. Verify that user 3 (Bob) sees her as memberProject with no other permissions.

adminProject

Add any user with any practice_area to project
Remove any user with any practice_area from project
Demote any user with any practice_are on project
Promote any user with any practice_are on project
See any user on project and all their details: See the following information for all project 1 (website) team members. User 7 (Ralph) should not show up as he is in the project 2 (People Depot).
- name
- practice_area
- permission_type
- phone
- texting_ok
- email

adminBrigade

Look up any user and see their permission history: Look up user 4 (Alice) and see her organization history
1. 2023-11-01 onboarded with practice_area 3 (research)
2. 2023-12-01 joined project 1 (website) as a projectMember with practice_area 3 (research)
3. 2023-12-30 became practiceLeadProject (research) on project 1 (website)
Update a user's email address: Update user 2 (Sarah)'s email address from sarah@something908.com to sarah-hfla@something908.com. This test works for the following fields
- name
- phone
- texting_ok
Lookup and update any project data: Update people depot name with a new name, PeopleDepot.

We will not be testing updating the practice_area for a user, since it involves revoking all permission associated with the current practice_area. Additionally, we have yet to discuss how people can be in multiple practice areas. This is all out of scope for the current FLS testing

fyliu commented 6 months ago

@ExperimentsInHonesty Should practiceLeadProject item 2i be 3 instead? To me, it looks like a typo on the indentation but I'm not sure.

fyliu commented 6 months ago

~~Here's the place in django docs saying it supports RLS.~~

Permissions can be set not only per type of object, but also per specific object instance

Looks like this statement has been in Django for a long time, like back when django-guardian was still being updated. I can only guess that this statement doesn't mean what I thought it meant, and that something like django-guardian is still required for RLS.

Neecolaa commented 6 months ago

Future tasks for Bonnie and I:

We need to reexamine the event model through the lense of some events being public and others having prerequisites for viewing.
Review this issue https://github.com/hackforla/website/issues/6819 to rationalize between people depot's future architecture and the website team's current needs.
Go back and assign blank Create/Update/Delete permissions

Neecolaa commented 4 months ago

Need to add this information to spreadsheet:

Project Practice Area Lead Assign Permission: Can assign any user to the project and practice area for which tye are a lead, even users not on their project. See Appendix B for more details on user list.

Project Member De-assign Privilege: Only themselves

Project Practice Area Lead De-assign Project: Can de-assign any user that is assigned to the project and practice area for which they are a lead

Neecolaa commented 4 months ago

OUR NOTES TO OURSELVES Project Practice Area Lead Assign Permission: Can assign any user to the project and practice area for which tye are a lead, even users not on their project. See Appendix B for more details on user list. De-assign Project: Can de-assign any user that is assigned to the project and practice area for which they are a lead Project Admin Assign Permission: Can assign any active user to the project and practice area for which they are a lead, even users not on their project. See Appendix B for more details on user list. De-assign Permission: Can de-assign any user that is assigned to the project and practice area for which they are a lead

Project Member De-assign Privilege: Only themselves

User last_login to people depot

Neecolaa commented 2 months ago

Foreign keys are sometimes updated by users Example: A community of practice changes their leadership type. The lead would see a dropdown of the currently existing leadership types and be able to select one. This would cause the leadership_type_id in the database.

Permission rules for tables with hide field: if TRUE, all other fields in the table have AdminBrigade permission level at minimum. If false, permission levels noted in spreadsheet are applicable

Revisit project_leads from project table at next meeting

Neecolaa commented 2 months ago

To do after this pass:

Return to unverified_user permissions. Will the information need to be hidden in certain cases? If so, make sure there's a field for hiding the information. If information is hidden, it will only be able to be viewed by someone with the minimum UPDATE permission level or higher.
We also have a Dependent on Permission flag that we should revisit

08/26 Left off on Project_Program_Area_Status

Neecolaa commented 2 months ago

ERD/SS changes: Project_Program_Area_Status -> Project_Program_Area_Status_Type Project_Status_History -> Project_Program_Area_Status

Neecolaa commented 1 month ago

Idea for tables that need brigade admin approval: Start off storing updates for approval in JSON files on the VRMS side, can change to database tables if json system proves to be too slow.

Need to identify tables that need admin approval for creation/edits

Neecolaa commented 1 month ago

Question for Ethan: How hard is it to change permission levels? Currently, some permission levels are high. When we build features in the future, we'll want to lower permission levels.

Use the example of user's practice_area_target

ExperimentsInHonesty commented 1 month ago

We met on Monday and made good progress. A few more weeks and we will probably ready to discuss again with Ethan.

shmonks commented 3 weeks ago

Please provide update

Progress: "What is the current status of your project? What have you completed and what is left to do?"
Blockers: "Difficulties or errors encountered."
Availability: "How much time will you have this week to work on this issue?"
ETA: "When do you expect this issue to be completed?"
Pictures or links* (if necessary): "Add any pictures or links that will help illustrate what you are working on."

remember to add links to the top of the issue if they are going to be needed again.

Neecolaa commented 3 weeks ago

We worked on determining which fields are needed for events so that we can assign permission levels for those fields. We started working on it in this tab, but it would currently require an explanation from Bonnie or I to understand it. The plan is to talk about this at the next all team meeting.

ExperimentsInHonesty commented 2 weeks ago

We met yesterday and want to talk to Fang about the event Recurrence library

Specifically how it addresses check ins and cancelations and record keeping for historical analysis

hackforla / peopledepot