Participant types

[nickvergessen]

• Depends on Move database schema to migration #352
• Depends on Split API controller and clarify method names #349
• Set both participants as owner for new 1on1 calls
• Set creator as owner for new group/public calls
• Migration step to set owner on existing calls
• Endpoint to promote/demote participant to/from moderator
• Endpoint to remove a user from a room
• UI to promotion/demotion
• UI to remove a user from a room

Fix #297

@jancborchardt we need a UI to allow to promote users to moderators, demote them again and in the future also to remove users from a room. Do you have a good idea for a UI here? I think it would be nice if this was possible while being in a call, but it should also work when there is no call atm (to prepare it) and when the user is not part of the current call, which I think makes this a bit tricky. But maybe you have an idea?

When there is a call for participants I would suggest a dropdown on the name of the user, or a little triangle behind it.

@Ivansss what do you think, how should we set the owner on update for group rooms etc. I mean for 1on1 rooms we just set both as owners, when there is only one user in a room it's also easy. But what do we do with public/group rooms where there is more than one user? We don't know which user created it.

[jancborchardt]

When there is a call for participants I would suggest a dropdown on the name of the user, or a little triangle behind it.

Yup, exactly. :) Clicking on the username should open a popover menu. Just like we already do when screensharing to switch between screens, so we can extend that.

Good question for how we do that before the call. Let's for now just have it in the call, and make sure to remember the roles of people even if they disconnect and reconnect later, or the call is days apart. Ok?

[Ivansss]

But what do we do with public/group rooms where there is more than one user? We don't know which user created it.

Why don't we know that?

If a user create a group room by selecting directly a nextcloud group in the dropdown list, then we know who is doing that action and that user will be the owner.
Same if a user create a public room by clicking "New public call".

If a 1on1 room is upgraded to a group or public room, then the 2 participants of the 1on1 room are kept as the owners of the new group/public room.

[nickvergessen]

No I mean from current system upgraded to new. We don't know which user created a room. :/

[Ivansss]

Oh! I get it now 😄
Since there is no way to guess who was the creator of that already created rooms, I think we should assign a random owner or moderator to that rooms.
We will need a mechanism like that anyways for assigning new moderators when the last owner/moderator leaves a room.

[nickvergessen]

Right, we could make everyone a moderator. That would keep up the current behaviour.

From my idea the only difference between moderators and owners is, that owners can not be removed by moderators.

We will need a mechanism like that anyways for assigning new moderators when the last owner/moderator leaves a room.

Not really, I see two options:

1. Leave the room unchanged, people can still use it and talk, etc. Just not add more people
2. Delete the room, also fine by me since it's basically "moderator ended the call". But maybe 1 together with a "delete the call for everyone" option for owner/moderator is the better idea.

[nickvergessen]

@Ivansss I woould like to merge this now, and continue with the full participant list in a separate PR

[codecov]

Codecov Report

Merging #353 into master will decrease coverage by 2%.
The diff coverage is 0%.

@@             Coverage Diff              @@
##             master     #353      +/-   ##
============================================
- Coverage     14.32%   12.31%   -2.01%     
- Complexity      283      342      +59     
============================================
  Files            20       22       +2     
  Lines          1410     1640     +230     
============================================
  Hits            202      202              
- Misses         1208     1438     +230

Impacted Files	Coverage Δ	Complexity Δ
lib/Controller/RoomController.php	0% <0%> (ø)	93 <25> (+32)	⬆️
lib/Participant.php	0% <0%> (ø)	5 <5> (?)
lib/Migration/Version2001002Date20170707115443.php	0% <0%> (ø)	7 <7> (?)
lib/Room.php	0% <0%> (ø)	41 <10> (+9)	⬆️
lib/Manager.php	0% <0%> (ø)	45 <0> (+6)	⬆️
appinfo/routes.php	0% <0%> (ø)	0 <0> (ø)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 819d8b9...72dda3f. Read the comment docs.