openerp-expert-framework team mailing list archive

[Niels Huylebroeck <nh@xxxxxxxxxx>]

Posting this because it was in the expert-production mailing list by
accident:

---------- Doorgestuurd bericht ----------
Van: Niels Huylebroeck <nh@xxxxxxxxxx>
Datum: 19 april 2012 10:26
Onderwerp: Re: [Openerp-expert-production] Open letter for Client API
specification.
Aan: openerp-expert-production@xxxxxxxxxxxxxxxxxxx


Eric,

I completely agree with you, however we've just received word from OpenERP
SA that they consider the GTK obsolete and will not upgrade the behaviour
on the GTK client to be identical to the Web client behaviour.

We're still in discussion with OpenERP for this issue so the final word has
not been said, but it's proving to be something they are not easily
accepting as a bug but rather consider it a feature.

Regards,
Niels

Op 19 april 2012 05:37 schreef Eric Caudal <eric.caudal@xxxxxxxxxxxxxx> het
volgende:

 This will be completely refactored for 7.0: related calculated fields will
> pull from original field and not the other way round.
> Anyway both client should behave identically...
>
>
>   [image: openerp]
>
> *Eric CAUDAL*, CEOeric.caudal@xxxxxxxxxxxxxx
> Cell: + 86 186 2136 1670. Skype: elico.corp*Elico Corp - OpenERP Ready Partner, Shanghai.*http://www.openerp.net.cn
>
>
> On 04/19/2012 11:27 AM, Graeme Gellatly wrote:
>
> Interesting question.
>
>  I think a. is what most modules are expecting, and certainly before the
> web client existed this was the only expectation.
>
>  There is a danger with b of a circular loop.  Field a changes b, b
> changes c, c changes a etc etc.  The second issue with b is ugly expensive
> methods like product_id_change which is called in full or part by half at
> least 3 different SO line fields.  Just adds a lot of overhead, so if the
> case was b, then there would need to be safeguards in place against calling
> the same method multiple times unnecessarily (although I do note that this
> case already occurs in a in the GTK when you create a record)
> - definitely those methods would need rewriting (although noted that in
> fact many already have been in 6.1, possibly for that reason)
>
>  Broadening the issue slightly although still relevant to this discussion
> - what if the field is invisible, readonly, or outside a users security
> rights.  So are we talking user changes, or client changes.  I have no
> preference either way, but if b is to be the expectation then GTK must
> support, and it would be nice for there to be a way of telling what input
> that triggered the call.
>
>