I really do not like the approach from MUC as it is difficult to know who is blocked from this list, but I agree that the current approach with MIX is not the best.

The difficulty here is that while MUC shows users' affiliations to the room, MIX does not. Only owners (and sometimes admins) are allowed to "view or modify" channel details and due to that only they knew who is admin or owner. That makes it impossible to present a "membership" status to others.

Additionally, as admins/owners are defined in a separate form than "allowed" and "banned" that makes it even more complicated as we are not "changing" state, but "removing" from one node, "adding" to another and possible modifying another PunSub item just to accomplish a single change (ie. from admin to banned).

However, I think that we could consider slight improvement. In the "manage" window, we could get rid of "allowed"/"banned" and have a single list. For the public channel (anyone can join) we would have only the "banned" list displayed, and for the private channel (invite only) we would have just a list of people allowed to join.

This approach could simplify this view.

Managing admins/owners from this view is a little more tricky and I would prefer to leave it as it is or add "context menu item" with something like "Make admin/owner" which tapped would try to update channel configuration.

@wojtek What do you think? Would this work?

I really do not like the approach from MUC as it is difficult to know who is blocked from this list, but I agree that the current approach with MIX is not the best.

Maybe adding groups to that list would help? Something like in Finder:

As for particular rights associated with current role/permissions: non-admin could probably do without even being able to access the list (they can't see the rights, looking at banned list shouldn't be all that important to them).

As for switching from "allowed to banned", while this may require two actions, from the person point of view it's single action -- I guess we could probably hide "xmpp technical detail" and make it more user friendly (add somebody to the channel, make somebody admin, ban somebody) which would entail particular changes to MIX pubsub nodes.

I know we can "hide" things, and I'm even suggesting to "hide unused stuff" (like banned tag when we have a members-only channel). I'm just not sure if putting "more" actions and data into a single view will make things simpler? or more difficult for regular user (we are not regular users).

Adding groups does not solve a way to change them before groups as instead of using "combobox" we need to add context menu and most likely a drag and drop support...

I know we can "hide" things, and I'm even suggesting to "hide unused stuff" (like banned tag when we have a members-only channel). I'm just not sure if putting "more" actions and data into a single view will make things simpler? or more difficult for regular user (we are not regular users).

We already have them in MUC view and I wouldn't say it's "overwhelming". There is a limitation of how simple the UI can be (and it kinda reminded me of: https://www.youtube.com/watch?v=9BnLbv6QYcA ;-) ).

Adding groups does not solve a way to change them before groups as instead of using "combobox" we need to add context menu and most likely a drag and drop support...

My initial idea was to have single list with combo boxes. And to help with organisation and seeing "who is who" (and also who is banned), adding groupping while maintaining the combo boxes.

However, keeping in mind "simplicity" argument, having a context menu (instead of combo box) with action to change the group would also work just fine (I don't see much difference functionality wise between combo box and context menu here). I'm not sure if drag&drop would be needed here (it's kinda cumbersome on longer lists)

I'm not sure if drag&drop would be needed here (it's kinda cumbersome on longer lists)

I'm pretty sure that someone will try that and would report a bug that it doesn't work.

Maybe let's not get ahead of ourselves? :-)

If the widget doesn't support d&d natively then let's not handle it initially. And if someone complains about it we can act accordingly (decide to add it or wontfixit)?

I've reimplemented this feature. The new version of participants (and their permissions) management will be part of the next build.

I think it works quite good. A couple of improvements:

1. adding modification menu/options on main/left click
2. better distinction between owner/admin in the context menu (currently it's the same star icon)
3. scaling down context menu items:

Interesting, on my macOS it looks a little different - most likely issue with old macOS misbehaving..

As for adding this on the "left click" - that can be tricky as I've used just "normal" context menu which is fired only on right click, but I'll try to look into this.

Zrzut ekranu 2021-09-29 o 12.31.42.png

Maybe not exactly misbehaving but just famous Apple's breaking stuff between versions. Having it work on Catalina (10.15) would be nice. As for the context menu - it's not essential, just a suggestion but if it requires more tinkering I'm not sure if it's worth the effort.

I've improved UX for this feature and it should work better on Catalina (at least I hope it will).

Works way better now.

One nit-pick - the items are not in the same order depending on current rights:

Can we make it more uniform?

@wojtek I've added grants, then revokes, but I can switch their places. Please confirm, that this is what you expected.

Hmmm, I didn't notice that order. I think that actual rights should be in the same order (IMHO best would be "from most powerful" to leaast).

(btw. for you (owner) there is a missing star in "Revoke owner rights")

Actually, there are missing icons on Catalina. I can backport them if we need them, but I would consider dropping them (all icons in this menu) on macOS lower than BigSur as they are not really what they should be. See a screen from BigSur.

+1 on dropping icons on Catalina as there aren't usually icons in the menu.