On 03/03/12 17:34 +0100, Albert Cervera i Areny wrote: > A Dissabte, 3 de març de 2012 16:53:19, Cédric Krier va escriure: > > On 03/03/12 12:19 +0100, Cédric Krier wrote: > > > On 03/03/12 12:12 +0100, Albert Cervera i Areny wrote: > > > > A Dissabte, 3 de març de 2012 11:35:45, Cédric Krier va escriure: > > > > > > 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. > > > > > > I will try to update the current patch, I think I have an idea on how to > > > do it that will not change too much the current patch. > > > > I made the implemenation in the Set 7. > > Thank you for your quick update. However I find a problem with it, and it is > the fact that group permissions are applied to functions only (nodes of the > workflow), whereas previous designs were at transition level (edges of the > workflow). > > That means that with Set 7 you cannot create a group with these permissions > in > sale.sale: > > - They *can* move from quote to draft > - They *cannot* move from cancel to draft > > As permission is at the button either you allow them to execute "draft" or > you > don't. You cannot make it depend on current state. That's why my proposal > added a domain to what you called "ir.model.button". Adding it, makes it > possible to check capabilities on transitions, not only on actions.
Indeed it is the case as each functionnalities are separated, you can combine them the way you want. So it is up to the developer to design buttons as he wants. More over, it is also possible to deactivate a button and split it into 2 buttons. So I don't think it is an issue. -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: [email protected] Website: http://www.b2ck.com/
pgprUZsLMjxp4.pgp
Description: PGP signature
