Open dkliss opened 1 year ago
What you are seeing there is probably result of a filter that we apply when room is set to anonymous. In that case we send notifications for that only to moderators (as event payload contains real jid, without this we will expose real jid of user to everyone). Possibly we could tweak this and send only nick name in that case to everyone else?
Hi,
Nick name change indicating whose "Affiliation" is change should work. At least a recipient can adjust change of affiliation status.
Found a note from XEP. "Roles" are granted, revoked, and maintained based on the occupant's room nickname or full JID rather than bare JID. Whereas, "Affiliations" are granted, revoked, and maintained based on the user's bare JID, not the nick as with roles. So, I am assuming the nick (you mentioned) will be username within bare JID for affiliation change (and nick will be MUC Nick for "Role" change)?
On your comment " only to moderators", I am not really clear on how MucSub handles "Roles". Below is my summary but if I am missing any info, please correct me.
For Affiliations, If I am an Admin or Owner Affiliate, I can fetch list of Admins or Owners or Others from server.
For Roles, even if I have set Affiliations to Admin or Owner, I cannot get list of Roles (i.e. moderators, or participants) from the server. What I get is an error message "Moderator privileges required".
Now, I am not sure, even if when I am an Owner, if my "Role" is set up as "Moderator" in the server. This is because, when I issue a subscribe request stanza shown below, I do not see what was my role setup in server i.e. is my role = moderator. In XEP-0045, upon sending a JOIN, i receive response as affiliation=owner and role =moderator.
<iq from='hag66@shakespeare.example'
to='coven@muc.shakespeare.example'
type='set'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<subscribe xmlns='urn:xmpp:mucsub:0'
nick='mynick'
password='roompassword'>
<event node='urn:xmpp:mucsub:nodes:messages' />
<event node='urn:xmpp:mucsub:nodes:affiliations' />
<event node='urn:xmpp:mucsub:nodes:subject' />
<event node='urn:xmpp:mucsub:nodes:config' />
</subscribe>
</iq>
However, in MucSub, I can confirm that I am an Owner via getting list of affiliates from the server. But because of error "Moderator privileges required", I cannot retrieve list of "Roles" from server and hence I am not sure If I am a "Moderator".
And to me the root cause of this seems to be, that the server has not assigned any "role" to a user who created a room (affiliation=owner). And hence, the "owner" is not setup as role=moderator and hence the owner or admins cannot really fetch list of roles from server.
This is my observation. I am not sure how to confirm, what "role" an owner is assigned when a MucSub subscribe is issued as Result does not show that. So, I was wondering, if similar to XEP-0045, a default role of "moderator" needs to be setup for affiliates "owner" .
In summary, looks like, MucSub does not support "Roles" alteration. And, not sure, if a default role for Owner can be setup as "Moderator" OR alternative, a user is provided with an option on XML stanza to set the "Role" as per their wish.
For example,
One option is, including a response in stanza below on what was the role assigned:
<iq from='hag66@shakespeare.example'
to='coven@muc.shakespeare.example'
type='set'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<subscribe xmlns='urn:xmpp:mucsub:0'
nick='mynick'
role='moderator'. <-------THIS IS NEW
password='roompassword'>
<event node='urn:xmpp:mucsub:nodes:messages' />
<event node='urn:xmpp:mucsub:nodes:affiliations' />
<event node='urn:xmpp:mucsub:nodes:subject' />
<event node='urn:xmpp:mucsub:nodes:config' />
</subscribe>
</iq>
Other option is to allow An API option for users to assign role as below:
<iq from='hag66@shakespeare.example'
to='coven@muc.shakespeare.example'
type='set'
id='E6E10350-76CF-40C6-B91B-1EA08C332FC7'>
<subscribe xmlns='urn:xmpp:mucsub:0'
nick='mynick'
role='moderator'. <-------THIS IS NEW AND USER DEFINED
password='roompassword'>
<event node='urn:xmpp:mucsub:nodes:messages' />
<event node='urn:xmpp:mucsub:nodes:affiliations' />
<event node='urn:xmpp:mucsub:nodes:subject' />
<event node='urn:xmpp:mucsub:nodes:config' />
</subscribe>
</iq>
What you are seeing there is probably result of a filter that we apply when room is set to anonymous. In that case we send notifications for that only to moderators (as event payload contains real jid, without this we will expose real jid of user to everyone). Possibly we could tweak this and send only nick name in that case to everyone else?
What you are seeing there is probably result of a filter that we apply when room is set to anonymous. In that case we send notifications for that only to moderators (as event payload contains real jid, without this we will expose real jid of user to everyone). Possibly we could tweak this and send only nick name in that case to everyone else?
Sharing some more info on the Affiliation versus Role, after some checking. The stanza for Affiliation versus Role is below. When changing Affiliation, XEP is using destination JID. Whereas when changing Role, destination is a "Nick".
AFFILIATION: EXAMPLE STANZA FOT CHANGING AFFILIATION
<iq id="MNNADLQDI" type="set" from="myTestUserJID@testServer.com/69cc4690"
to="mucSubRoom@conference.testServer.com">
<query
xmlns="http://jabber.org/protocol/muc#admin">
<item affiliation="admin" jid="otherTestUserJID@testServer.com">. <-- THIS IS A JID
<reason>Changing Affiliation Status </reason>
</item>
</query>
</iq>
ROLE: EXAMPLE STANZA FOT CHANGING ROLE
(BELOW Responds with ERROR: Changing role/affiliation is not allowed)
Seems related to Owner not assigned default tole of moderator.
<iq id="MLIYDJWST" type="set" from="myTestUserJID@testServer.com/69cc4690"
to="mucSubRoom@conference.testServer.com">
<query
xmlns="http://jabber.org/protocol/muc#admin">
<item nick="otherTestUserNick" role="moderator">. < --THIS IS A NICK
<reason>Changing your role</reason>
</item>
</query>
</iq>
Based on above, what I found is:
Based on above, what could work is below:-
Hi,
I was wondering if any update on this ? I did some further checking on semi-anonymous (JIDs to moderators only, roomconfig_whois=moderators) rooms, and affiliation changes are still not sent to anyone (including affiliate=admin). It potentially seems because of role-moderator is not used as everyone gets a role =none.
I found note below in documentation, which confirms that role = none is actually part of mucsub. I was wondering if any other way to send notifications from server side. If this is not possible because of was mucsub works, i can close this.
"Until a subscriber is not joined a conference (see Joining a MUC Room), a subscriber role MUST be 'none'."
Hi, this issue has been discussed in link below but has been closed. However, looks like it has not been resolved.
https://github.com/processone/ejabberd/issues/3172
What I tried.
Scenario 1: There is a room, with three participants. One of three participants is an Owner. Remaining are only members. If Owner, makes one of the member as Admin, the Owner receive a response from server on affiliation change, but member does not receive anything.
Scenario 2: The room has three members and this time one is Owner, One is Admin, and other is Member. This time, Owner, made an Admin to be a member. And the Admin user, even though an Admin does not receive any response on Affiliation Change.
Summary In summary:
Optional Information
Example test scenarios are below.
Scenario 1: Owner changes Member To Admin. Owner receives Result. Member Receives Nothing. Expected: Member is informed of Affiliation Change.
Scenario 2: Owner changes Admin to Member. Owner receives Result. Member Receives Nothing Expected: Member is informed of Affiliation Change.
Setup Users are subscribed to following nodes.
Note, If when changing affiliation, I also send a presence stanza (Join a Room), then I receive presence packaged in MucSub (as per example stanza in docs below), which is sent to users whose affiliation is changed. But if we did this, then we will be "Present" in room as per XEP--0045, and after that, the room will start sending standard messages instead of MUCSUB encapsulated messages i.e. below approach basically breaks MucSub
Before creating a ticket, please consider if this should fit the discussion forum better.
Environment
erl +V
Configuration (only if needed): grep -Ev '^$|^\s*#' ejabberd.yml
Errors from error.log/crash.log
No errors
Bug description
Please, give us a precise description (what does not work, what is expected, etc.)