Comment 9 for bug 378824

Hello guys,

So just as I reported back in early 2009, I still think it's a framework
bad design or bug if you like. Gustavo explained why again.
Now, until this may hopefully finally be fixed (OpenERP SA are you here?),
here is the pig work around I used to do those years:
let the field as readonly and implement tthe on_change function. But also,
override the create and write methods of the objects to set again the field
value (same function as for the on_change) in case it's not there.
This way after on_change the value will not be set. But when the user will
click on the save button it will be properly set. It's a very ugly code
duplication and this is brittle between the on_change event and the save
event, but this almost the only option all the framework let us today.
Other options involve adding extra fields with inverse function definition,
but I think it's just worse.

I know some how don't do implementation anymore don't see the issue here.
Well, just to give you an idea, last week in less than 24 hours, the issue
as been raised by 3 Akretion co-workers and it was almost a blocker in all
those case. So engineers with respectively 4, 3 and 1 year of full time
experience with OpenERP where blocked on that and had to ask me for a
workaround. Now imagine the new partners OpenERP SA tries to hire... Yes,
the framework need to be improved else there will be no massive success for
OpenERP...

On Mon, Mar 5, 2012 at 5:59 AM, Francesco OpenCode Apruzzese <
<email address hidden>> wrote:

> ** Description changed:
>
> readonly=True (in py and xml) does allow programs to write but not to
> save the field.
> - onchange triggers can write into "readonly=true" fields, but this
> information is quietly lost during save
> + onchange triggers can write into "readonly=true" fields, but this
> information is quietly lost during save
>
> Example (abstract)
> onchange(qty,price)
> returns value=qty*price
> value is a database field.
>
> it seems to me that readonly=true should only prevent user input.
> and that onchange is considered as "user input"
>
> how should a readonly field be filled if neither user nor program can set
> a value?
> may be I am missing something.
>
> may be an attribute "enterable" =false (default true) could prohibit
> user input and allow program input
>
>
> http://doc.openerp.com/developer/2_6_views_events/views/design_element.html
> just says "read only"
>
> thanks
>
> --
> You received this bug notification because you are a member of OpenERP
> Drivers, which is subscribed to OpenERP GTK Client.
> https://bugs.launchpad.net/bugs/378824
>
> Title:
> field attribute readonly=True
>
> Status in OpenERP GTK Client:
> Confirmed
>
> Bug description:
> readonly=True (in py and xml) does allow programs to write but not to
> save the field.
> onchange triggers can write into "readonly=true" fields, but this
> information is quietly lost during save
>
> Example (abstract)
> onchange(qty,price)
> returns value=qty*price
> value is a database field.
>
> it seems to me that readonly=true should only prevent user input.
> and that onchange is considered as "user input"
>
> how should a readonly field be filled if neither user nor program can set
> a value?
> may be I am missing something.
>
> may be an attribute "enterable" =false (default true) could prohibit
> user input and allow program input
>
>
> http://doc.openerp.com/developer/2_6_views_events/views/design_element.html
> just says "read only"
>
> thanks
>
> To manage notifications about this bug go to:
> https://bugs.launchpad.net/openobject-client/+bug/378824/+subscriptions
>