Unify User Model #1648
Description
Multi-Table-Inheritance for participations creates a lot of indirection in ephios, but is helpful to keep track of the corresponding user-identifying model (local, FederatedUser, GuestUser). Reverse behavior is managed by participant dataclasses, that control which views, models and icons are used for signing up and managing participations. The system is very exensible, but makes duplicating behaviors necessary if we want to share features accross participant types.
We could unify FederatedUsers, GuestUser and Participants to also be a UserProfile.
- wouldn't need MTI for participation model
- wouldn't need participant model (could store qualifications on UserProfile, but would have to use QualificationGrants)
- could use Groups to orchestrate event visibility for Federated/Guest users. might need a replacement of Djangos Group model to get
- custom managers for Group, so we could seperate "local" groups from special groups for federation or Guests
- additional fields on Group, like whether the name can be changed by users or is managed by a plugin
- UI changes to distinguish types of group
- would allow to change type of user, e.g. convert a Placeholder to an active User
- would allow reusing GuestAccounts and Placeholders accross events
- would need to rebuilt Guest and Federation entrypoints
- might need UI tweaks for federated users to be aware that they are on a different server
- How would we handle consequences for federated users? Would they still be moved to the original server or stay at the host or both?
Would we want to split off auth info from profile info?
How can we control behavior of the User model based on it's type in various places (in an extensible way)?
- deciding what to do on consequence approval?
- displaying its user (e.g. with additional info about originating server, icon choice, ...)
- ...
- --> feels like it should be their own class, but we want to avoid MTI esp. in the user model. What patterns fit this problem? some form of Behavior injection?