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).
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.
This previously prevented a single owner from setting their own nickname
via admin query.
The form method uses `true` as actor so it bypasses this check.
These have caused too many issue reports to be included in
the stable branch at this time.
Affected issues: #345, #397
Reverted commits:
dcd53a565c01
6d4b0895f76d
1b10802a770e
564e897f0790
a7221ada9368
aaff40ec7001
05a3275b6873
c2b99fa134b3
8da11142fabf