On 03/03/12 18:37 +0100, Albert Cervera i Areny wrote: > A Dissabte, 3 de març de 2012 18:01:27, Cédric Krier va escriure: > > 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. > > Sure but that requires the developer to take into account.
Like for any development :-) > Do you see any > issues with with adding the domain to ir.model.button even if not in the > first > version? For me, it makes harder to be sure that all cases are covered. Also domains could overlap so it requires to define some sort of priorities. At the end it makes stuffs more complicated for just some rare case that could be managed with few lines of code. > For the rest, I like Set 7, because we can separate workflow from security > with > two different decorators. -- 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/
pgpbGlCH3sjYt.pgp
Description: PGP signature
