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

• identify if table has a description (see spreadsheet under Resources)
  • if not, reach out to PD leads
• identify and document (below) what other tables are associated (see ERD under Resources)
• create a single model in Django (defining schema)
• 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
• Write an API end point
• write API unit tests
• 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.

   • id
   • name_first
   • name_last
   • gmail
   • preferred_email
   • created
   • user_status_id (FK)
   • practice_area_current
   • job_title_current
   • practice_area_target
   • job_title_target
   • desired_roles
   • availability - this has been converted into a related table user_availability
   • current_skills
   • target_skills
   • linkedin_account
   • referred_by (FK)
   • github_handle
   • phone
   • texting_ok
   • slack_id
   • time_zone
   • conduct - 8/10 meeting: Nicole informed that this was converted to the more generic user_check record
   • updated
   • 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

   • cancelled_event (one-to-many)
   • check_in (one-to-many)
   • permission (one-to-many)
   • permission_history (one-to-many)
   • user_availability (one-to-many)
   • user_check (one-to-many)
   • user_employment_change (one-to-many)
   • win (one-to-many)
   • 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

   • practice_area (many-to-many)
   • 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

• api tests
• final adjustments to the model definition if any
• 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