Extent of request edit rights task
Background
“If other users wish to edit a deck then they must request edit rights from the Creator. This notified the deck creator by email who are directed to add the use to those who have rights to edit their deck. Alternatively, a user can fork the deck to create their own version where they are the deck creator and can manage who has rights to edit the deck.”
In general this tasks involves more work than just sending an email. In this discussion the exact plan for SWIK-1735 should be decided as well as the future work for this task. The notification server will be changed/enhanced in the future thus we need to decide what should be done now and what while the change of the notification service.
User story:
I as an signed in user, want to send a request for editing rights of a deck to an owner to which I have no edit rights. I click on Edit Deck and then on Request Edit Rights. I get a visual feedback if it was successful or not. The deck owner should get an email and a notification from my request. When the edit rights were granted I will see a notification and have edit rights to the deck.
Short/Intermediate solution:
The userservice gets a route (secured with JWT) for sending emails to a specific user. The deckservice get a new route (secured with JWT) for managing edit right requests. The platform acts as a coordinator and uses the userservice to send emails plus the deckservice to manage rights requests.
The email will be send to the deck owner and will contain a link for adding the user as a editor. The links directs to the deck edit view but with query parameters which will trigger rights checking and asks via a modal if the user should be added as editor.
Final version:
Kostis and Kurt already discussed the perfect workflow, here is a summary:
a) the notification service stores and handles custom notifications; in this case, an object that says user a wants edit rights for deck b owned by user b. There should be no duplications (instead renewing)
b) This object is a "request" that should also be handled separately by deck service, so that: (1) a user has a list of requests he has sent out and (2) a user has a list of requests directed to him concerning one of his decks
c) a user that sends out the request should have an option to revoke it
d) a user that receives the request should be able to either (1) grant it or (2) reject it with a simple click
e) when a deck owner visits the deck permissions (currently the deck metadata page) they should be presented with users that have requested access and also either grant or reject access there
f) The user who requested the rights will get a notification how the deck owner had decided
This includes much more work and the precondition is SWIK-1684.
The notification part is not done. The rest is already deployed.