Spreed: Synchronize group members in group chat continuously

[JLueke]

1268 already created the posibillity to invite groups to chat rooms, but the participiants in the chat room don't update if the members of the group change.

If a member leaves the group, he still is a participiant in the chat room.
If a user is added to the group, he won't be added as a participiant to the chat room as well.

I suggest that the participiants of a chat room are updated by the members of the group itself (groups?), if a group is added to the chat room.

[nickvergessen]

The problem with this is not adding/removing users, tracking groups is easy enough.
But we need a way to say "hey room, do not track this group anymore". And I fail to see a good way to make this possible without having a too flooded UI.

But maybe we can do this automatically, when a user from that group is removed.

[JLueke]

As far as I saw, there was no option in the UI to add a group to an existing conversation via the participant lists. There is only the option to create a new room with the (current) group members, if you want to invite a group to a chat.
Thus there is no need for an option to untrack the group members in the UI, right?

For the API (to create a room and add new participiants) another optional parameter could be used to either keep tracking the members of the group or just add the current members of the group individually.

[nickvergessen]

As far as I saw, there was no option in the UI to add a group to an existing conversation via the participant lists.

That is possible with the upcoming release. Was implemented in #1268

[JLueke]

What are use cases where I wouldn't want to update the participants according to the group members continuously?

[SIN3R6Y]

I second this feature, when adding new employees in, it would be nice if they just automatically get added to their respective group chats. My idea for UI would be for it to stay mostly how it is now, when you create a chat room out of a group, the room name matches the group and it stays synced with users in that group. If an admin kicks a user from the group manually, the room name is changed back to a regular multi-user chat room with the title "user1, user2, user3, etc..." and user syncing stops.

[JLueke]

The room name needs to be unique then: Question is, if there are cases where users create rooms with the same name of a group. If you have multiple businesses using the chat rooms without using the groups (for any reason), then its likely that rooms with same nams are created. This can be prevented if you create the rooms with a prefix for each company (simply by creating the rooms and groups via the API). Long story short, @SIN3R6Y proposal only works if the room names are unique.

[SIN3R6Y]

True, in our case our room names are unique as we pull group email adresses ([email protected]) for room names and the nextcloud group name. But enforcing this i think is bit out of the scope of spreed is it not? It's my understanding that nexcloud uses the group name as the gid, so this is an issue that would affect all of Nextcloud.

[JLueke]

Another table could be used e.g. synced_group_pariticipants (with columns gid and rid).
If a group _Foo_ is added to a room _aroomid_ as a participiant and the members should be synchronized continuously, then an entry (gid is 'Foo' and rid is 'aroomid') will be created for synced_group_pariticipants. Now if the members of the group itself change, it'll be checked if there are any numbers of entries in synced_group_pariticipants for this group. If thats the case the members of the room should update accordingly to the change in the group.

[SIN3R6Y]

Do you even need a new table though? For example add group to conversation, only that gid gets added to the member list. When calculating the member list just do a lookup for members of said group each time. Then you have group sync, and you can maintain external members as well.

[langfingaz]

In addition to what @SIN3R6Y suggested the participant view of a group chat could be similar to the sharing view in files app: Instead of showing each individual user you could show all groups and users that were added to the conversation. And by clicking on three dots next to each user/group you can change it's rights (e.g. to moderator).

What do you think of this idea?

[nickvergessen]

So if a user is invited as normal user, but one of his groups is a moderator and another group is not moderator, should the user be a moderator?

[langfingaz]

Good question. Do you know how it is handled with file sharing?

If Alice shares a file as readonly with group g1 and with read and write access to group g2. If Bob is a member of both, group g1 and g2, does he now have read only or also write access?

I would guess it's read and write. So the "highest" group permission counts.

If Alice also shares that file directly to Bob as readonly, one could argue that this direct share is meant to overwrites any other rules.

[nickvergessen]

Its exactly as you assumed, and the direct share overruling is the exact thing i could also imagine 🤔

[JLueke]

Good question. Do you know how it is handled with file sharing?

If Alice shares a file as readonly with group g1 and with read and write access to group g2. If Bob is a member of both, group g1 and g2, does he now have read only or also write access?

I would guess it's read and write. So the "highest" group permission counts.

If Alice also shares that file directly to Bob as readonly, one could argue that this direct share is meant to overwrites any other rules.

I think only the highest permission should count regardless of which share type it is (group, user, ...):

As Bob I would assume that I have read and write access to the file as long as I'm a member of g2. If I leave g2 only the remaining share permissions are used: readonly. If I leave g1 only the permissions of the direct share will count and vise versa.

And this behaviour analogous for the room participants

[born2webdesign]

What @SIN3R6Y suggested—minus individually kicked users.

[klada]

To be honest I'd actually consider this a medium security issue, not just an _enhancement_.

In environments where people manage their permissions through groups you expect updated group membership to also update permissions. This includes revoking access to resources (chats in this case) when users are removed from a group.

I know there are many battlefields out there for you guys but giving this a security label might help prioritize things during development.

[Dubidubiduu]

The "1. to develop" is tagged to 217 of 222 open tags. I don't think it's the needed priority.

We use groups for files, decks, calendars and talk. For files, decks, calendars it works fine. But for talk, after adding just one user (synced by user_sql) I have to re-add a group to a talk-room. And I have to do this for 40 groups manually.

Also in doing this way, the user won't leave the room, if they aren't in the group any longer.

For me it's annoying, but yeah, for sure, also a security issue. And also a basic feature actually.

[Dubidubiduu]

While checking/readding the groups to the rooms to get the newest nextcloud users into their rooms I miss-clicked, so I got a full room with the wrong users. This is just a very annoying bugish thing.