| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This makes it much nicer to inspect Prosody internals.
Existing textual status messages from commands are not serialized to
preserve existing behavior. Explicit serialization of configuration is
kept in order to make it clear that returned strings are serialized
strings that would look like what's actually in the config file.
The default maxdepth of 2 seems ought to be an okay default, balanced
between showing enough structure to continue exploring and DoS-ing your
terminal.
Thanks to Ge0rG for the motivation to finally do this.
|
|
|
|
| |
This was explicit previously
|
|
|
|
| |
The return statements were lost in d95e083931d1
|
|\ |
|
| |
| |
| |
| | |
Meant to reduce user confusion over what's reloaded and not.
|
| |
| |
| |
| |
| | |
This ensures rules in mod_mam apply to some extent. Messages worth
archiving are probably worth sending to other clients.
|
| |
| |
| |
| | |
Ensures that all your clients know about sent messages that failed.
|
| | |
|
| | |
|
|\| |
|
| |
| |
| |
| |
| |
| |
| | |
27f5db07bec9 fixed this wrong. The code is supposed to check if the
stanza is NOT sent to your bare JID. A MUC PM is always sent to your
full JID. Hopefully nobody sends MUC invites to full JIDs, because those
would be skipped by this as well.
|
| | |
|
| |
| |
| |
| |
| |
| | |
This is the subset of mod_mam rules I believe makes sense in MUC.
Note that mod_muc_mam does not have its own rules, but uses these.
|
| |
| |
| |
| |
| | |
Unclear if clients normally ever send error messages, but there may be
locally generated bounces sent on behalf of local sessions.
|
| |
| |
| |
| |
| | |
Should be more obvious that all iq stanzas are considered important.
Changes behavior for invalid things in the default namespace.
|
| | |
|
| |
| |
| |
| |
| | |
This case was previously handled by fall-trough at the end of the
function.
|
| |
| |
| |
| | |
This was already the case for presence and iq stanzas but not messages.
|
| |
| |
| |
| | |
Copy-paste mistake presumably
|
| |
| |
| |
| |
| | |
When the reason is reported as an util.error object the `reason` field
is empty and the reason text should be extacted from the error object.
|
| |
| |
| |
| | |
Probably because autocomplete.
|
| |
| |
| |
| | |
(thanks Ge0rG)
|
|\ \ |
|
| | |
| | |
| | |
| | | |
Logic using full vs bare JID addressing may return in the future.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The intent was to not store MUC groupchat messages, which are sent from
the MUC to local full JIDs, while allowing for potential future
account based group chat. However, since this function handles messages
in both directions and outgoing MUC messages are sent to the bare room
JID, those were stored.
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
In Lua 5.3 difftime() takes integers as argument but returns a float,
and then tostring() serializes it with a decimal point. This violates
XEP-0012.
Like #1536
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
Since these XEPs are subject to change we may need come back and double
check these in the future.
|
| | |
| | |
| | |
| | |
| | | |
Makes it possible to learn of delivery failure even if it came bouncing
back while you were offline.
|
| | | |
|
| | |
| | |
| | |
| | |
| | | |
no-store is used in an example in XEP-0313, so obviously this is the
preferred hint
|
| | |
| | |
| | |
| | | |
If it is with a body then it execution does not get this far
|
| | | |
|
| | |
| | |
| | |
| | |
| | |
| | | |
The intent is to capture errors to stanzas sent by the local user, so
that they can see why a message failed to be delivered even if the error
came after they went offline.
|
| | |
| | |
| | |
| | | |
Happy now Ge0rG?
|
| | |
| | |
| | |
| | | |
Mostly just lifted from mod_csi_simple
|
| | |
| | |
| | |
| | | |
Improved readability and early returns definite yes/no answer.
|
| | |
| | |
| | |
| | |
| | | |
This is based on code in mod_csi_simple and aiming towards being more
flexible and maintainable than a couple of tests for when not to store.
|
| | |
| | |
| | |
| | |
| | | |
Logging of 'why not' is already done. Why not both? Will make more sense
when the rules evolve a bit.
|
| | |
| | |
| | |
| | |
| | | |
Meant to improve readability and ease further improvements to this
algorithm.
|
| | |
| | |
| | |
| | |
| | | |
Both mediated invites defined by XEP-0045: Multi-User Chat and direct
invites defined by XEP-0249: Direct MUC Invitations
|
|\ \ \
| |/ /
|/| /
| |/ |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
| |
| |
| | |
Improves readability, easier to see structure.
|
| |
| |
| |
| |
| |
| |
| |
| | |
It is somewhat ambiguous where an error really comes from in the case of
an external component.
Setting by to the bare host at least distinguishes it from JIDs with a
node- or resourcepart.
|
| | |
|
| |
| |
| |
| | |
presence
|