[Cubicweb] CubicWeb 3.25 release
denis.laxalde at logilab.fr
Fri Apr 14 16:48:19 CEST 2017
I am pleased to announce the release of CubicWeb 3.25. Many thanks to
contributors of this release which, according to Mercurial, are: Adrien
Di Mascio, Alain Leufroy, Arthur Lutz, Christophe de Vienne, David
Douard, Denis Laxalde, Julien Cristau, Olivier Cayrol, Philippe Pepiot,
Rémi Cardona, Samuel Trégouët and Sylvain Thénault.
Main changes in this release are listed below.
* A new option `connections-pooler-enabled` (default yes) has been
allow to switch off internal connection pooling for use with others
such as pgbouncer_.
.. _pgbouncer: https://pgbouncer.github.io/
* In `deleteconf` view (confirmation before deletion), the list of
composite objects that would be deleted along with the primary entity is
* The ``cubicweb.pyramid`` module now provides a Paste application factory
registered as an entry point named ``pyramid_main`` and that can be
run a Pyramid WSGI application bound to a CubicWeb repository.
* A new configuration type ``pyramid`` has been added to create CubicWeb's
instances (through ``cubicweb-ctl create -c pyramid <basecube>
This configuration bootstraps a CubicWeb instance that is essentially a
repository plus the minimal setup to run a Pyramid WSGI application
of it. Noticeably, it does not ship all *web* configuration but rather
relies on configuration declared in a ``development.ini`` file for any
* A new way to declare workflows as simple data structure (dict/list)
introduced. Respective utility functions live in ``cubicweb.wfutils``
module. This handles both the creation and migration of workflows.
* A new IDublinCore adapter has been introduced to control the generation of
Dublin Core metadata that are used in several base views.
* It is now possible to *derive* rtags using their ``derive`` method
(0849a5eb57b8). Derived rtags keep a reference to the original rtag
hold custom rules, allowing changes which are done in the original
derivation to be still considered.
* A new ``cubicweb-ctl scheduler <appid>`` command has been introduced
background and periodic tasks of the repository (previously called
tasks*). In a production environment, a process with this command
run alongside with a WSGI server process (possibly running multiple
Backwards incompatible changes
* As a consequence of the replacement of the old looping tasks manager by a
scheduler, all cubicweb-ctl's "start" commands (i.e. ``start``,
``wsgi``) do not start repository *looping tasks manager* anymore, nor do
they start the scheduler. Site administrators are thus expected to start
this scheduler as a separate process. Also, registering looping tasks
calling ``repo.looping_tasks()``) is a no-op when the repository has no
scheduler set; a warning is issued in such cases. Application
rely on repository's ``has_scheduler`` method to determine if they should
register a looping task or not.
* In ``cubicweb.pyramid``, function ``make_cubicweb_application`` got
into ``config_from_cwconfig`` (950ce7d9f642).
* Several cleanups in repository's session management have been conducted
resulting from changes introduced in 3.19 release. Among others, the
``cubicweb.server.session.Session`` class has been dropped, and request
``session`` attribute is now tight to a web session whose implementation
depends on the front-end used (twisted or pyramid). Hence this attribute
should not be accessed from "repository side" code (e.g. hooks or
and has lost some of his former attributes like ``repo`` which used to
reference the repository instance. Due to this, you don't have
to session's data through the connection, which leds to deprecation
``data`` attribute and removal of ``get_shared_data`` and
methods which are deprecated since 3.19.
* Support for 'https-url' configuration option has been removed
* The `next_tabindex` method of request class has been removed
* The `cubicweb.hook.logstats.start` hook was dropped because it's looping
task would not be run in a web instance (see first point about repository
* ``uicfg`` rules to hide the opposite relation of inlined form are not
automatically added, because this was actually done randomly and so not
reliable, so you'll have to add them manually:
autoform_section.tag_object_of(('CWUser', 'use_email', 'EmailAddress'),
More information about the Cubicweb