Create Table: User

[ExperimentsInHonesty]

Overview

We need to create the User table so that we can automate user permissions and accounts creation

Details

A table and a model are the same thing

Action Items

• [x] identify if table has a description (see spreadsheet under Resources)
  • [ ] if not, reach out to PD leads
• [x] identify and document (below) what other tables are associated (see ERD under Resources)
• [x] create a single model in Django (defining schema)
• [x] Write a test for the relationships this model will have with other models (e.g., creating a user and assigning them a set of permissions on a project). - no relationships yet since this is the only model
• [x] Write an API end point
• [x] write API unit tests
• [x] Document the endpoint in Swagger

Resources/Instructions

• See People Depot Resources wiki page for links

Items to document (referenced above)

Description

• List of users

Data Fields

1. Copied from spreadsheet and checked off according to ERD. Data fields are bolded and relation fields are not.

   • [x] id
   • [x] name_first
   • [x] name_last
   • [x] gmail
   • [x] preferred_email
   • [x] created
   • [x] user_status_id (FK)
   • [x] practice_area_current
   • [x] job_title_current
   • [x] practice_area_target
   • [x] job_title_target
   • [x] desired_roles
   • [ ] availability - this has been converted into a related table user_availability
   • [x] current_skills
   • [x] target_skills
   • [x] linkedin_account
   • [x] referred_by (FK)
   • [x] github_handle
   • [x] phone
   • [x] texting_ok
   • [x] slack_id
   • [x] time_zone
   • [ ] conduct - 8/10 meeting: Nicole informed that this was converted to the more generic user_check record
   • [x] updated
   • [x] password - this is not used with Cognito authentication

2. In ERD only - none

3. Combined table

name	Data	Rela.	in ERD	in sheet	notes
id	x		x	x	PK
name_first	x		x	x
name_last	x		x	x
gmail	x		x	x
preferred_email	x		x	x
created	x		x	x
job_title_current	x		x	x
availability	x			x	this has been converted into a related table user_availability
current_skills	x		x	x
target_skills	x		x	x
linkedin_account	x		x	x
github_handle	x		x	x
phone	x		x	x
texting_ok	x		x	x
slack_id	x		x	x
time_zone	x		x	x
conduct	x			x	8/10 meeting: Nicole informed that this was converted to the more generic user_check record
updated	x		x	x
password	x		x	x	this is not used with Cognito authentication
user_status_id		x	x	x	FK
practice_area_current		x	x	x
practice_area_target		x	x	x
desired_roles		x	x	x
referred_by		x	x	x	FK

Associated Tables

1. Copied from spreadsheet and checked off according to ERD

   • [x] cancelled_event (one-to-many)
   • [x] check_in (one-to-many)
   • [x] permission (one-to-many)
   • [x] permission_history (one-to-many)
   • [x] user_availability (one-to-many)
   • [x] user_check (one-to-many)
   • [x] user_employment_change (one-to-many)
   • [x] win (one-to-many)
   • [x] user_status_type (many-to-one)
   • [ ] project (array of IDs) - this has been converted to a sort of junction table called permission in the ERD

2. In ERD only

   • [x] practice_area (many-to-many)
   • [x] referrer (many-to-one)

Swagger Endpoint Link

-

[fyliu]

It would be nice if all data fields have

1. default values
2. if it can be empty or not
3. varchar size
4. uniqueness constraint

I read that using UUID for primary key is the best thing to do and doesn't impact performance if we're using postgres

I see array fields that represent a list of PK of other models. Should they be made into model relations like one-to many?

[fyliu]

From today's meeting I think we settled on these

1. Use UUID as model index to simplify things.
2. The int array fields represent many-to-many relationships that I just didn't recognize before.
3. varchar size could be something like 50 for gmail, for example, or maybe 255, which is a common value.
4. Ask Nicole and Bonnie about nullable fields, uniqueness constraints, and default values for the fields.

[fyliu]

I've neglected this for a while but I'm much more confident now, having read through a few more books on django and drf.

I recently worked on

1. creating the API
2. limiting viewable fields for the API
3. setting up API docs using drf-spectacular
4. generating ER diagrams from django models

I expect to have this complete in the next week.

Things that need to be done

• [x] api tests
• [ ] final adjustments to the model definition if any
• [x] add custom type fields like phone number and timezone

Things for the future

• [ ] model relations to undefined models
• [ ] limit API actions to maybe disable delete or perform soft delete

[fyliu]

Just a note in case anyone really wants to try fixing this. It doesn't affect the application at all except the swagger doc shows time_zone as string type instead of timezone.

I'm using this timezone field extension and drf-spectacular (generates swagger docs) is not able to recognize it correctly. https://github.com/mfogel/django-timezone-field

There's documentation on how to customize it but I don't think we want to do that at this point. https://drf-spectacular.readthedocs.io/en/latest/customization.html

[fyliu]

Need to review the description

• missing "conduct" field