@merefield Could you give a summary of the current state of the user data model here, and some references to the relevant swagger docs? We need a centralised overview for future building, both on the dev side of things, but also for PMs to understand what they’ve got to work with.
First thing to note:
- the data model is mostly only built out in so far as to support the current front end (so we don’t have a situation where we have “unexercised” functionality in Production).
- it is largely unchanged from the general concept used by the original user-api.
Key TODO’s include:
- data privacy customisation: there is currently no user discretion on what is private, what is not.
- location management (there’s a country code implemented, but no street address management at time of handing over).
The main tables are:
- User - one row per User (no matter how many persona’s they have). This includes the users Role. A user can only have one Role (Listener, Artist, Label, TenantAdmin, Admin, SuperAdmin)
The full list of Roles and Scopes is maintained in this file:
- UserGroup - a User is allowed to own more than one UserGroup of type ‘persona’ if an Artist, allowing someone to have multiple “appearances”. This is where profile attributes like banner and avatar are stored (these specifically are UUID’s that map to the image store, @auggod can expand on that). UserGroup also allows a Label to own a group of artists, etc.
User-API owns all user account tables, including those required by to manage authentication:
The swagger file is generated here:
And is viewable online when running that server.
However, @auggod aims to merge this swagger with id’s etc. with a separate process for Production and UAT.
We need a country code for location management for rights purposes, but I think the street address management could be handled better by SAAS like Stripe. The same for payment cards and bank details.