You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
If the application has to do different things depending a users state/roles, then we can implement these roles.
This allows the frontend to implement UI based on the roles, and not re-implement the logic from the backend to decide what the user can do.
if a group has an active agreement set, then only users that have agreed to it should be able to do pickups
otherwise the user should be able to do pickups
It means more bureaucracy to manage the roles for the users (e.g. when there is no agreement all the users need to have that role, and when you add an agreement, all those roles go away), but it seems like it should be a good approach.
We don't have a clear concept if this role is actually needed, so discussion should go back to #324
It might also be connected to #546, but requirements haven't been specified there either.
(Originally written by Nick, moved from https://github.com/yunity/karrot-backend/issues/419)
If the application has to do different things depending a users state/roles, then we can implement these roles.
This allows the frontend to implement UI based on the roles, and not re-implement the logic from the backend to decide what the user can do.
It means more bureaucracy to manage the roles for the users (e.g. when there is no agreement all the users need to have that role, and when you add an agreement, all those roles go away), but it seems like it should be a good approach.
Related to #324 (comment)
The text was updated successfully, but these errors were encountered: