Update Table: User

[ExperimentsInHonesty]

Overview

We need to update the User table model to include new fields and have the correct names for fields.

Details

• The initial model issue: #15

Action Items

Update existing Django model

• [ ] In the files indicated by Resource 1.01, Change the following items in the code

Current name in code	Updated Name	Updated Type (may already be this type)
current_job_title	job_title_current_intake	varchar
email	email_intake	EmailField
first_name	name_first	varchar
gmail	email_gmail	EmailField
is_active	user_status_id	int
last_name	name_last	varchar
preferred_email	email_preferred	EmailField
target_job_title	job_title_target_intake	varchar

• [ ] Add the following items in the code

Name	Type
practice_area_primary	int (practice_area_primary)
practice_area_secondary	int[] (practice_area_secondary)
practice_area_target_intake	int[] (practice_area_target_intake)
referred_by	int
email_cognito	EmailField

• [ ] Write a test for the new relationships this model will have with other models (e.g., creating a user and assigning them a set of permissions on a project) if any.
• [ ] Update API end point
• [ ] Update API unit tests
• [ ] generate a schema table definition and post it in a comment below and add a link to it in the Update Schema dependency issue.
• [ ] Document the endpoint in ReDocs

After PR has been approved

• [ ] Release the dependency and move the issue out of the icebox for #436

Resources

• 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, User view filter

[fyliu]

User fields as of 2024-11-14

[shmonks]

@Neecolaa and @ExperimentsInHonesty to review current column fields

[shmonks]

We need to add a Cognito email field in this table, and change 'email' to intake_email

---

We decided to rename all the emails Noun - Adjective e.g., email_intake, email_gmail, email_cognito, etc.

[fyliu]

@Neecolaa The following is not part of this issue, but the table made me think of something else. Can we add descriptions to all the columns to help developers using the API figure out how they should use them? Something like this example I made up?

I bolded the target column names to make them more noticeable.

I think the developer should also generate and post a schema image of the table like I did above but in the PR.

Current name in code	Updated Name	Updated Type (may already be this type)	description
first_name	name_first	varchar	User's first name
last_name	name_last	varchar	User's last name
created_date	created_at	DateTimeField	Auto-generated date and time when user was created
is_active	user_status_id	int	User active status. This is determined by <...>
current_job_title	intake_job_title_current	varchar	The job title when first joined the organization. This is not updateable by the user later.
target_job_title	intake_job_title_target	varchar	The user's target job title when first joined the organization. This is not updateable by the user later.

The description would show up in the API docs like the "Event name" in this example:

[ExperimentsInHonesty]

@fyliu @ethanstrominger Do you know what are these fields for: is_staff is_superuser

Re the comment above about putting descriptions. We will do that on another epic, once we get all the table changes with the correct field names made.

Can we add descriptions to all the columns to help developers using the API figure out how they should use them? Something like this example I made up?

Current name in code	Updated Name	Updated Type (may already be this type)	description
first_name	name_first	varchar	User's first name
last_name	name_last	varchar	User's last name
created_date	created_at	DateTimeField	Auto-generated date and time when user was created
is_active	user_status_id	int	User active status. This is determined by <...>
current_job_title	intake_job_title_current	varchar	The job title when first joined the organization. This is not updateable by the user later.
target_job_title	intake_job_title_target	varchar	The user's target job title when first joined the organization. This is not updateable by the user later.

[fyliu]

@ExperimentsInHonesty Those are what django uses in the default model. See link to reference.

is_staff:

• Boolean. Allows this user to access the admin site.

is_superuser:

• Boolean. Treats this user as having all permissions without assigning any permission to it in particular.

is_staff currently has a description in peopledepot that we can update: "Designates whether the user can log into this admin site."

---

I said there's no way to get the text-only description before. But I forgot about just asking the database for it. Maybe the developer making the change can do a before and after output of this? I can provide this for the other tables as well.

Here's what the user table is defined as in the database currently:

                           Table "public.core_user"
      Column       |           Type           | Collation | Nullable | Default 
-------------------+--------------------------+-----------+----------+---------
 password          | character varying(128)   |           | not null | 
 last_login        | timestamp with time zone |           |          | 
 is_superuser      | boolean                  |           | not null | 
 uuid              | uuid                     |           | not null | 
 created_at        | timestamp with time zone |           | not null | 
 updated_at        | timestamp with time zone |           | not null | 
 username          | character varying(255)   |           | not null | 
 is_active         | boolean                  |           | not null | 
 email             | character varying(254)   |           | not null | 
 is_staff          | boolean                  |           | not null | 
 current_job_title | character varying(255)   |           | not null | 
 current_skills    | character varying(255)   |           | not null | 
 first_name        | character varying(255)   |           | not null | 
 github_handle     | character varying(255)   |           | not null | 
 gmail             | character varying(254)   |           | not null | 
 last_name         | character varying(255)   |           | not null | 
 linkedin_account  | character varying(255)   |           | not null | 
 phone             | character varying(128)   |           | not null | 
 preferred_email   | character varying(254)   |           | not null | 
 slack_id          | character varying(11)    |           | not null | 
 target_job_title  | character varying(255)   |           | not null | 
 target_skills     | character varying(255)   |           | not null | 
 texting_ok        | boolean                  |           | not null | 
 time_zone         | character varying(63)    |           | not null | 
Indexes:
    "core_user_pkey" PRIMARY KEY, btree (uuid)
    "core_user_username_36e4f7f7_like" btree (username varchar_pattern_ops)
    "core_user_username_key" UNIQUE CONSTRAINT, btree (username)
Referenced by:
    TABLE "core_user_groups" CONSTRAINT "core_user_groups_user_id_70b4d9b8_fk_core_user_uuid" FOREIGN KEY (user_id) REFERENCES core_user(uuid) DEFERRABLE INITIALLY DEFERRED
    TABLE "core_user_user_permissions" CONSTRAINT "core_user_user_permissions_user_id_085123d3_fk_core_user_uuid" FOREIGN KEY (user_id) REFERENCES core_user(uuid) DEFERRABLE INITIALLY DEFERRED
    TABLE "core_userpermission" CONSTRAINT "core_userpermission_user_id_2b95370e_fk_core_user_uuid" FOREIGN KEY (user_id) REFERENCES core_user(uuid) DEFERRABLE INITIALLY DEFERRED
    TABLE "django_admin_log" CONSTRAINT "django_admin_log_user_id_c564eba6_fk_core_user_uuid" FOREIGN KEY (user_id) REFERENCES core_user(uuid) DEFERRABLE INITIALLY DEFERRED

The steps to get this are below:

• How to get the database table definition

  # run this to enter the database in the docker container
  ./scripts/db.sh
  
  # within the database
  
  # get the list of tables
  # "describe tables"?
  \dt
  
  # get the details of a table
  # "describe table"?
  \d core_user

  # or as one command:
  ./scripts/db.sh -c "\d core_user"
  
  # optional get all the table names
  ./scripts/db.sh -c "\dt"

[fyliu]

@ethan pointed out that is_staff and is_superuser are internal data and don't need to be exposed to the API client. They can find out who the adminGlobals are from the user_permission rather than the user table.