Add User, School, Provider models and default scopes

[elceebee]

Context

Setting up some of the basic data structures before proceeding with feature work.

I decided it made sense to do this as a separate PR before proceed with logging in as a support user.

Changes proposed in this pull request

No UI changes. The only change to existing functionality is to add the service to the seeded personas.

Guidance to review

Pull and run the migrations and seed the database.
Have a look at the erd in this PR -- they should reflect the agreed approach. #30

Note: Not everything in the erd is here -- I haven't included the membership model because that is outside of the scope of what I'm working on (support users will have access to all the schools and providers, not through membership). I can add it for completeness if people think it would be useful. Otherwise, happy for someone to do it when it becomes more relevant.

Link to Trello card

https://trello.com/c/SX3aODZS

Things to check

• [NA] If the code removes any existing feature flags, a data migration has also been added to delete the entry from the database
• This code does not rely on migrations in the same Pull Request
• If this code includes a migration adding or changing columns, it also backfills existing records for consistency
• If this code adds a column to the DB, decide whether it needs to be in analytics yml file or analytics blocklist
• [NA] API release notes have been updated if necessary
• [NA] If it adds a significant user-facing change, is it documented in the CHANGELOG?
• [NA] Required environment variables have been updated or added to the Azure KeyVault

Screenshots

[Nitemaeric]

Based on the new support_user_enabled attribute, I have a few questions:

1. Will a User be allowed multiple roles?
2. Would we continue with this path to differentiate Provider users vs School users?

[elceebee]

Based on the new support_user_enabled attribute, I have a few questions:

1. Will a User be allowed multiple roles?
2. Would we continue with this path to differentiate Provider users vs School users?

1. Other than support, I don't think there are other roles. We have asked Simon a few times I think about whether or not there will be an 'admin' role -- someone who is able to add other users for schools, for instance. The answer, as I understand it, is that what a user can do will be based on the service / membership, not a specific role. I think SupportUser is unique as a role.
   If we think there are going to be other roles, using inheritance and scoping for the support user is probably not the right approach. I thought about having a separate SupportUser model (ie, placements_user has_one placements_support_user). Do you think that would be a more scalable approach?

2. I'm not sure what you mean. The user is scoped for service and then associated with organisations (that isn't represented here).

[elceebee]

Models and migrations to enable support user journey

[Nitemaeric]

1. Other than support, I don't think there are other roles. We have asked Simon a few times I think about whether or not there will be an 'admin' role -- someone who is able to add other users for schools, for instance. The answer, as I understand it, is that what a user can do will be based on the service / membership, not a specific role. I think SupportUser is unique as a role.
   If we think there are going to be other roles, using inheritance and scoping for the support user is probably not the right approach. I thought about having a separate SupportUser model (ie, placements_user has_one placements_support_user). Do you think that would be a more scalable approach?

I was thinking that, yeah. I'm just not sure if it's necessary or not. 🤔 I do think it's more modifiable though. There is a small db performance tradeoff by separating this context into a separate table though. I have seen AdminUser -> User in the past though and it's generally fine with the proper indexes and eager loading.

2. I'm not sure what you mean. The user is scoped for service and then associated with organisations (that isn't represented here).

I think the question is two-fold. 1) Are we planning to categorise users into School users vs Provider users? 2) If so, will we add an additional boolean attribute to signify those roles?

[elceebee]

1. Other than support, I don't think there are other roles. We have asked Simon a few times I think about whether or not there will be an 'admin' role -- someone who is able to add other users for schools, for instance. The answer, as I understand it, is that what a user can do will be based on the service / membership, not a specific role. I think SupportUser is unique as a role.
   If we think there are going to be other roles, using inheritance and scoping for the support user is probably not the right approach. I thought about having a separate SupportUser model (ie, placements_user has_one placements_support_user). Do you think that would be a more scalable approach?

I was thinking that, yeah. I'm just not sure if it's necessary or not. 🤔 I do think it's more modifiable though. There is a small db performance tradeoff by separating this context into a separate table though. I have seen AdminUser -> User in the past though and it's generally fine with the proper indexes and eager loading.

I suppose we could keep it as a bool for now and it would be a straightforward migration to move it to a separate table later if we find it's necessary. Perhaps it is wise not to anticipate complexity that may not actually exist. I'm happy to go either way. @ollietreend do you have a view?

2. I'm not sure what you mean. The user is scoped for service and then associated with organisations (that isn't represented here).

I think the question is two-fold. 1) Are we planning to categorise users into School users vs Provider users? 2) If so, will we add an additional boolean attribute to signify those roles?

Thanks for the clarification! I don't see where that will be necessary. They will be users for whatever organisation they have a membership to. And since that is a polymorphic association, the school-ness or provider-ness of the will be implied. Does that sound ok?

[ollietreend]

This is looking good – nice work. It's really nice to see our thoughts & plans about service namespacing taking shape in reality.

I've added a few comments, and I've "requested changes" because I think at least a couple of my suggested changes would be useful.

[Nitemaeric]

I suppose we could keep it as a bool for now and it would be a straightforward migration to move it to a separate table later if we find it's necessary. Perhaps it is wise not to anticipate complexity that may not actually exist. I'm happy to go either way. @ollietreend do you have a view?

👍 I'm good with keeping it a boolean for now. I'd also drop the _enabled as @ollietreend suggested.

Thanks for the clarification! I don't see where that will be necessary. They will be users for whatever organisation they have a membership to. And since that is a polymorphic association, the school-ness or provider-ness of the will be implied. Does that sound ok?

👍 Sounds good to me for now. This means that a user can potentially belong to both a School and a Provider.

[ollietreend]

This looks good to me ✨ 🚀