| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This is allowed by XEP-0045, which states:
"A moderator SHOULD NOT be allowed to revoke moderation privileges from
someone with a higher affiliation than themselves (i.e., an unaffiliated
moderator SHOULD NOT be allowed to revoke moderation privileges from an admin
or an owner, and an admin SHOULD NOT be allowed to revoke moderation
privileges from an owner)."
|
| |
|
|
|
|
|
| |
Including the payload of the stanza that caused the error is optional
and we're generally not doing it anywhere else.
|
|
|
|
|
|
| |
The numeric error codes seems to have been removed from the examples in
XEP-0045 version 1.24, and were deprecated even by RFC 3920 in 2004,
only allowed for backwards compatibility.
|
|
|
|
|
|
| |
I spend several minutes confused over where the bug was until I
remembered I had set myself as visitor in the previous debug session.
This would have helped.
|
| |
|
| |
|
| |
|
| |
|
|
|
|
|
|
| |
.affiliation
It appears nothing currently uses this field in prosody or prosody-modules
|
| |
|
|
|
|
| |
...and fixing the logic bug that broke everything in the previous commit.
|
|
|
|
| |
data
|
|
|
|
|
|
|
|
|
|
| |
XEP-0045 states:
> Affiliations are granted, revoked, and maintained based on the user's
> bare JID, not the nick as with roles.
Therefore inclusion of a full JID in affiliation queries is invalid.
Thanks to Ge0rG and Poezio for discovering this issue.
|
|\ |
|
| |
| |
| |
| |
| |
| | |
Fixes https://prosody.im/security/advisory_20210722/
Backs out 4d7b925652d9
|
| |
| |
| |
| |
| |
| |
| | |
Use case: Enable module that provides a virtual occupant object for bots
Before, if there is no occupant then either some other part of MUC would
reject the message or `occupant.nick` would have caused an error.
|
| |
| |
| |
| | |
Also test for self-probes
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The following patch allows Prosody to respond to `probe` presences and send out the probed occupant's current presence.
This is based on line 17.3 in XEP-0045:
A MUC service MAY handle presence probes sent to the room JID <room@service> or an occupant JID <room@service/nick>
(e.g, these might be sent by an occupant's home server to determine if the room is still online or to synchronize
presence information if the user or the user's server has gone offline temporarily or has started sharing presence again,
as for instance when Stanza Interception and Filtering Technology (XEP-0273) is used).
|
|\| |
|
| |
| |
| |
| | |
(thanks damencho)
|
|\| |
|
| |
| |
| |
| | |
#1595) (thanks lessthan3)
|
| |
| |
| |
| | |
Updates #1533
|
| | |
|
|\| |
|
| | |
|
| | |
|
| |
| |
| |
| | |
occupant presence
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Changing the default setting of `new_muc_storage_format` from false to true.
The code supports reading both formats since 0.11, but servers with MUCs stored
using the new format will not be able to downgrade to 0.10 or earlier.
The new format is clearer (less nesting for the most commonly-accessed data),
and combined with the new map-store methods, allows for some operations to become
more efficient (such as finding out which MUCs on a service a given user is affiliated
with).
|
| |
| |
| |
| | |
Activated when muc#roomconfig_presencebroadcast includes the "none" role.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Currently there is what amounts to a hack in presence_broadcast.lib.lua to
make it always broadcast presence with roles of "none". This is to ensure
that if you previously saw available presence for someone, you will also
see the unavailable presence (which always has role="none").
The correct approach is to take into account what the previous role was (
i.e. answer the question: "Was the available presence for this occupant
a role for which presence broadcast is enabled?).
The logic is already in place to do this correctly, but most call sites
do not provide the previous role (prev_role argument) of the occupant,
which causes it to not be used. In its place the hack to always broadcast
presence of role="none" has allowed things to continue to work.
The intention is that a subsequent commit will remove the unconditional
broadcast of role="none".
|
| |
| |
| |
| |
| | |
This seems to be the one place handling MUC-PMs. This event is added so that
plugins (such as muc_occupant_id) can edit them without having to redo the work.
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
an occupant JID
|
|\ \
| |/
|/| |
|
| | |
|
| |
| |
| |
| | |
Committed by Zash
|
| |\ |
|
| |\ \ |
|
| | | |
| | | |
| | | |
| | | | |
Also makes it easier to read diffs of added fields.
|
| | | | |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
I would like to invert this logic so that it checks if the role change
is allowed instead of checking if it is not allowed as it does now, in
order to make it easier to understand.
|