...
A user should only need to register once (per email address)
When logging in, active users can choose one of their existing farm associations or to define a new farm and association
When being invited to play a role at a farm, an existing user can add the new role to their existing roles
...
^ Registration flow
...
^ Multi-farm log-in flow
...
^ Receiving an invitation flow
Architectural Guidance
...
High level architecture guidance
...
Open Questions | Discussion | Decisions |
|---|---|---|
Where should user settings / configurations be held? | It depends. Obviously user-centric configurations such as language should be held on the user. Settings that may vary from role to role, such as permissions to read/write should be stored on the user-farm. Other, farm specific settings such as measuring system* and currency should be stored on the farm settings. | |
Can a user play more than one role at a single farm? | Depends on our implementation of RBAC. HW: a manager will also want be able to log hours of ‘work’. role might also change over time. What is important is that the primary farm account (i.e the ‘owner’) controls who has access at any given point, and can invite/reject other users from the main farm account. So what would that process look like where a primary farm ‘invites’ people as workers, technicians, researchers, etc, to ‘join their farm team’ in a particular role? |