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, which is called by the platform and uses the userservice to send emails. This could not done by the platform because first of all the platform does not have all the data needed (like email of the deck owner) and second of all its not the domain of the platform.
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.