Room moderators

Allow room owners to select multiple users as moderators.

Proposal:

• Add a new property moderators of type List<String> which will contain user IDs to Room entity for internal use/persistence only.
• Add new API endpoints:
  • GET /room/<Room ID>/moderators
    Response body: [{"userId": "<User ID>", "roles": ["<Role>"]}]
  • PUT /room/<Room ID>/moderators/<User ID>
    Request body: {} (adds default role EXECUTIVE_MODERATOR) or {"roles": ["<Role>"]}
  • DELETE /room/<Room ID>/moderators/<User ID>
• Add new UserFindQuerySerivce to lookup user ID by login ID.
• Moderators have the same permissions as the owner but cannot delete the room.
• Adding different roles for moderators might be useful but I wouldn't include this in an initial implementation.
• Roles:
  • EDITING_MODERATOR has almost all permissions the owner has (cannot delete room).
  • EXECUTIVE_MODERATOR has moderating permissions (delete comments/answers).
    (NYI for comment micro service, 07.07.19)

@cthl58 @lmas60 @tksl38: Any thoughts?

Edit (03.06.): Frontend-Workflow to add new mods:

1. Room owner enters loginId of the new mod
2. FE looks up userId via POST request to /user/find:

   {
     "properties": {
       "loginId": "..."
     }
   }

3. FE receives list of users (loginId alone is not unique)
4. FE sends PUT request to /room/<room ID>/moderator/<user ID>

added api enhancement labels

changed milestone to %3.0-beta1

changed the description

Sounds good. Will the moderators be returned on a GET request for a room?

No, I wouldn't include them because:

• persistence and public APIs do not match here
• moderator data is probably only relevant once or twice when setting up the session

There might be some use cases like listing moderators in a room overview but I'm not sure if something like this is useful for ARSnova.

changed the description

I don't think we need it in the room overview either.

changed the description

Implemented by !131 (merged).

closed

@dgrh99 If i request the moderators in the backend i get moderator objects like the following:

[{"userId":"7556b17438ed3fae5d95080813012333","roles":["EXECUTIVE_MODERATOR"]}]

According to the description above you get userId and loginId, is that out of date?

I've updated the description to match the implemented behavior.

You can retrieve user details via the /user endpoint:
/api/user/?ids=<User Id>,<User Id>,...

changed the description

changed the description