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.
- template theme can be specified in parenthesis: (some_theme)path/to/template.html. Withtout parenthesis, "default" is used
- static content are supposed to be in [theme]/static, error pages in [theme]/error/[err_code].html
- default page are used in some case (2 for now): if error page with specified code doesn't exists, a base page is used, and if a page doesn't exist for a theme, the same one for default theme is looked for
- CSS files are automatically found for HTML pages
- CSS files can be split, the'll be added in the template according to the page requested.
- theme CSS file is looked for, and if not found the default theme equivalent is looked for.
- each element of a path can be associated to a CSS file, and styles.css is always there. For instance if blog/articles.html is requested, the following CSS can be included: "styles.css", "blog.css", "blog_article.css". They all must be in /static
- if the automatic finding of CSS files is not wanted, css_files arguments can be used instead, with full relative path (i.e. including theme)
- CSS files can be merged and included inline with css_inline argument
- root_path can be specified, it will be used as a prefix for static files
- requested theme (which may differ from actual theme, e.g. if the template is not found and default one is used instead) is available in template with "theme" variable
- added getThemeAndRoot method to retrieve theme and theme root path from template
- quick_app: don't fail when we can't get autodisconnect parameter
- bridge: removed useless BridgeFrontend parent class
- use of TypeError, unicode and list to workaround Pyjamas incompatibilities
template output use the new template renderer and data_objects module in backend tools.
Options can be specified: template to give a direct path to template, browser to display result directly, inline-css to include css in the HTML page.
Default template can be specified in command's TEMPLATE attribute, and a template_data_mapping method is called if it exists to map data to what is expected by the template.
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.
jinja integration is being rewritten to be used not only in Libervia, this is a first step which put the renderer in backend/frontends tools.
The renderer is mainly HTML oriented, but may be used for other files.
sat_templates dependency is needed to use it.
- blog/get will retrieve and parse blog items on specified service/node and can request only one or more specific items according to ids of max value
- it takes profit of outputs and the new extra_outputs: a default output display microblogs as key/value, a fancy one display it in a more confortable way for reading it the terminal
- for default output, keys can be filtered using --key argument
- extra outputs are output locals to a command which can be used in addition to the generic one which are compatible
- added --output_option argument(s) to specify option specific to selected output
- Jp.command now references the running command
- profilesGetList now handles clients and components boolean arguments, to filter profiles
- jp: added --clients and --components options to profile/list
- profilesGetList now returns sorted profiles
- 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
- feedback method is a helper method to quickly display an info message to user
- sendMessage is the method used to send a message in the stream, using message data dictionary.
It inclure a trigger point which can't be cancelled, it is intended for e2e encryption method which don't do full stanza encryption.
- "send" trigger point is disabled as it is not used at the moment
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
- use the new convention for bridge names (getMenus ==> menusGet, etc.)
- menu now use canonical path, which is the untranslated path with each element stripped and lowercase, it must be unique by menu type
- added menuLaunch method to manually launch a menu like an action, canonical path is used instead of id
- added SECURITY_LIMIT_MAX constant
- memory.cache is now used
- getAvatar and setAvatar has been renamed to avatarGet and avatarSet to follow new convention
- getAvatar now return (optionally) full path, and may request vCard or only return avatar in cache
- getAvatarFile has been removed as it is not needed anymore (avatarGet can return full path)
- getCard has been removed from bridge as it was only used to request avatar
- new internal method getBareOfFull return jid to use depending of the jid being part of a MUC or not
- cache is now set per profile in client, instead of a general one for all profiles
- thanks to the use of memory.cache, correct extension is now used in saved file, according to MIME type
- fixed and better cache handling
- a warning message is shown if given avatar hash differs from computed one
- empty hash value is now in a constant, and ignored if received
- QuickApp has been updated to follow new behaviour
- Primitivus has been fixed (it was not declaring not using avatars correclty)
- jp has been updated to follow new methods name
