aboutsummaryrefslogtreecommitdiffstats
path: root/plugins/muc
Commit message (Collapse)AuthorAgeFilesLines
...
* | 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.
* | | | | | | | | | MUC: Strip tags with MUC-related namespaces from private messages (fixes #1427)Kim Alvefur2019-09-291-0/+1
| |_|_|_|_|_|_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | Prevents duplication since it adds another <{muc#user}x> here
* | | | | | | | | MUC: Fix delay@from to be room JID (fixes #1416)0.11.3Kim Alvefur2019-08-311-2/+2
| |_|_|_|_|_|_|/ |/| | | | | | |
* | | | | | | | MUC: Advertise XEP-0410 supportKim Alvefur2019-07-301-0/+1
| |_|_|_|_|_|/ |/| | | | | | | | | | | | | | | | | | | | Unsure if the feature was in the XEP at the time of 7c1cdf5f9f83
* | | | | | | MUC: Add error message to error bounces when not joined to roomMatthew Wild2019-02-041-3/+3
| |_|_|_|_|/ |/| | | | |
* | | | | | MUC: Allow changing data attached to an only owner (fixes #1273)Kim Alvefur2018-12-201-1/+1
| |_|_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.