Epic: Audit differences between code and documented field names

[Neecolaa]

Overview

There are field names in the code that do not currently match our documentation. We need to go through the existing django models, identify the mismatches, and update the code or documentation to comply with our desired naming conventions.

Action Items

• List existing models
• For each model, create a table containing the different field names
• Verify desired naming conventions
• Update the documentation/code
• release Discuss our requirements for permissions #150 from icebox

Resources/Instructions

1.01 Code locations

• 1.01.01 /app/core/models.py
• 1.01.02 /app/core/admin.py
• 1.01.03 /app/core/api/serializers.py
• 1.01.04 /app/core/migrations/0002_user_current_job_title_user_current_skills_and_more.py

1.02 People Depot Resources wiki page for links

• ERD
• Table and Field Definitions
• API Endpoint
• 1.03 Spreadsheet, all fields

[fyliu]

[name of concern]

Action Item recommended

Details

Details

I want to note that when we name a ForeignKey field something like "user", Django will create a database column called "user_id". It's Django's convention to drop the "_id" from the end when converting from db to Django code.

These screenshots illustrate how ForeignKey fields in Django actually turn into db columns with "_id" endings

I can find a link to a better description of this when I'm on a computer.

[Neecolaa]

When we get to documenting the Events tables, see the following note

event has a field called brigade_id that's commented out, but will need to be changed to org_id

[ExperimentsInHonesty]

Instructions

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 (if necessary): "Add any pictures that will help illustrate what you are working on."

1. Progress: We discussed the need to get clarification from Fang on what we need to do next re the FK id in the comment above. Epic: Audit differences between code and documented field names #432 (comment) @Neecolaa will follow up with him.
2. Blockers: time
3. Availability: Monday meetings
4. ETA: we will never finish this 💀💀💀💀

[ExperimentsInHonesty]

@Neecolaa will look for an epic and if there isn't one, make one

• Update Schema: User model #436
• Update Table: User #429
• Update Table: user (replace role association with practice area) #172 - does not have table, might be old
• Update Table: project #227 - does not have table, might be old

The issues may need to be redone to deal with any guidance we get from Fang re field names with "id" in them

[fyliu]

I think we should change that name (brigade_id to org_id) in the comment. Those are supposed to be placeholders for relationships with models that don't exist yet. The code should be in the completed model, but we can't add them yet. But we also want to close the issue as complete, so we add them as comments.

These comments should only exist in models that we decided to have initially even though they depended on other models that didn't exist. So User, Project, Event I believe. Later create table issues used dependencies.

I see a couple of commented lines are probably safe to delete as well, like day_of_week, but we can also leave them for some audit issue before we release.

[ExperimentsInHonesty]

We decided the way to handle if a table creation has a FK, then add this text to the issue, and that will provide instructions on what the developer should do, to clear the error and make sure that their comments get uncommented when the FK table is created.

Action Items

Add links to issues

• Go to this link: Issues tab, label: needs FK text
• Find the FK references.
• Find the related table issues (using issue tab, spreadsheet)
• If the issue has a table format, we will need to add 2 extra columns for the FK designation and the issue link. See example of table issue
• Add the links to the issues next to the FK item
• If the issues found are all closed, then remove the label
• if any of the issues are open, add the text below.

Update issue templates

• Table creation issue template change needed
  • All issues need to be formatted like this (with table) in the future Update Table: User #429
    • file to update: https://github.com/hackforla/peopledepot/blob/main/.github/ISSUE_TEMPLATE/create-table-issue-template.md
• Table update issue template change needed
  • we need to expand the table so that it has space for Key Type and FK issue(s)
    • file to update: https://github.com/hackforla/peopledepot/blob/main/.github/ISSUE_TEMPLATE/update-table.md

Resources

• Find table issues
  • Spreadsheet PD: Table and field explanations, Tables - has links to issues next to table names. Might be a little out of date, but worth checking if you can't find the issue.
  • Issue tab, label: table creation

Example

• See issue Create Table: project_stack_element_xref #205

Data Fields

For each of the FK below if the FK table has not yet been created (i.e, the issue is still open), you will need to

• comment out the code after you create it
• add an action item on the open issue to uncomment the code line you commented out when that issue's table is created.
• Provide your file and line number as a permalink under resources in that issue

1. New fields
   • (PK) id - int - Record Id
   • (FK) project_id - int (Create Table: project #16)
   • (FK) stack_element_id - int - Record Id (Create Table: technology #39 initial model, Update Table: technology (rename to stack_element) #204 modification)

Copy text

For each of the FK below if the FK table has not yet been created (i.e, the issue is still open), you will need to
 - comment out the code after you create it 
 - add an action item on the open issue to uncomment the code line you commented out when that issue's table is created. 
 - Provide your file and line number as a permalink under resources in that issue