priority is needed because we'll need to inspect former items on retract to check the
Acitivy to use (it may be an `Undo` activity is some cases), and this must be done before
the cache is updated by pubsub cache plugin.
rel 370
Priority lets order the callback list when an event is received. This is important in some
use case, notably when a plugin needs to check the former item before it is deleted from
cache or updated.
rel 370
Repeating a post as specified at https://xmpp.org/extensions/xep-0277.html#repeat is now
implemented. On sending, one can either use the new `repeat` method (or the bridge
`mbRepeat` one from frontends) to repeat any XEP-0277 item, or use the field `repeated` in
microblog data's `extra`. This field must mainly contains the `by` field with JID of
repeater (the "author*" field being filled with original author metadata), and the `uri`
field with link (usually `xmpp:` one) to repeated item.
When receiving a repeated item, the same `repeated` field is filled.
rel 370
When a XEP-0372 mention is received, the linked pubsub item is looked after in cache, and
if found, it is send to mentioned entity with `mention` tag added.
However, this doesn't work in some cases (see incoming doc for details). To work around
that, `@user@server.tld` type mention are also scanned in body, and mentions are added
when found (this can be disabled with `auto_mentions` setting).
Mention are only scanned in "public" messages, i.e. for pubsub items, and not direct
messages.
rel 369
when a mentions are found in AP items (either with people specified directly as target, of
with `mention` tags as in
https://www.w3.org/TR/activitystreams-vocabulary/#microsyntaxes), they are converted to
XEP-0372 `mention` references.
This is only done for Pubsub items (i.e. not for private messages).
rel 369
synchronisation used to be skipped when the node was existing and `resync` was not set,
however the case happens when a node is subscribed but not synchronised, thus this patch
update the behaviour to be sure to have the node synchronised.
rel 369
metadata are converted to vCard4 (XEP-0292).
Avatar is converted to User Avatar (XEP-0084), it is downloaded, resized, converted and
cached on first request.
If avatar is bigger than 5 Mio, it won't be used.
rel 368
XMPP identity data (coming from various XEPs, notably XEP-0292 (vCard4) and XEP-0084 (User
Avatar)) are now used to complete actor data.
Avatar files can now be delivered with the `avatar` type in URL.
rel 368
implementation of vCard4, the dedicated <IQ/> protocol is not implemented because it's
obsoleted (see comments).
Fow now, only `fn`, `nickname` and `note` are handled.
rel 368
cached file filename is now always UID + extension to avoid collision. `filename` argument
as been renamed to `original_filename`, it is store if present, and used to guess media
type when necessary.
handle retractation of messages. As it is not possible to know from the AP item alone if
we need to to a message retractation (XEP-0424) or a pubsub retractation (XEP-0060), we
now cache sent message, and decide which method to use according to how the item is cached
(i.e. in message history or in pubsub cache).
rel 367
Convert XEP-0424 message retractation request to suitable AP delete activity.
The message workflow and its triggers are now used instead of a direct observer, as it is
now possible to do so with component, and this let other plugin to parse and eventually
update metadata.
rel 367
new generic `get` allow to retrieve an ORM object with given column and value, and
optionally join load attributes.
In `delete`, it is now possible to specify instances to add to session, this allow, to
update them in the same transaction. It is also now possible to specify a list of object
to delete them all in the same transaction.
rel 367
- `origin_id` is added as a column instead of being just in extra, as it an important data
to filter on.
- Add some constraints.
- Add `serialise` method to Message and Subject.
message workflow were not used for components so far. This patch activate it, normalise
namespace to the client one to simplify parsing, and use SatXMPPComponent.sendHistory and
SatXMPPComponent.receiveHistory to indicate if a component should store sent and received
message in database (they both default to False).
OTR plugin is deactivated for components.
rel 367
when an item `retract` is received from a node from which an AP actor is subscribed, a
corresponding `Delete` activity is created and sent to AP followers.
Trying to retract an item from a virtual node of the gateway pubsub service now return a
`forbidden` stanza error (those nodes are handled on AP side and thus are not owned by
XMPP entities).
rel 367
when an error is received on unsubscribe because user was not subscribed, a warning is
logged, but no exception is raised anymore, as the expected result is reached.
