aboutsummaryrefslogtreecommitdiffstats
path: root/plugins/muc
Commit message (Collapse)AuthorAgeFilesLines
* MUC: Add new event 'muc-build-occupant-presence' for plugins to extend ↵Matthew Wild2020-04-111-0/+2
| | | | occupant presence
* MUC: Add ad-hoc command setting affiliation in a room (fixes #1174)Kim Alvefur2020-03-211-0/+43
| | | | | | | | | | 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.
* MUC: Add initial hats support (broadcast only)Matthew Wild2020-03-182-0/+24
| | | | | | | | 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.
* MUC: Persist affiliation_data in new MUC format!Matthew Wild2020-03-121-0/+1
|
* MUC: Switch to new storage format by defaultMatthew Wild2020-03-121-1/+1
| | | | | | | | | | | | 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).
* MUC: Support for broadcasting unavailable presence for affiliated offline usersMatthew Wild2020-03-122-3/+24
| | | | Activated when muc#roomconfig_presencebroadcast includes the "none" role.
* MUC: Pass previous role to :publicise_occupant_status() when destroying a MUCMatthew Wild2020-03-121-3/+4
|
* MUC: Don't unconditionally broadcast presence with role="none"Matthew Wild2020-03-121-4/+0
| | | | | | 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.
* MUC: Pass previous role to :publicise_occupant_status() whenever possibleMatthew Wild2020-03-121-4/+6
| | | | | | | | | | | | | | | | | | | 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".
* mod_muc: add muc-private-message eventMaxime ?pep? Buquet2020-02-241-1/+3
| | | | | 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.
* Merge 0.11->trunkMatthew Wild2020-02-131-1/+2
|\
| * mod_muc: Allow control over the server-admins-are-room-owners feature (see ↵Matthew Wild2020-02-131-1/+2
| | | | | | | | #1174)
* | MUC: Make note to handle configuration form errors [luacheck]Kim Alvefur2019-12-231-0/+2
| |
* | MUC: Remove some unused variables [luacheck]Kim Alvefur2019-12-231-4/+4
| |
* | MUC: Improve presence broadcast form field labelMatthew Wild2019-12-221-1/+1
| |
* | MUC: Add missing reference to room (thanks buildbot) [luacheck]Kim Alvefur2019-11-261-0/+1
| |
* | MUC: Indicate the component as origin of various errors where there's no roomKim Alvefur2019-11-262-7/+7
| | | | | | | | A room that doesn't exist can't return an error, can it?
* | MUC: Indicate that the room is the origin of various errors where 'from' is ↵Kim Alvefur2019-11-253-16/+19
| | | | | | | | an occupant JID
* | MUC: Indicate origin of registration related errorsKim Alvefur2019-11-251-3/+3
| |
* | MUC: Indicate origin of password related errorsKim Alvefur2019-11-251-1/+1
| |
* | Merge 0.11->trunkKim Alvefur2019-11-237-44/+229
|\ \ | |/ |/|
| * MUC: Make nickname field in registration form requiredKim Alvefur2019-11-021-1/+1
| | | | | | | | | | | | Prevents traceback from resourceprep(nil) muc#register_roomnick is also required in XEP-0045
| * MUC: Strictly validate room JID on creationKim Alvefur2019-11-011-0/+8
| | | | | | | | This should prevent any MUCs with invalid JID (according to current normalization routine)
| * MUC: Enforce strict resourceprep on nicknames (bye bye robot face)Kim Alvefur2019-09-231-0/+16
| |
| * MUC: Advertise history related fields as integers via XEP-0122Kim Alvefur2019-10-201-2/+4
| | | | | | | | This takes advantage of data type validation and conversion done in util.dataforms.
| * MUC: Add controls for whose presence is broadcast (closes #1335)Lance Stout2019-10-203-5/+112
| | | | | | | | Committed by Zash
| * Merge 0.11->trunkKim Alvefur2019-10-201-2/+0
| |\
| * | MUC: Validate registration dataform more carefullyKim Alvefur2019-10-201-1/+13
| | |
| * | Merge 0.11-trunkKim Alvefur2019-09-291-0/+1
| |\ \
| * \ \ Merge 0.11->trunkKim Alvefur2019-08-311-2/+2
| |\ \ \
| * | | | MUC: Simplify nickname refresh loopKim Alvefur2019-08-251-2/+1
| | | | | | | | | | | | | | | | | | | | Affiliation data is passed as a loop variable so no need to retrieve it
| * | | | Merge 0.11->trunkKim Alvefur2019-08-211-0/+1
| |\ \ \ \
| * | | | | MUC: Advertise language field as such via XEP-0122Kim Alvefur2019-07-071-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | MUC: Reflow event tables to improve readabilityKim Alvefur2019-06-191-4/+20
| | | | | | | | | | | | | | | | | | | | | | | | Also makes it easier to read diffs of added fields.
| * | | | | MUC: Update error message for consistencyMatthew Wild2019-03-181-1/+1
| | | | | |
| * | | | | MUC: Fire an event to allow affecting decision of whether to allow a role changeKim Alvefur2019-02-241-0/+12
| | | | | |
| * | | | | MUC: Factor out role change permission check into its own methodKim Alvefur2019-02-241-18/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
| * | | | | Merge 0.11->trunkMatthew Wild2019-02-041-3/+3
| |\ \ \ \ \
| * | | | | | MUC: Rename import to avoid name clash [luacheck]Kim Alvefur2019-01-061-2/+2
| | | | | | |
| * | | | | | MUC: add ID to message if no ID is presentJonas Wielicki2019-01-061-0/+4
| | | | | | |
| * | | | | | Merge 0.11->trunkKim Alvefur2018-12-201-1/+1
| |\ \ \ \ \ \
| * \ \ \ \ \ \ Merge 0.11->trunkMatthew Wild2018-12-192-2/+2
| |\ \ \ \ \ \ \
| * \ \ \ \ \ \ \ Merge 0.11->trunkKim Alvefur2018-12-151-1/+1
| |\ \ \ \ \ \ \ \
| * | | | | | | | | MUC/subject: Don't consider messages with <body> or <subject> (fixes #667)Kim Alvefur2018-12-041-0/+6
| | | | | | | | | |
| * | | | | | | | | MUC: Move check for explicit room join earlier in room creation flowKim Alvefur2018-11-272-8/+1
| | | | | | | | | |
| * | | | | | | | | Merge 0.11->trunkKim Alvefur2018-11-251-0/+1
| |\ \ \ \ \ \ \ \ \
| * \ \ \ \ \ \ \ \ \ Merge 0.11->trunkMatthew Wild2018-11-151-12/+18
| |\ \ \ \ \ \ \ \ \ \
| * | | | | | | | | | | MUC: Fix spelling in commentsKim Alvefur2018-11-101-5/+5
| | | | | | | | | | | |
* | | | | | | | | | | | MUC: Keep role across nickname change (fixes #1466)Kim Alvefur2019-11-231-0/+3
| |_|_|_|_|_|_|_|_|_|/ |/| | | | | | | | | |
* | | | | | | | | | | MUC: Don't advertise registration feature on host JID (fixes #1451)Kim Alvefur2019-10-201-2/+0
| |_|_|_|_|_|_|_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.25.1) at 2024-12-20 01:44:07 +0000