...
SWIK-740 (service) and SWIK-741 (frontend) are ticket tickets 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
- Any 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.
Deck definitions:
private deck = a deck that is not listed, branched and only the owner has editing rights. It is proposed that a private deck can be deleted (e.g if an owner abandons a deck half way through creating it).
restricted deck = a deck that is not listed. It may be a branch of a public deck
public deck = as per beta releaseIn detail it is really complex. With this complexity there were three versions of the deck edit rights.
Version 1:
Having public, restricted and private decks. Each editor of a deck has her/his own revision of the deck. A public deck could be edited by everyone, a restricted deck just by the owner and by authorized users. These restrictions could only be changed by the deck owner.
Here the removal of illegal/corrupt content is not easy and there is much metadata of each deck revision needed to handle edit rights and deletion.
Revisions are created when a public deck is changed by a (could be anyone) user and when a restricted deck is changed by the owner (owner could also save to current revision) of the deck or an authorized user. Its not already defined how a revision of a restricted deck created by an authorized user should be handled when this user updates it (save versus save as new revision). I am not aware of the code which handles the route "/deck/needsNewRevision" - please decide by yourself how to change the code.
Just the owner of a deck is able to change the edit rights. Thus no authorized user is able to do this. Also each revision of a deck have to link to / save the origin edit rights. A change of these rights have to be pass to all revisions. It should be possible to revoke edit rights for a user for all revisions (which are children of the revision where the edit rights were added)
The handling of translation is not decided yet.
Private and restricted decks are not part of search results.
Version 2:
The owner of a deck is the only person who is able to change the deck and other people could provide change requests.
That means that if the non owner changes the deck it is forked. Then specific changes/parts of the deck could be proposed as changes to the owner of the original deck.
Also the forked deck could get change requests from the origin deck or their owners.
For this we need a kind of a merge tool in the frontend (should work with the change log as proposed in Deck branching when forking a deck ).
With this proposal we have also a contributor list because the change log contains the author.
Deleting is no problem here: If there is a reason to delete a deck we could delete the deck without destroying other decks and stuff. If a deck is corrupt/illegal then we delete it and mark all forks of it as possible corrupt/illegal. This is technical possible if each fork contains metadata about the forking history (origin, fork1, fork2, ...) which shouldn't be a problem.
For the trial partners it could be helpful if a deck has a progress attribute with the values draft, open for requests and fine for now plus the deck has the option to be hidden for search results.
Summarized its compliant with the old SlideWiki: a change gives a user three options: perform minor edit, apply for membership and create a new revision/copy.
Version 1.1:
Definition is ongoing - See Kostis comment from the Feb 24, 2017.
Revisioning terminology
We need to have clear and easy to understands terms for users. "Branch" and "fork" are not in common usage within UIs but "version" is. "Revision" has a number of meanings and so is confusing. We need terminology for:
...
- 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)?