Open fyliu opened 2 years ago
I had planned to use this table as an example for creating initial data migration, but I ended up using soc_major instead. I did use this one to create the initial conversion script, but there are many initial data sheets that have exactly the same columns and I needed to make sure the script worked for the general case.
This is half way down the Prioritized Backlog, but I'm taking this issue so no one works on it while I use it for #36. I initially used this as an example of populating the database with initial data generated from the PD: Tables and field explanations spreadsheet.
There's also the soc_major model mentioned above. I remember having to fix the CSV-to-python conversion script because of it, I believe to work with something exceptional in the table headers. I may have lost that change after a hard drive crash, but I will make sure the script works with it too. That issue is in the Ice Box, so I'm not going to assign myself to it.
I think having a single user_status per user is problematic, and a user should probably have a separate status for each project they're in.
Here's the diagram of user_status' relationship to user. Here's the initial data.
Does each user have a single user_status? According to the diagram above, yes. That means it's the user's status at the organization/brigade level. But the status reflects events that happen in individual projects: project check-ins.
Alice is part of the PD team. Alice is active in PD and her VRMS check-in to the PD team automatically marks her user_status as Active.
Alice is also part of the Engineering CoP. Due to Alice's current schedule, she can no longer contribute to Engineering. Alice changes her own user_status to Time Away Hold.
Alice still has enough time for PD, so she checks in to VRMS for PD and it marks her user_status Active again.
When the Engineering CoP lead views all active members in the CoP (is this one of the things the user status should be used for?), they would see that Alice is still active when she's really not.
Related alternative: If Alice did not set the Time Away Hold, she would be automatically marked Inactive after 4 weeks of not checking in to Engineering CoP. Her status would keep alternating between Active and Inactive in this case. What should be her real status if there's only a single one?
It feels like the status should be a relationship between a user and a project. The Active/Inactive/Time Away Hold fit nicely into that. A user can be active in one project and inactive in another at the same time.
The Barred status fits as well, but it might also be thought of at the organizational level, where a user is barred by an admin from participating in all the projects and CoPs.
The organization level user status feels like an aggregate of the project level ones. To derive it, we can take the user, where user.statuses
is a list of FKs that point to statuses for projects the user is in, and go through them to determine if the user is active in at least one project.
The organization level user status feels like an aggregate of the project level ones. To derive it, we can take the user, where user.statuses is a list of FKs that point to statuses for projects the user is in, and go through them to determine if the user is active in at least one project.
I think that's a valid concern. Perhaps a user_status
as string can be for general user status (as long as the user is active for at least one project) and user_project_status
will be for the relationship between project:status?
I'm sure there are different ways to handle this; I just thought of 2 possibilities immediately and would love feedback.
Option 1:
user_project_status
as JSON to store key:value of project_id: user_project_status. Postgres does give us the flexibility to do this without further complicating our schemas.Option 2:
user_active_projects
arrayuser_inactive_projects
array user_time_away_hold_projects
array user_barred_projects
arrayuser_active_projects
While I like Option 1 over Option 2, I'm curious to hear others' opinions.
I just want to make sure I’m not misunderstanding this. I think a single user status is the high level requirement we need to meet. The implementation details might be up to us to discuss and decide.
My suggestion above is to make user_status a many-to-many relationship to user, and to have a project field so that a project lead doesn’t mark a user as Time Away Hold for another project. So it would need a through table like the user_project_status you have, to hold this extra data for use by permission.
Two issues came up in our discussion about this issue
We are likely going to use swagger (in use by other projects at hfla, and is the most popular externally)
Short article that generally explains OpenAPI documentation https://www.django-rest-framework.org/topics/documenting-your-api/
A full featured Swagger installation option https://drf-yasg.readthedocs.io/en/stable/readme.html#features
What Swagger has to say about data dictionaries https://swagger.io/docs/specification/data-models/dictionaries/
CivicTechIndex (a hackforla project) uses swagger
https://api-stage.civictechindex.org/swagger/ (try organizations, using hack-for-la
as the slug)
Swagger has an fake example that has more data in it https://petstore.swagger.io/?docExpansion=full
What we would probably install
A full featured Swagger installation option https://drf-yasg.readthedocs.io/en/stable/readme.html#features
We're using drf-spectacular (outputs documentation in OpenAPI3 format) in PD right now, and would rather not go back to drf-yasg (OpenAPI2) unless it's lacking some support we need. OpenAPI 3 allows more expressive documentation than OpenAPI 2.
Examples
From PD code: This portion of our code with the description of thehttps://github.com/hackforla/peopledepot/blob/998d8ea23b2f091e37f071f6fc958480dbcfac52/app/core/api/views.py#L49-L61
@chelseybeck Can we assume you are not working on this? And we can unassign you and put it in the prioritized backlog.
We need to discuss these or create ERs for them to move them off this issue.
@fyliu @Neecolaa
Q: Did we decide how it relates to user and projects? Say a user is in People Depot and also in Engineering. Does the user have a single status and the last status set by one of the projects sticks, or does it go on the user-project xref table? Create an ER for this?
A: The user status is derived by if the user has an active permission on any project (including CoPs)
So in the future, if a person is not on a project, and is going to CoP meetings or assigned to a CoP issue, or Guide, then they are active. We will routinely remove people from issues for lack of activity, and VRMS/Zoom will track attendance at events.
Q: Relocating the description to a data dictionary. Is this on hold that we're not doing for now? I'm not sure what needs to be done for that. Create an ER for this?
A: I am not sure what you are asking regarding the data dictionary
It sounds like we only need the status in the user table, and then maybe there needs to be backend automation(s) to check if the user
In Progress
statusSummary:
@ExperimentsInHonesty For the data dictionary, I meant do we still plan on doing it since I think Chelsey might have moved on from here? She has the expertise on creating it and how to use it.
It looks like the data dictionary decision does block this issue.
description
columndescription
column
Hold this for discussion on Monday 08/11/24 discussion with VRMS - but it looks like we're going to err on the side of keeping the descriptions in the database for now.
Overview
We need to create the
user_status_type
table so that we can update a shared data store across hackforla.org, vrms, civictechjobs, and tables (onboarding) project.Details
A table and a model are the same thing
Action Items
Resources/Instructions
Description
User Status
Data Fields
Copied from spreadsheet and checked off according to ERD. (unchecked items indicate a mismatch between ERD and spreadsheet, which requires a review)
In ERD only (having items here indicates a mismatch, which requires a review)
Associated Tables
Copied from spreadsheet and checked off according to ERD. (unchecked items indicate a mismatch between ERD and spreadsheet, which requires a review)
In ERD only (having items here indicates a mismatch, which requires a review)