Several documentation callbacks (doc/0 and mod_doc/0) are implemented
and `ejabberdctl man` command is added to generate a man page. Note
that the command requires a2x to be installed (which is a part of
asciidoc package).
Now every such string MUST be encapsulated into ?T() macro.
The macro itself is defined in include/translate.hrl.
Example:
-module(foo).
-export([bar/1]).
-include("translate.hrl").
bar(Lang) ->
translate:translate(Lang, ?T("baz")).
This commit introduces `use_mam_for_storage` option that take boolean
argument. Enabling it will make mod_offline not use spool table for storing
offline message, but instead will use mam archive to retrieve messages
stored when offline.
Enabling this option have couple drawback currently, only messages that
were stored in mam will be available, most of flexible message retrieval
queries don't work (those that allow retrieval/deletion of messages by id).
This option disable storing separate mucsub message for each individual
subscriber but instead when user fetches archive virtual mucsub messages
are generated from muc archives.
Since we now require R19, we shouldn't need that anymore.
There are still couple places where p1_time_compat:unique_timestamp() is
used as there is no direct equivalent.
Note that support for older specification is completely dropped,
i.e. no backward compatibility is provided since the XEPs are
still very experimental and being changed drastically
This change should apply usual logic for message wrapped in mucsub except
check for groupchat message, so messages without bodies for example
should be rejected
As mod_offline currently doesn't preserve metadata, add an explicit
check for messages retrieved from offline storage to avoid stripping
their stanza IDs.
Thanks to Zuglufttier for spotting this.
After some discussion with the community it was decided to
clean the configuration file from excessive comments and
explicitly configured default values. Also, mod_mam and
mod_http_upload have been added.
The rationale for this is to have a clean and not bloated
configuration file which doesn't scare away newcomers and
which has all features from the Compliance Suite 2018 (XEP-0387)
enabled by default.
For further configuration an admin is encouraged to read the
documentation at https://docs.ejabberd.im/admin/configuration
The header consisted of too many unrelated stuff and macros misuse.
Some stuff is moved into scram.hrl and type_compat.hrl.
All macros have been replaced with the corresponding function calls.
TODO: probably type_compat.hrl is not even needed anymore since
we support only Erlang >= OTP 17.5
Since we got rid of all bottle-neck processes and we have
a connection pool for every database, the option is no longer
needed and in fact is detrimental: in practice what you get
is just a bunch of overloaded processes in the IQ handlers pool
no matter how much you increase the `iqdisc` value.
Given that there are close to zero operators understanding
the meaning of the option and, hence, not using it all,
it's not simply deprecated but completely removed.
The commit also deprecates the following functions:
- gen_iq_handler:add_iq_handler/6
- gen_iq_handler:handle/5
- gen_iq_handler:iqdisc/1
If set to `true`, all incoming XML packets are fully validated
against known schemas. If an error occurs, the packet will be bounced
with the corresponding error reason. The default value is `false`.
The option might be useful to protect client software from sofisticated
bugs related to XML validation as well as for client developers
who want to catch validation errors at early stage of development.
Note that the option might have slight performance impact, so use it
with care on loaded machines.
When the option is set to `true`, the module will generate
CAPTCHA challenges for incoming subscription requests. The option
also implies that option `drop` is set to `true`. Note that
the module won't generate CAPTCHA challenges for messages: they
will still be rejected if `drop` is set to `true`.
Fixes#2246
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.
