Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Update User Database Model to Include User Types #655

Closed
Joshua-Douglas opened this issue Feb 10, 2024 · 5 comments · Fixed by #668
Closed

Update User Database Model to Include User Types #655

Joshua-Douglas opened this issue Feb 10, 2024 · 5 comments · Fixed by #668
Assignees
Labels
p-Feature: Dashboard Coordinator points: 5 Can be done in 19-30 hours Role: Back End Section: 1 Related to Major Flows Section 1: Account Creation
Milestone

Comments

@Joshua-Douglas
Copy link
Member

Joshua-Douglas commented Feb 10, 2024

Overview

The current user model does not differentiate between user types, and only includes the username and email. To implement the coordinator dashboard requirements, outlined in #501 and #651, we need to make the following changes to our database:

  • Update the User model to include first and last name
  • Update the User model to include account type (Guest, Host, Coordinator, Admin)
  • Update Guest, Host and Coordinator models to allow for the following relationships:
    • Coordinators can have 0 or more Guests
    • Coordinators can have 0 or more Hosts
    • Guests can have 0 or 1 Coordinators
    • Guests can have 0 or 1 Hosts
    • Hosts can have 0 or more Guests
    • Hosts can have 0 or 1 Coordinators

To facilitate these changes we will need to update the SignUp endpoints to specify the role type, first name, and last name. None of our endpoints support creating an association between users, so we will need to add this capability in a future issue.

Action Items

  • (Required) Update User models to include user types, and to define the user relationships
  • (Required) Write test cases to verify that we can store and retrieve users from the database
  • (Required) Update the SignUp endpoints to include basic user info, and the user type
  • (Optional) Write a script that uses faker to populate a test database with these relationships in place. We already have a collection of test users. It would be useful to load useful data for these users.
  • (Optional) Add middleware to validate role-based access. In general guests and hosts should only be able to access their own info. Coordinators have elevated access.
  • (Optional) Add endpoints to query the user assignments. We could do these:

Optional Assignment Endpoints

  1. Get a Coordinator's Assigned Guests and Hosts
  • Endpoint: /coordinators/{coordinator_id}/assignments
  • Method: GET
  • Description: Retrieves both the guests and hosts assigned to a specific coordinator. The response could be structured to include separate lists for guests and hosts.
{
  "coordinator_id": 1,
  "guests": [
    {
      "user_id": 2,
      "first_name": "John",
      "last_name": "Doe",
      "host_id": 4
    },
    {
      "user_id": 3,
      "first_name": "Jane",
      "last_name": "Doe",
      "host_id": 5
    }
  ],
  "hosts": [
    {
      "user_id": 4,
      "first_name": "Host",
      "last_name": "One"
    },
    {
      "user_id": 5,
      "first_name": "Host",
      "last_name": "Two"
    }
  ]
}
  1. Get a Guest's Coordinator and Host
  • Endpoint: /guests/{guest_id}
  • Method: GET
  • Description: Retrieves details of a specific guest, including their assigned coordinator and host.
{
  "user_id": 2,
  "first_name": "John",
  "last_name": "Doe",
  "coordinator": {
    "user_id": 1,
    "first_name": "Coordinator",
    "last_name": "One"
  },
  "host": {
    "user_id": 4,
    "first_name": "Host",
    "last_name": "One"
  }
}
  1. Get a Host's Coordinator and List of Guests
  • Endpoint: /hosts/{host_id}
  • Method: GET
  • Description: Retrieves details of a specific host, including their coordinator and a list of assigned guests.
{
  "user_id": 4,
  "first_name": "Host",
  "last_name": "One",
  "coordinator": {
    "user_id": 1,
    "first_name": "Coordinator",
    "last_name": "One"
  },
  "guests": [
    {
      "user_id": 2,
      "first_name": "John",
      "last_name": "Doe"
    },
    {
      "user_id": 3,
      "first_name": "Jane",
      "last_name": "Doe"
    }
  ]
}
@Joshua-Douglas Joshua-Douglas added Role: Back End p-Feature: Dashboard Coordinator milestone: missing points: 5 Can be done in 19-30 hours Section: 1 Related to Major Flows Section 1: Account Creation labels Feb 10, 2024
@Joshua-Douglas Joshua-Douglas self-assigned this Feb 10, 2024
@Joshua-Douglas Joshua-Douglas added this to New Issue Approval in HUU: Project Board via automation Feb 10, 2024
@Joshua-Douglas
Copy link
Member Author

