Fix: Don't use affiliation to decide whether to observe the role

[Fishbowler]

ISSUE: In a constrained environment, where Jitsi is backed by an XMPP server with MUCs already defined, users with an affiliation of "admin" and a role of "moderator" appear as a moderator to everyone but themselves.

Whilst XEP-0045 defines the owner affiliation to have a default role of moderator, this isn't always the case.

That being said, this line was in for a reason, so happy to talk about how to meet that need. Perhaps look at constraining it to const newRole = (member.affiliation === 'owner' | member.affiliation === 'admin') ? member.role : 'none'; ?

[jitsi-jenkins]

Hi, thanks for your contribution!
If you haven't already done so, could you please make sure you sign our CLA (https://jitsi.org/icla for individuals and https://jitsi.org/ccla for corporations)? We would unfortunately be unable to merge your patch unless we have that piece :(.

[Fishbowler]

CLA is signed

[damencho]

Whilst XEP-0045 defines the owner affiliation to have a default role of moderator, this isn't always the case.

That being said, this line was in for a reason, so happy to talk about how to meet that need. Perhaps look at constraining it to const newRole = (member.affiliation === 'owner' | member.affiliation === 'admin') ? member.role : 'none'; ?

Why is this not the case? We haven't seen any problems with that?

[Fishbowler]

Thanks so much for the quick review, and sorry for not getting back to you til now.

In most cases, role and affiliation will match tidily. It's only in more esoteric setups, where the MUC is being externally controlled AND Jitsi isn't permitted to upgrade everyone to owner where it wouldn't.

Are you as concerned about the original purpose of this removed line as I am? I don't know why that test is there, but it feels like more than an abundance of caution. The compromise I suggested (expanding the if statement to include the "admin" affiliation) would both work in my setup, and be compliant with the default roles in XEP-0045.

Let me know if you'd like me to update this PR.

[saghul]

Whilst XEP-0045 defines the owner affiliation to have a default role of moderator, this isn't always the case.

That being said, this line was in for a reason, so happy to talk about how to meet that need. Perhaps look at constraining it to const newRole = (member.affiliation === 'owner' | member.affiliation === 'admin') ? member.role : 'none'; ?

Why is this not the case? We haven't seen any problems with that?

I think we won't run into this ourselves because we always use owner, but LGTM in general.

[Fishbowler]

Thinking about this some more - this needs companion PRs in some places.
Whilst XMPP allows Admins to be moderators, Jitsi doesn't. To be a moderator means to be able to nominate other moderators, which is amending the Admins or Owners of a MUC, which is something only an Owner can do.

Whilst this is technically correct, I'm not sure you'd want to take it without the other MRs being in place too. I'm going to revert this to draft until I find time to get the companion pieces of work done.

[sapkra]

@Fishbowler Any updates on this?

[Fishbowler]

To be honest, the amount of work required to get all of the Jitsi components to behave correctly in this edge case is more than I'm willing to take on. I've worked around it for now using an XMPP shim, telling lies about roles and affiliations to both Jitsi and the XMPP server.