Ignore node plugin defaults if the plugin handling the request isn't
enabled, rather than ignoring 'default_node_config' options and
applying plugin defaults in that case.
Use any option specified via 'default_node_config' by default, and take
the remaining defaults from the node plugin handling the request. This
is the documented behavior.
Before this change, the code applied the plugin defaults only if no
'default_node_config' existed at all. And even this logic didn't work
as intended, since 'default_node_config' yielded an empty list in case
it wasn't configured, which resulted in plugin defaults never being
applied.
Don't merge 'default_node_config' settings with the default options of
the first configured node plugin. Otherwise, the latter might later
override those of the plugin that should handle a node creation request.
For example, the following configuration would lead to the 'flat'
options being used by default for 'pep' nodes as well:
mod_pubsub:
plugins:
- flat
- pep
Since commit 514c25caef, whenever a PEP
item was published, a notification was blindly sent back to the owner.
However, this should only be done subject to +notify filtering, as per
XEP-0163:
| the PEP service shall send notifications to all of the account owner's
| available resources (subject to notification filtering).
The motivation for the mentioned commit was that +notify subscriptions
initially didn't work for PEP node owners (#2108). However, that issue
was fixed by commit 5968bc9318 (#2112).
As a result, the owner's client was actually notified twice if the
client was subscribed to the node (e.g., via +notify).
Therefore, just omit the additional, blind notification.
Thanks to W. Martin Borgert and Daniel Gultsch for reporting the issue.
Make it explicit that the get_max_items_node/1 function returns
?MAXITEMS if the 'max_items_node' option isn't specified. The function
didn't actually fall back to 'undefined' (but to the 'max_items_node'
default; i.e., ?MAXITEMS) anyway. This change just clarifies the
behavior and adjusts the function specification accordingly.
Support XEP-0060's pubsub#item_expire feature by adding a command for
deleting expired PubSub items.
Thanks to Ammonit Measurement GmbH for sponsoring this work.
If we use _`whatever`_ here in ejabberd man pages,
it is converted to *`whatever`* in markdown,
and docs.ejabberd.im/Makefile converts to the proper links
Add a command for keeping only the specified number of items on each
node and removing all older items. This might be especially useful if
nodes may be configured to have no 'max_items' limit.
Thanks to Ammonit Measurement GmbH for sponsoring this work.
Allow for setting the mod_pubsub option 'max_items_node' to 'unlimited'.
If clients then request a 'max_items' limit of 'max', old items aren't
deleted when publishing new ones.
Thanks to Ammonit Measurement GmbH for sponsoring this work.
Let clients request the maximum limit for the node configuration option
'max_items' by specifying the special value 'max' instead of an integer.
This was added to XEP-0060, revision 1.17.0 (and clarified in revision
1.20.0).
Thanks to Ammonit Measurement GmbH for sponsoring this work.
If clients don't ask for a specific 'max_items' limit, use the value of
mod_pubsub's 'max_items_node' option as default, rather than the
hard-coded ?MAXITEMS value. This makes sure clients cannot circumvent a
smaller, configured limit.
Bump the default value for mod_pubsub's 'max_items_node' option, which
hard-limits the 'max_items' value requested by clients.
These days, use cases such as microblogging or XEP-0402 may need a large
number of items per node. Bumping the limit makes sure such
functionality is properly supported with the default configuration.
The size of a list of nodes returned for disco#items request
is now controlled by option 'max_nodes_discoitems'. The default
value is 100. The name and the default value of the option is
chosen to be consistent with mod_muc's 'max_rooms_discoitems' option.
This change requires Erlang/OTP-21.0 or higher.
The commit also deprecates the following options:
- log_rotate_date
- log_rate_limit
Furthermore, these options have no effect. The logger now fully
relies on log_rotate_size, that cannot be 0 anymore.
The loglevel option now accepts levels in literal formats.
Those are: none, emergency, alert, critical, error, warning, notice, info, debug.
Old integer values (0-5) are still supported and automatically converted
into literal format.
