Don't forget the push session ID if the client resumes a stream
management session. This makes sure no push notifications are generated
for a connected client with a resumed stream management session.
Thanks to Thilo Molitor for spotting the issue.
The fact that mod_push uses a timestamp as a push session ID is just an
implementation detail. Rename things accordingly to avoid confusion.
However, stick to "timestamp" in the storage modules, as it corresponds
to the database column names/types, there.
Fix the problem that no push notifications were triggered in the case
where all of the following conditions applied:
- The XEP-0198 session has been resumed at least once.
- The XEP-0198 session is pending (i.e., the client is disconnected).
- The message wasn't stored in the user's MAM archive (e.g., because it
was of type "groupchat").
The problem was introduced in cd336369a5.
Many thanks to Friedrich Altheide for reporting the issue and to Thilo
Molitor for his help with tracking it down.
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
Unwrap MUC/Sub messages so that our check for a message body yields the
correct result.
Many thanks to Robert Schuh for pointing out the issue and suggesting a
fix.
Closes#3565.
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).
This commit removes the 'store_offline_message' hook which didn't allow
mod_push to suppress notifications when storing an offline message
failed (due to the offline spool size limit being exceeded or due to
database issues).
Fixes#3120.
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")).
While distinguishing actual chat messages from other message types,
don't classify all <encrypted/> messages as chat messages, but only
those that have a <payload/> element.
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
Set the 'include_body' option to a static text by default. Some app
servers check for the presence of a 'last-message-body' field to
distinguish between notifications generated for actual chat messages and
notifications triggered by other types of traffic.
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
Don't include a urn:xmpp:push:summary form in push notifications that
are triggered by outgoing messages. App servers might use the form
fields to generate user-visible notifications directly (as opposed to
just waking the client app). This is usually not desired for outgoing
messages.
If the 'include_sender' and/or 'include_body' options are specified,
also include a urn:xmpp:push:summary form in push notifications that are
generated for carbon-copied messages (with a body).
Some mobile apps might only be notified on actual chat messages with
a body, so don't let mod_push_keepalive reset the stream management
timeout on other types of traffic.
Add 'include_sender' and 'include_body' options. If one or both of them
are set to 'true', a urn:xmpp:push:summary form with the enabled
field(s) is included in push notifications that are generated for
messages with a body.
The 'include_body' option can instead be set to a static text. In this
case, the specified text will be included in place of the actual message
body. This can be useful to signal the push service whether the
notification was triggered by a message with body (as opposed to other
types of traffic) without leaking actual message contents.
If a pending stream management session is closed with a stream error,
this is usually due to the client opening a new stream that conflicts
with the old one. Don't generate a push notification in this situation.
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
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.
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.
