| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
| |
| |
| |
| | |
occupant presence
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This gives service admins a way to set an arbitrary affiliation in any
room. Enables various administrative use cases such as room ownership
reassignment or recovery.
Reduces the need for the admins-as-owners feature, as this can be used
by admins to make themselves owner in any room when needed, instead of
being owners all the time.
|
| |
| |
| |
| |
| |
| |
| |
| | |
Based on the currently-deferred XEP-0317. The protocol differs
a little (because XEP-0317 is incomplete), therefore currently
we use a custom namespace.
The plan is to update and finish XEP-0317.
|
| | |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
| | |
|
| |
| |
| |
| |
| |
| | |
Detailed explanation in de607875d4bd. A presence with role="none"
(which is always type="unavailable") should only be broadcast if
available presence was previously broadcast for that occupant.
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
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.
|
|\| |
|
| |
| |
| |
| | |
#1174)
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
A room that doesn't exist can't return an error, can it?
|
| |
| |
| |
| | |
an occupant JID
|
| | |
|
| | |
|
|\ \
| |/
|/| |
|
| |
| |
| |
| |
| |
| | |
Prevents traceback from resourceprep(nil)
muc#register_roomnick is also required in XEP-0045
|
| |
| |
| |
| | |
This should prevent any MUCs with invalid JID (according to current normalization routine)
|
| | |
|
| |
| |
| |
| | |
This takes advantage of data type validation and conversion done in util.dataforms.
|
| |
| |
| |
| | |
Committed by Zash
|
| |\ |
|
| | | |
|
| |\ \ |
|
| |\ \ \ |
|
| | | | |
| | | | |
| | | | |
| | | | | |
Affiliation data is passed as a loop variable so no need to retrieve it
|
| |\ \ \ \ |
|
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This lets clients know that the field is a language field and should be
in RFC 5646 format.
Field validation code in util.dataforms left for future commit.
|
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| |\ \ \ \ \ |
|
| | | | | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \ |
|
| |\ \ \ \ \ \ \ |
|
| |\ \ \ \ \ \ \ \ |
|
| | | | | | | | | | |
|
| | | | | | | | | | |
|
| |\ \ \ \ \ \ \ \ \ |
|
| |\ \ \ \ \ \ \ \ \ \ |
|
| | | | | | | | | | | | |
|
| |_|_|_|_|_|_|_|_|_|/
|/| | | | | | | | | | |
|
| |_|_|_|_|_|_|_|_|/
|/| | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | |
| | | | | | | | | | |
There is currently no mention in XEP-0045 of how or where to advertise
support for registration.
Advertising on the host JID may be confusable with service-wide
registration, as implemented in ejabberd.
A common and sensible pattern in XMPP is that a feature is advertised on
the JID where the service is available.
|