Make sure the "ExecStop" command line blocks until ejabberd is actually
stopped. This prevents systemd from killing the ejabberd process(es)
immediately.
Also, let the "ExecStart" command line block until ejabberd's startup is
completed. This makes sure that services which depend on ejabberd
aren't started up too early.
The "reload_config" command doesn't work the way admins would typically
expect, so it shouldn't be exposed via systemd. Those who understand
the behavior can execute the command using ejabberdctl.
Admins might expect ejabberd to be able to access data below /home or
/tmp. For example, they might use those locations to dump/restore
Mnesia backups, or as a document root for mod_http_fileserver or
mod_http_upload.
Fixes#1297.
This adds a new hook that is triggered for each invite to an MUC room:
- muc_invite(RoomJID, RoomConfig, From, To, Reason) -> ok
where
- RoomJID = From = To = #jid (see jlib.h)
- RoomConfig = #config (see mod_muc_room.hrl)
- Reason = binary()
XEP-0050 says: "The result for each stage (other than the last) of a
command's execution SHOULD include an <actions/> element." Some clients
insist on this.
Offline sessions should not be counted when reporting the number of
connected resources.
Apart from that, this number is now also reported when using a
non-default session management backend.
In the past, the "send_message" command sent a copy of the message to
each resource if the message was addressed to the bare JID of a local
online user. When message carbons are enabled, this creates duplicates;
and with MAM enabled, each copy is archived. Therefore, "send_message"
no longer creates copies of the message.
Check whether the 'from' and 'to' attributes are valid before bouncing
or resending a stanza from the stream management queue. They might be
invalid in certain corner cases.
Thanks to Evgeniy for spotting this.
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.
