On 29/11/11 11:00 +0100, Albert Cervera i Areny wrote:
> A Dimarts, 29 de novembre de 2011 09:48:27, Cédric Krier va escriure:
> > On 29/11/11 08:59 +0100, Albert Cervera i Areny wrote:
> > > A Divendres, 25 de novembre de 2011 19:10:48, Cédric Krier va escriure:
> > >
> > > 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.
> >
> > This looks like the Button object I worked (before losing the work due
> > to crash disk) to allow to have xml view in separeted file [1].
> > So I think it should add some more parameters on it like the type
> > (action or method (no more workflow :-)).
>
> What would be the advantage of distinguishing between action and method? What
> would be the differences?action is running an ir.action like a report or a wizard. method is calling a method on the model. > > One question I got is when should we test the access right/state. > > For now, this design looks like it is only done on client side except if > > there is some extra code in the method. Or as you said we could use a > > decorator but the issue with decorator is the extension by other > > modules where you lose the fact that the decorator is called first but > > it is perhaps not a problem. > > What about overriding __getattribute__ method or something like that in > Model? > Too much overhead, maybe? Don't like too much. I prefer explicit. -- Cédric Krier B2CK SPRL Rue de Rotterdam, 4 4000 Liège Belgium Tel: +32 472 54 46 59 Email/Jabber: cedric.kr...@b2ck.com Website: http://www.b2ck.com/
pgpxtzFJ1K0qC.pgp
Description: PGP signature
