workflow RSS Feed

cubicweb-forge #712813: missing transition from done to open in ticket's workflow

Sylvain Thenault — 2010-04-22T14:33-01:00

cubicweb-forge #714355: ticket workflow fixes

Sylvain Thenault — 2010-04-22T14:33-01:00

allow client to pass the 'got feedback' transition
the 'wait for feedback' transition should be available from the in-progress state
we should be able to go back to open from the done state

cubicweb-forge #475394: change ticket workflow

Katia Saurfelt — 2010-04-22T14:31-01:00

clients are lost when a ticket is pending validation, but ther version is not yet published. they think the ticket requires their attention, but there is nothing to validate yet since the version is still in development.

a solution would be to insert a state "done/fixed" between open and "validation pending". when a version gets published, all the tickets would move from "fixed/done" to "validation pending".

cubicweb #732246: defining permissions on workflow transitions

Nicolas Chauvat — 2010-03-05T16:35-01:00

defining permissions on workflow transitions is done differently than defining permissions on entities and relations. it would be nice to have one obvious way to do it. keeping what is done for entities and relations sounds better.

Cubicweb 3.2 : what's new

Aurelien Campeas — 2009-06-03T12:16-01:00

Cubicweb has experienced a rather large shakeup. Some things needed major restructuration, and that is why you have been left with few releases in the past few weeks. All the cubes available at http://www.cubicweb.org/project have been updated accordingly.

Version 3.2 brings us considerable improvements for:

Form construction

Cubicweb has had for long a nice system of forms smart enough to build themselves out of one cube's schema and some programmer-provided hints (or 'relation tags') to fine-tune things.

It was not easy however to customize these forms nor to build new ones from scratch.

So the new form systems draws from django-forms flexibility and style, keeping all the automatic goodness, and also make it quite easy now to build or customize forms at will.

This is the area were backwards compatibility is mostly gone. Custom forms will have to be rewritten. Don't be angry about that, the forms overhaul was long overdue, and from now it will only move in small evolutionary, well-mannered steps.

Relation tags

Along with the form subsystem is the __rtags__ mechanism substantially updated and made more extensible. The __rtags__ were quite incorrectly attached to entities class at the ORM level instead of being related to views and forms. The cubicweb.web.uicfg module now provides a comprehensive catalog of relation tags instances allowing automatic forms and views customisation in a nicely declarative manner.

Cubicweb 3.2 still remains compatible with the old __rtags__.

View selection/filtering

Cubiweb has also had for long a nice mechanism to filter views applicable to a given result set, the selector system. Various base classes were provided to hide selectors from the programmer and it had grown a little messy.

Selectors now have a nicer declarative feeling and the framework does not try to hide them. Quite the opposite: writing, maintaining and using selectors is now a breeze, and the base classes are gone. More is less !

However Cubicweb 3.2 remains backward compatible with the old selectors. Runtime warnings will help you track these and adapt as you see fit.

Other features

On the smaller features side, worth mentioning are:

new RichString attribute type in schema definitions, that simplifies format and encoding management,
inline relation edition is now possible (it was formerly limited to attributes) with 'reledit' view,
workflow definition has been simplified,
web/views has been somewhat cleanup up and reorganized,
automatic registration of app objects can now be switched to manual mode (no more hairy hard-to-debug registerer mechanism),
a generic SIOC view,
a view synthetizing permissions across a whole app.

We hope you enjoy this release! The cubicweb development team.

photo by jared under creative commons

cubicweb-forge #502158: broken forge instances because of workflow differences

Nicolas Chauvat — 2009-12-01T16:52-01:00

tracker defines workflows that forge ignores. this leads to broken instances.

cubicweb-forge #342655: Have a custom workflow for a given project

Arthur Lutz — 2009-12-01T11:16-01:00

A project has a workflow on the Version and Ticket objects. It would be nice if for a given project we could customize the workflow of the Tickets for example.

cubicweb #342657: Selectable workflows

Arthur Lutz — 2009-10-07T21:37-01:00

For a given type, have various workflow from which you can choose from.

For example, a Ticket on a forge has a base workflow, but for a given Project we could choose a different workflow that is in store.

cubicweb #343714: Enable workflow transition comments editing

Sandrine Ribeau — 2009-09-16T21:54-01:00

A transition comment should be editable by managers and creator of the transition.