Discuss our requirements for permissions

[fyliu]

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 Permissions requirements #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]

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]

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

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

[ExperimentsInHonesty]

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]

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]

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]

• @Neecolaa will update the comment above with actual table names
• next meeting, we will check to see if the tables exist already
• 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]

Use cases and tests for FLS feasibility

unverifiedUser

1. Update any user information for themselves
   • name
   • phone
   • texting_ok
   • email

memberGeneral

1. same as unverifiedUser

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

memberProject

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

1. 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)
2. 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
3. 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
4. Remove a user in their practice area from team: Update user 6 (snoop) to end his permission (memberProject) on his project (1 website).
5. 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)
6. 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.
7. 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

1. Add any user with any practice_area to project
2. Remove any user with any practice_area from project
3. Demote any user with any practice_are on project
4. Promote any user with any practice_are on project
5. 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

1. 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)
2. 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
3. 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

[Neecolaa]

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 ER: Rationalizing the sponsors and partners info in code base website#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]

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]

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]

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]

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]

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

[Neecolaa]

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]

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]

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

[shmonks]

Please provide update

1. Progress: "What is the current status of your project? What have you completed and what is left to do?"
2. Blockers: "Difficulties or errors encountered."
3. Availability: "How much time will you have this week to work on this issue?"
4. ETA: "When do you expect this issue to be completed?"
5. 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]

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]

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

[shmonks]

Please provide update

1. Progress: "What is the current status of your project? What have you completed and what is left to do?"
2. Blockers: "Difficulties or errors encountered."
3. Availability: "How much time will you have this week to work on this issue?"
4. ETA: "When do you expect this issue to be completed?"
5. 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.

[shmonks]

Please provide update

1. Progress: "What is the current status of your project? What have you completed and what is left to do?"
2. Blockers: "Difficulties or errors encountered."
3. Availability: "How much time will you have this week to work on this issue?"
4. ETA: "When do you expect this issue to be completed?"
5. 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.