A Dissabte, 3 de març de 2012 11:35:45, Cédric Krier va escriure: > On 03/03/12 10:59 +0100, Albert Cervera i Areny wrote: > > 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) > > This should go into the button design.
Well, the button will apply security restrictions to RPC calls only, won't it? > The current design was made close > to the workflow engine design in the purpose to make small (and > manageable) changes. > But of course at the end, I think the groups validation should go to the > button definition. > > > - Allows for several "workflows" > > As already stated, we don't see any cases where it is useful. Moreover, > you can always merge 2 workflows into one. Not important for me either :) > > - Doesn't put the names of the groups in the source code > > I don't see any issue with that. We already do it in domains, states > etc. I think it's important to be able to do that at DB level when possible. Administrators may want to be able to change group capabilities without programming. > > > 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. > > I don't think so. Look at the new sale design it works with 1 state > field but manage other kind of state like the delivery and invoicing > states. Don't know it enough. Will take a look at it. > > > 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). > > Indeed, I think the main issue is the button definition because it > have to combine 2 kind of states: > > - the workflow depending on the state of the Model > - the permission depending on the user group > > So yes, it will be great to manage the groups in the database but the > workflow must be managed in the code. > But any way, this is for the button improvement of Tryton. For now, with > the current "no-workflow" design, we don't loose a functionality as the > button definition was (and is still) managed in the XML. Ok. So we agree in the in the final goal. -- 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
