ortonomy
commented
7 years ago Hmm, good analysis.
This comment from a stakeholder is telling:
About registration: a. Can this be done a freelancer, or is it the responsibility of the freelancer manager to create new profiles? J: I feel it should be the freelancer manager. And some of the basic info may be able to be filled out by the freelancer or imported from a spreadsheet or something like that. M: Agreed, I don’t want freelancers having to use the system at all, unless they want to
For MVP, that means we're going to have one type of user: an admin who adds entities called freelancers to the system, BUT the freelancers themselves are not going to be users.
Of course in the future they're going to need to register, and mod their own details.
Wouldn't it be easier to have a user table that has a type flag, admin or freelancer. This is set on creation, and can be created by an admin in backend interface or on registration page on the front-end. Who generates the password is therefore a question of who creates the record, not the DB structure.
Based on the type, a column freelancerID column can be populated with a reference to the freelancer table that has all the freelancer related data and always logged in as a freelancer. If it's null && admin type, then they're logged in as admin.
Can still handle authentication in single table?
Specifically the user will never have a freelancerID for MVP, because all user will be admins.
Current proposal:
When a new freelancer is registered, a User account for that freelancer is generated using a default password. The freelancer is then able to log in as a User and view/edit their profile.
Benefits:
Cons:
(create_freelancer().then(create_user(freelancer)))