Background
SWIK-740 (service) and SWIK-741 (frontend) are ticket for the implementation.
While implementing and discussing it, we noticed it is very complex and depends on the deck revision/fork handling.
User group discussion: Groups of Users
Deck branching/forking discussion: Deck branching when forking a deck
Current State:
- A user can create user groups, join, leave and delete them
- Forking a deck results in a new revision of the deck
- Each user is able to create a new revision of a deck
- All Deck contributors are able to update a revision
Target:
- Give a deck a general access level: public, restricted, private
- Access level restricted: Users and groups could be choosed, ẃhich then have edit rights for the deck revision
- All existing decks are public
- if a deck is private or the user is not part of the restricted set, then the user is not able to edit the deck (or the content)
We should use the current code as orientation but as this is a main feature we should concern the real life scenarios.
Action items
- Who should be able to fork a restricted/private deck?
- Should it be possible to branch(revision) a restricted deck? By Whom?
- Who is allowed to change the edit rights?
- Should this workflow just appear in the frontend or also in the service/API?
- Does edit rights works together with the current forking approach (creating a revision)?