The callback is supposed to provide known options and their default
values, as long as the documentation. Passing default values into
get_mod functions is now deprecated: all defaults should be provided
by the Mod:mod_options/1 callback.
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.
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.
Carbon copies of private MUC message are generally not desired,
especially not when multiple clients joined the room with the same nick.
In this case, the MUC service usually sends PMs to all joined resources
anyway, so carbon-copying those PMs would create duplicates.
Don't carbon-copy messages of type "normal" that don't have a body
element as an immediate subtag. Those messages are usually generated by
clients or servers (as opposed to messages written by humans). This
includes MAM messages, for example.
Before generating a carbon copy for a resource, make sure it's actually
available. This handles the case where, for some reason, the
'unset_presence_hook' wasn't called during logout of a resource. Carbon
copies sent to that resource would otherwise be re-routed to another
resource (which might've received a copy of that message already).
When multiple resources have the same (highest) priority, the session
manager routes messages sent to their bare JID to each of these
resources. When another resource has a lower priority but receives
carbon copies, make sure it won't receive multiple copies of such
messages.
An earlier version of XEP-0280 specified the <received/> and <sent/>
tags to be siblings of the <forwarded/> element, whereas the current
version mandates them to be parents of <forwarded/>. The mod_carboncopy
module supports both variants. However, the check that makes sure
clients won't receive a copy of the messages they sent didn't work for
the old-style schema. This is now fixed.
Log one instead of three [info] messages when XEP-0280 (Message Carbons)
support is enabled or disabled successfully. On failure, log an
additional [warning].
As the session manager handles messages sent to unavailable resources
just like messages sent to bare JIDs, mod_carboncopy must do that, too.
That is, forward them only to those carbon-copy-enabled resources that
don't have a top priority, in order to avoid duplicates.