this new plugin is a high level way to manage profile or entity identities, i.e. informations about them.
It has been created to handle easily data which can be in several location (e.g. roster, vcard-tmp, vcard4, etc.)
For now, only nickname can be gotten/set (set only works for profile's own identity, while get can be used on any jid).
- event node is handling the main metadata of the event, and invitees node handle the invitations/invitees answers
- invitees and blog node are automatically created and associated to the event, except if they are specified (in which cas the existing one are used and attached to the event node)
- extra metadata are added to <meta> elements
comments node access model is now copied from parent item by default. If whitelist access is used, parent item affiliations are copied too.
publish model is now open by default instead of subscribers
New methods getAffiliations (for checking affiliation by any entity) and getNodeAffiliations (for checking the affiliations of a node, for the owner), and theirs corresponding bridge methods.
/!\ new dependency: shortuuid
Plugin invitations allows to invite somebody without XMPP account, using an unique identifier.
The various arguments are explained in the docstring.
- plugin misc account has been reordered and cleaned a bit.
- new xmpp_domain setting is used to get the domain name of main XMPP server
- password generation method has been moved to tools.utils
- email sending method has been moved to tools.email
in-band was partially in core for historical reason, it has been moved to XEP-0077, and fixed. It is still incomplete, but should work for basic accounts creation.
this module aims is to help manipulate complex data from bridge, mainly for the template system.
It is in common and not only in frontends as it may be used in some case by backend, if it needs to use template system in the future.
- SàT can now handle components
- plugin have now a "modes" key in PLUGIN_INFO where they declare if they can be used with clients and or components. They default to be client only.
- components are really similar to clients, but with some changes in behaviour:
* component has "entry point", which is a special plugin with a componentStart method, which is called just after component is connected
* trigger end with a different suffixes (e.g. profileConnected vs profileConnectedComponent), so a plugin which manage both clients and components can have different workflow
* for clients, only triggers of plugins handling client mode are launched
* for components, only triggers of plugins needed in dependencies are launched. They all must handle component mode.
* component have a sendHistory attribute (False by default) which can be set to True to allow saving sent messages into history
* for convenience, "client" is still used in method even if it can now be a component
* a new "component" boolean attribute tells if we have a component or a client
* components have to add themselve Message protocol
* roster and presence protocols are not added for components
* component default port is 5347 (which is Prosody's default port)
- asyncCreateProfile has been renamed for profileCreate, both to follow new naming convention and to prepare the transition to fully asynchronous bridge
- createProfile has a new "component" attribute. When used to create a component, it must be set to a component entry point
- jp: added --component argument to profile/create
- disconnect bridge method is now asynchronous, this way frontends can know when disconnection is finished
- new PI_* constants for PLUGIN_INFO values (not used everywhere yet)
- client/component connection workflow has been moved to their classes instead of being a host methods
- host.messageSend is now client.sendMessage, and former client.sendMessage is now client.sendMessageData.
- identities are now handled in client.identities list, so it can be updated dynamically by plugins (in the future, frontends should be able to update them too through bridge)
- profileConnecting* profileConnected* profileDisconnected* and getHandler now all use client instead of profile
- new client.sendMessage method is used instead of sendMessageToStream
- client.feedback is used in OTR
- OTR now add message processing hints and carbon private element as recommanded by XEP-0364. Explicit Message Encryption is still TODO
- OTR use the new sendMessageFinish trigger, this has a number of advantages:
* there is little risk that OTR is skipped by other plugins (they have to use client.sendMessage as recommanded)
* being at the end of the chain, OTR can check and remove any HTML or other leaking elements
* OTR doesn't have to skip other plugins anymore, this means that things like delivery receipts are now working with OTR
(but because there is not full stanza encryption, they can leak metadata)
* OTR can decide to follow storage hint by letting or deleting "history" key
SkipHistory was skipping all remaining triggers just to skip history, which is not the intented behaviour.
Now history can be skipped by setting mess_data[u'history'] = C.HISTORY_SKIP, this way we won't skip importants triggers.
When history is skipped, mess_data[u'extra'][u'history'] will be set to C.HISTORY_SKIP for frontends, so they can inform user that the message is not stored locally.
- wrong elements were used in this plugging, it could not work properly
- use constants for hints
- add addHint method so other plugins can add a hint easily
- hints can be added by frontends in mess_data['extra']['hints'] (serialized dict) or by other plugins using addHint
- if history is skipped on message reception, mess_data['extra']['history']['skipped'] is set
- introduced PLUGIN_INFO['usage'] for usage information for developers
- messageSend trigger now use pre_xml_treatments so it doesn't block other triggers of higher priority
- text commands now use a very high priority, as it is local command and should not be blocked in most of cases
- new otrState signal, to send state change to frontends
- history is not skipped anymore, a future option may change this behaviour
- OTR trigger are skipped on groupchat messages
- context_manager is now in client instead of being global to plugin
- removed fixPotr as it is fixed upstream
note triggers should be improved for encryption methods, as skipping an encrypter may break security, but putting it in top priority may break nice features.
fix bug 170
