A Divendres, 25 de novembre de 2011 19:10:48, Cédric Krier va escriure:
> Hi,
>
> Today, I got a talk with Nicolas about the relevance of the workflow
> engine in Tryton.
> We came to the conclusion that it will be perhaps better to drop it.
> So here are the arguments:
>
> - The Subflow which is indeed a key feature in the design of workflow is
> never used in Tryton because by experience (on OpenERP) we knew that
> it doesn't allow enough flexibillity. Most of the time, you need to
> trigger the workflow in some other activities then the starting/ending
> one.
>
> - The flexibility. Normally the workflow engine must provide
> flexibility but in the reallity, we have most of the time more
> difficulty to modify it through modules (any standard module does it).
> So we manage it by inheriting some methods.
>
> - Simplicity. Just looking at the workflow of sale and you understand
> that when you try to modelise complet life cycle of a document, the
> workflow becomes very complex. But we can print a picture of it.
>
> - Misunderstanding, most of the developpers (and users) think that the
> workflow is linked to the status of the document but because of the
> nature of the engine, it is not. And you can have inconsistency
> between both.
>
> - Speed, it is well know that the workflow engine is not very fast. Does
> it deserve this sacrifice?
>
> - Security, this is a point where it is good. The access right to go
> througth a transition works well.
I agree in all those points. Also, I'd add that we were discussing not the
workflow engine, but the workflow and "state" of a document concept with
Dominique from SISalp, and I think that needs some revision too. The same way
subflows are not flexible enough, the "state" or "workflow" concept in a single
document is sometimes not flexible enough, either. The advantage is that it is
easy to understand but at the same time it is often used to impose some
restrictions that make user's life a bit complicated. Although, maybe that
discussion should go in another thread and with some specific examples, so will
try to come back to this later.
> So by what could we replace the workflow engine?
>
> The idea will be to have just simple method calls. Those methods will
> replace the activities. The transitions will be replaced by different
> way:
>
> - buttons which are linked to methods
> - methods that call other methods
> - triggers? (not sure because they can be heavy)
>
> The security will be replaced by capacities. So some method will be able
> to check (via decorator?) if the user has a specific capacity to run the
> method. The capacities will be defined in XML and they will be linked to
> groups.
> The workflow trigger will be replaced by overriding the right method of
> the target model (it is already done like that with model without
> workflow).
> Optional advantage of such design is the traceback of calls will be more
> clear.
Again, I agree with the general design. The decorator can be an smart way to
check capacities, but I ask myself how would those methods would registered in
the system in the first place?
Maybe we should allow PYSON expressions that indicated when an action is
possible and when not, the same way it is already done with 'required' and
'readonly' states in fields. Somehow that would define what currently is the
previous state of a workflow state.
Ok. Just let me try to a proposal for discussion:
class Sample:
confirm = fields.Action('Confirm', Equal(Eval('state'), 'draft')),
def confirm_action(self, ids):
pass
I think that something like this has the advantage of:
- "Register" the action so we can assign user/group permissions to it.
- Clearly states what needs to be the previous "state" before the action can
be executed.
- All the code is in the same file (no need to jump to XML for following the
workflow).
- Can be overriden by other modules.
Opinions?
--
Albert Cervera i Areny
http://www.NaN-tic.com
Tel: +34 93 553 18 03
http://twitter.com/albertnan
http://www.nan-tic.com/blog
--
tryton-dev@googlegroups.com mailing list
