Let mod_mam use the 'sm_receive_packet' hook to generate stanza IDs for
incoming messages, but not to actually store them. The latter would
require additional changes to make sure modules such as mod_privacy and
mod_block_strangers continue to affect MAM.
If mod_offline is disabled but a message is archived by mod_mam, no
error bounce should be generated. This functionality got lost when
mod_mam stopped using the 'offline_message_hook'.
Now that mod_mam no longer uses the 'offline_message_hook', avoid
duplicating notifications for messages written to both MAM and offline
storage in another way.
XEP-0359 v0.5.0 says: "Stanza ID generating entities, which encounter a
<stanza-id/> element where the 'by' attribute matches the 'by' attribute
they would otherwise set, MUST delete that element even if they are not
adding their own stanza ID."
Let mod_mam store incoming messages from a new hook in ejabberd_sm.
This makes sure all messages are tagged with a stanza ID, including
those that are forked to multiple resources in ejabberd_sm.
Closes#1344.
Refuse filtering anon MUC MAM queries by JID even if it's the client's
own JID. Clients probably won't perform such queries in practice, so
the additional complexity is unnecessary.
The changes are very similar to those from previous commit:
* Now there is no need to pass validating function in
gen_mod:get_opt() and gen_mod:get_module_opt() functions,
because the modules' configuration keeps already validated values.
* New functions gen_mod:get_opt/2 and gen_mod:get_module_opt/3 are
introduced.
* Functions gen_mod:get_opt/4 and get_module_opt/5 are deprecated.
If the functions are still called, the "function" argument is
simply ignored.
* Validating callback Mod:listen_opt_type/1 is introduced to validate
listening options at startup.
It's now possible to use files as internal packet queues.
The following options are introduced:
* queue_type: the option can be set to `ram` (default) or `file`.
The option can be set per virtual host.
* queue_dir: path to the directory where queues will be allocated.
The default is 'queue' directory inside Mnesia directory.
This is a global option and cannot be set per virtual host.
Now 'From' and 'To' arguments must be omitted in functions
and structures related to routing.
The commit deprecates the following functions:
ejabberd_router:route/3 in favor of ejabberd_router:route/1
ejabberd_router:route_error/4 in favor of ejabberd_router:route_error/2
ejabberd_local:route_iq/4 in favor of ejabberd_local:route_iq/2
ejabberd_local:route_iq/5 in favor of ejabberd_local:route_iq/3
The format of {route, From, To, Packet} is changed in favor of {route, Packet}
When multiple resources have the same (highest) priority, ejabberd_sm
dispatches messages addressed to the bare JID (or to an unavailable
resource) to each of these resources. Such messages are now marked with
an 'sm_copy' flag for all but one of the resources. This makes it
easier for other modules to identify those duplicates.
Resolves#1356.
Use the user (or room) JID instead of the server JID for the 'by'
attribute of <stanza-id/> and <archived/> tags. That's what the
examples in XEP-0313 v0.2 and XEP-0359 v0.3.0 suggest.
XEP-0313 says: "a server SHOULD include in a user archive all of the
messages a user sends or receives of type 'normal' or 'chat' that
contain a <body> element."
The "assume_mam_usage" option now takes a boolean value. Setting it to
"true" has the same effect as "if_enabled" had before. The "on_request"
behavior is no longer offered, as it made the option (and its
documentation) overly complex.
Limit the number of messages returned for a given MAM request even if
the client didn't specify an RSM set (not just if the client specified
an RSM set without a limit).
This is still not done for MAM v0.2 requests though, as that version of
the XEP doesn't require clients to support RSM.
- Change order of the hooks in mod_mam for sending and receiving packets. Messages are archived before a carbon copy is send to the other recourcces.
- Add archived tag and unique stanza id to the outgoing packet to have message carbons with the archive information.
- Add additional hook (in mod_mam) to strip the archive tag for outgoing packets after message carbons have been send.
XEP-0313 says: "A MUC archive MUST check that the user requesting the
archive has the right to enter it at the time of the query [...]. In
the case of open MUC rooms, the MUC archives can generally be accessed
by any users [...] who do not have an affiliation of 'outcast'".
Include the occupant JID with MUC MAM messages if the room is not
anonymous, and also when the MAM user sent the MUC message himself (not
just in the case where he is a room moderator).
Strip any pre-existing <x/> tags which have an <item/> child with a
'jid' attribute from MUC MAM messages. This way, if such a tag exists,
clients can be sure it was added by mod_mam.
If a stream management session times out for a user who appears to be
using MAM, drop any unacknowledged messages rather than resending or
bouncing them. This avoids duplicates or bogus error messages.
However, this is only done if the new mod_mam option "assume_mam_usage"
is set to 'if_enabled' or 'on_request'. In the former case, a user is
assumed to be using MAM if archiving is enabled for his account. In the
latter case, MAM usage is assumed only if archiving was explicitly
requested by the client, or if archiving was enabled by means of
mod_mam's "request_activates_archiving" option.
Sort the messages retrieved from an Mnesia archive before selecting the
subset limited by the <max/> value. This makes sure the desired subset
of messages is sent to the client.
If the client doesn't specify a maximum number of messages to retrieve
per page, set a limit of 50 messages. If the client specifies a limit
larger than 250, cap the number to 250 messages.
These limits aren't enforced for MAM v0.2 requests though, as that
version of the XEP doesn't require clients to support RSM. The newer
revisions say that "a server MAY place a reasonable limit on how many
stanzas may be pushed to a client in one request. Whether or not the
client query included a <set/> element, the server MAY simply return its
limited results, modifying the <set/> element it returns appropriately."
If an <index/> is specified in the MAM request, reject the request
rather than ignoring the desired index and returning wrong results.
XEP-0059 says that the server "MAY return a <feature-not-implemented/>
error."
Holger Weiss