Our current data model contains a lot of unused data models. I'm planning to remove each of the unused data models. We haven't tested these unused models, so it is unclear if they work at this point. We can always recover from the version history.

HUU_DataModel_Before

@erikguntner
Copy link
Collaborator

@Joshua-Douglas thanks for outlining all this. For the first PR let's limit the scope to:

  • Updating the User model to include first_name, last_name, and type
  • Updating routes that create a user to set the first_name, last_name, and type. Those routes should be: /auth/signup/host, /auth/signup/coordinator, and /auth/invite

We can save assigning coordinators to hosts and guests as well as doing a data model cleanup for another PR.

I'm thinking for the user types we can create a user_types table that associates each type with an id and then use that id as the value for the type property on the user data model. Something like this:

erDiagram
    USER ||--|| USER_TYPES : has
    USER {
        int id PK
        string first_name
        string last_name
        string email
        int type_id FK
    }
    USER_TYPES {
        int id PK
        string type "guest, host, coordinator, or admin"
    }

That way if we want to add more user types or change the value of the types we only have to do it in one place. Thoughts?

@Joshua-Douglas Joshua-Douglas changed the title Update User Database Model to Include Update User Database Model to Include User Types Feb 12, 2024
@agosmou
Copy link
Member

agosmou commented Feb 18, 2024

@Joshua-Douglas

Our current data model contains a lot of unused data models. I'm planning to remove each of the unused data models. ... We can always recover from the version history.

Love this house-keeping.

I was thinking of how to easily indicate a major change in the db models...

Perhaps we use the "Feature: Refactoring" label on the PR (source here) or otherwise come up with a more descriptive one. If you have another suggestion, I'd love to hear it!

@Joshua-Douglas
Copy link
Member Author

Hey, good idea @agosmou. I labelled with the "Feature: Refactoring" per your suggestion.

I might be worth adding a "data model update" label to differentiate db model changes, since database changes will require a migration script once we have a production database with useful data.

@Joshua-Douglas
Copy link
Member Author

@Joshua-Douglas thanks for outlining all this. For the first PR let's limit the scope to:

  • Updating the User model to include first_name, last_name, and type
  • Updating routes that create a user to set the first_name, last_name, and type. Those routes should be: /auth/signup/host, /auth/signup/coordinator, and /auth/invite

We can save assigning coordinators to hosts and guests as well as doing a data model cleanup for another PR.

I'm thinking for the user types we can create a user_types table that associates each type with an id and then use that id as the value for the type property on the user data model. Something like this:

erDiagram
    USER ||--|| USER_TYPES : has
    USER {
        int id PK
        string first_name
        string last_name
        string email
        int type_id FK
    }
    USER_TYPES {
        int id PK
        string type "guest, host, coordinator, or admin"
    }

That way if we want to add more user types or change the value of the types we only have to do it in one place. Thoughts?

Hey @erikguntner,

I think that is a great way to structure it. I implemented that approach in 18b427a.

Existing users did not have a user role or name, so I assigned them to the guest role with names "Unknown". Now that the "host" user type is stored as a role we no longer need the Host table. I am deleting the host table, and I'll update the host endpoints to use this new role type before sumitting a PR.

HUU: Project Board automation moved this from New Issue Approval to Done Apr 14, 2024
@sanya301 sanya301 added this to the 6- MVP milestone May 14, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p-Feature: Dashboard Coordinator points: 5 Can be done in 19-30 hours Role: Back End Section: 1 Related to Major Flows Section 1: Account Creation
Projects
Development

Successfully merging a pull request may close this issue.

4 participants