A Dissabte, 3 de març de 2012 10:15:19, Cédric Krier va escriure: > On 03/03/12 08:53 +0100, Albert Cervera i Areny wrote: > > A Diumenge, 26 de febrer de 2012 19:25:45, Cédric Krier va escriure: > > > On 26/02/12 17:46 +0000, [email protected] wrote: > > > > Reviewers: , > > > > > > > > > > > > > > > > Please review this at http://codereview.tryton.org/256001/ > > > > > > > > Affected files: > > > > M trytond/model/__init__.py > > > > A trytond/model/workflow.py > > > > > > This is a first try. It will be good to discuss the design. > > > > I've been thinking about the design and I think we can make it more > > generic. In fact, I think we can fully drop the "workflow" word and talk > > simply about security or permissions. > > > > My proposal is to replace "@Workflow.transition('cancel')" with something > > like "@Security.check()" and let capabilities to be checked with > > "ir.rule.group" or something similar. > > > > So the security rule would need: > > - A domain expression > > - A group of users > > - A model > > - A function name > > > > So a function with the decorator of a given model can be executed if > > domain expression and group match any of the existing rules. > > So the only difference in terms of possibilities in your proposal is to > use a full domain than just a fixed one based on the _transition_state > field.
Not only this. It also allows to: - Use it for something not directly related to a workflow. Simply an action that you want to restrict to some users in some circumstances (certian values) - Allows for several "workflows" - Doesn't put the names of the groups in the source code > Why not! But I find that the current limitation force developer > to have a clean "workflow" for the users based on a simple field. Almost > every time, I speak with users about workflow they speak in terms of > state. A workflow, as a concept, is very clean and easy to understand, but at the same time, it has some problems because it imposes some restrictions, while in fact you usually want to handle several "states" such as the status of delivery, the status of invoicing, etc. > What I really don't like is to reuse the ir.rule.group or any thing else > stored in the database because the extension of something stored in the > database is painful (this is the main purpose of this switch). IMHO the problem with current workflow (v2.2) is that the flow is kept in the database. That is solved in the new design but the problem is that permissions are managed in python code. I think we want "workflow" to be handled in python (that should happen when we have the fields.Button with the appropriate states attribute) and "group permissions" to be handled in the database (just like we do with model access and rules). -- 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 -- [email protected] mailing list
