tinode / chat

Instant messaging platform. Backend in Go. Clients: Swift iOS, Java Android, JS webapp, scriptable command line; chatbots
GNU General Public License v3.0
12.06k stars 1.88k forks source link

group topic defacs changes are not propagated to group members #720

Open gabriel-vasile opened 2 years ago

gabriel-vasile commented 2 years ago

I'm not sure if this is a missing feature or this is the intended behaviour.

The situation:

What I expected: the change to be sent to group member. What happens: group member receives the new defacs only at the next {sub} to the group topic.

Tinode version: master

or-else commented 2 years ago

I would say it's probably a bug but a very minor one. Can you describe a use case where such update is important?

gabriel-vasile commented 2 years ago

The other changes made by the owner to the group (changes in public field, changes to the group members list) are propagated and peers views are updated in real-time. Not the same for defacs...

One can argue defacs don't change so often and they don't deserve to be updated in real-time, idk

or-else commented 2 years ago

I agree that it's inconsistent and that's why I marked it as a bug. The only case that I can think of when this bug may case minor trouble is if the owner has more than one device and changes the defacs from one of them then tries to do it again from another. Do you see any other cases?

gabriel-vasile commented 2 years ago

The case we have is the owner changes the defacs and other group members which are online and subscribed to the group are not notified of the change. They still see the old permissions in the Info section, their UI is still working based on the old defacs.

or-else commented 2 years ago

I understand that they do not get updated. That's why this issue is marked as a bug. Why is it a problem that they are not updated (other than being inconsistent)? "They want to do X but do Y because of the bug".

gabriel-vasile commented 2 years ago

Owner removes J from group permission. User1 invites user2 to group, knowing the group has J. User2 cannot join.

This is not a situation in webapp, or the other frontends but this is what I'm facing. Having the clients receive a notification that permissions have changed will let them handle situation.

or-else commented 2 years ago

User2 could not join because the owner removed the J permission, not because User1 had incorrect information. Anyway, it does indeed look like a minor bug. It will be fixed eventually.