Fields with attribute readonly=True do not preserve on_change values

[Ferdinand]

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

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

Hi Ferdinand,

I should say I share your opinion. I think having a way to prevent user input but still allow on_change or other kind of event to silently pass a value to the server would be better allowed at some point (may be a special readonly value or only for readonly at view level).

Currently, because of that limitation, when you have a field that is optionally read-only, you may have to find very ugly indirect hacks to pass the value back.

For instance, a concrete example: in fleet_maintenance (extra addons), the user selects a number of month for support contract in a salr order line (by means of a date range). The date range selected actually determine the number of months which is the quantity of monthly maintenance product per order line. So you want that quantity field to be readonly and the user to select a date range instead. But having the qty readonly while passing it back to the server after the user select two dates was really ugly and challenging in my opinion.

You could consider this a blueprint (given the amount of open critical functional bugs) but I think in v5.2/v6 it would be much better ti have a clean way to achieve what Ferdinand and I suggest.

Also, for French readers, this issue has been discussed in the forum here:
http://www.openobject.com/forum/post35955.html?sid=4d7ea2ffc20cd97f761ea43fe2d7840b
For other others, this is the same topic thread translated by Google:
http://translate.google.com/translate?prev=hp&hl=fr&js=n&u=http%3A%2F%2Fwww.openobject.com%2Fforum%2Fpost35955.html%3Fsid%3D4d7ea2ffc20cd97f761ea43fe2d7840b&sl=fr&tl=en&history_state0=&swap=1

Hope this help. But again, not a priority given the other issues I think.

Raphaël Valyi.

[Fabien (Open ERP) (fp-tinyerp)]

Sorry, invalid.
May be create a wishlist for a new kind of system. But readonly means value can not be sent to the server.
We may have to add a new keyword, but I am not sure it's smart. May be you can do what you need with a hidden but not readonly field.

[Ferdinand (office-chricar)]

see
https://blueprints.launchpad.net/openobject-server/+spec/xml-readonly

[Jay Vora (Serpent Consulting Services) (jayvora)]

This is acceptable, butc sorry, we cannot introduce this in 6.0 currently.
Thanks.

[Jay Vora (Serpent Consulting Services) (jayvora)]

GTK team,

Please refer bug 426676 as well. This could be a server side issue,but needs a client side support.

Thanks.

[Alexis de Lattre (alexis-via)]

This issue is still present in OpenERP 6.1 ; we would really like to have a way to prevent direct user input on a field, and have it's value set by an on_change. I have several developments where it would be really nice to have this.

[Serpent Consulting Services (serpent-consulting-services)]

+1.

[Gustavo Adrian Marino (gamarino)]

Let me say it is a needed behaviour, in no way a nice to have feature.

In any case where you define a default value for a read only field, there
is no way to handle it with the current behaviour. The default data will be
sent to UI, but due to the readonly bad behaviour, the readonly fields will
not be updated on model create. In order to provide a default value, there
is no other possibility than writing a record on database, which in many
cases is a non desired strategy.
By the way, if you change the field on a action (using a write), the field
will be modified on UI, so the readonly field could be effectively modified
by an user action! (clearly inconsistent with the religious defense of the
"readonlyness" of the view definition!)

If the field was modified by an onchange event or if the value was
initialized by a default, the new value should be updated on create or
write at the end of the editing operation.

The requested change will not break any existing module. If someone is
expecting no change of the value via UI (which it will not be possible) and
it is providing no default value for a field, it will notice no change in
the UI behaviour.

Past reluctance to accept this requested it seems to be based more on a
personal opinion rather than on a balanced analysis of need and possible
drawbacks of the proposal

El 2 de marzo de 2012 16:05, Serpent Consulting Services <
<email address hidden>> escribió:

> +1.
>
> --
> You received this bug notification because you are 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
>

--

Gustavo Adrian Marino

Mobile: [phone]

Email: <email address hidden>

Skype: gustavo.adrian.marino

[Raphaël Valyi - http://www.akretion.com (rvalyi)]

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 i...

[Yann Papouin (yann-papouin)]

Something is missing here, we need a way to display a computation result to the user (in a readonly field) and store this result for later user.

Two widgets should exists:
- Input field in readonly (grayed) mode (with all onchange events processed and write support)
- Dynamic label with no input capabilities that should work like the current read only field

[Vadim - Enapps LTD (vadim-enapps)]

cant agree more. definitely this is needed.

[Alexis de Lattre (alexis-via)]

You can't imagine how much time I am loosing these days because of this issue. It's just crazy !

[ஆமாச்சு (amachu)]

It works in Web-client. Why not make it happen through Gtk too? +1 for this.

[Etienne Hirt (hirt)]

@amachu:
* In what Web-client does it work?
* How does it work in that webclient?
Thanks

[Cristian Salamea (ovnicraft)]

Hello Stefan, bug affects too web UI in 6.1

Regards

[Stefan Rijnhart (Opener) (stefan-opener)]

@Cristian Added the web project to this bug. Your duplicate mentions that this also affects 7.0, is that correct?

[Cristian Salamea (ovnicraft)]

Yes sir :)

[Olivier Dony (Odoo) (odo-openerp)]

It's a design decision, and it has not been decided to change it so far. Read-only fields are meant for information purpose and are not used to transfer actual data, so developers must not rely on them for persisting field values.
There are many workarounds for doing it (e.g. using a second invisible field), but this is generally seen as a bad pattern. Changing the current behavior *would* break many modules, we've tried it already.

[Cloves Almeida (cjalmeida)]

Couldn't a "calculated" attribute be added meaning "a field whose value could be dinamically set but not through the UI"? No change for current behavior and would provide for a better framework.

[Asgardinho (felipereyesazul)]

If this is not a bug it is definitely a top tier feature and should be on top of the wishlist, I like the idea from Fabian in 2009 to implement another keyword, probably something like 'informative' that have the functionality explained before, this way there wont be any problems with other modules that use readonly.

[Kyle Waid (midwest)]

I also concur with everyone else.

Seems like a coverup to a system problem. There are many cases when a readonly field is required, i.e, not allowing the user to change information but still able to see it and pass it to the server. An example:

on the partial picking wizard, what if I want to show the user all of the items, but not allow them to change any of them? This is not possible without duplicating the fields. If you review most any other ERP system there is a concept of a readonly field. By Olivier's own comment he makes the case for duplicating the data which is a bad design.

I do not believe you correctly define the definition of a readonly field based on your system behavior. This is one of the most troubling aspects of OpenERP, and by the number of requests and length of reports, its strange it has not been addressed.

To just ignore the issue and not address it certainly does not help. The whole concept here seems kind of moronic.

[Ferdinand (office-chricar)]

Frustrating ....

[Olivier Dony (Odoo) (odo-openerp)]

I gave some more details on the related OpenERP Help topic[1]. We really can't change this behavior now because it breaks existing modules in subtle ways, and the desire to change it is often driven by flawed use cases. Compatibility trumps convenience. Having two different attributes or widgets would also definitely seem overkill, especially since the new API comes with the necessary changes to make this mostly irrelevant.

BTW as far as default values are concerned, it seems to me that passing a _default_xxx in the context would also be propagated to the next create() call, and thus properly saved in the database even if the client does not send it as part of the values because it's read-only. (create() does apply the provided defaults for fields without an explicit value)

[1] http://help.openerp.com/question/2247/how-to-handle-reading-and-writing-to-read-only-fields

[Alloice Lagat (alloh2371)]

I also face a similar problem and i have tried to raise it here
http://help.openerp.com/question/26897/how-to-change-sales-order-line-price_unit-and-invoice-line-price_unit-readonly/

[tim diamond (timdiam)]

It seems remarkable to me that this functionality is not possible. Small things like this is what will drive a customer to choose another ERP solution for the LONG RUN. Please put this functionality on top priority.

[Ferdinand (office-chricar)]

it's drive way developers - customers will not realize the problem as there exists a workaround in overwriting create and write and using a shadow field

[Ethan Furman (ethan-stoneleaf)]

I'm probably wasting my breath but I just lost five hours trying to figure out my fields weren't being saved.

Scenario: using the OpenERP provided res.bank table, updated with two more fields. These extra two fields, along with the already existing bank_bic and bank_name fields, are copied into res.partner.bank via on_change. The customer can then modify the copied fields, in which case either the modified fields are wrong, or the data stored in res.bank is wrong. So I made the res.partner.bank fields readonly, reasoning that on_change is not the user and, sure enough, the data showed up on screen. Then I wrote my validator to make sure the information coming from res.bank was good, and spent the next several hours trying to figure out my data was not being saved.

Once I searched, I found this bug report within five minutes -- that should say something important about how common this problem is becoming.

Olivier, you say a fix has been tried, but other modules broke -- what modules were they, and how did they break?

[Ferdinand (office-chricar)]

Hi
you must use 2 fields
* readonly : to display
* hidden: to save

[Andrei Levin (andrei-levin)]

@Ferdinand: Unfortunately 2 fields approach will fail miserably if we reopen line that is not saved yet. We will find that the readonly field is resetted to default. (For example sale_order_line).

[Ferdinand (office-chricar)]

@Andrei
please look at
http://bazaar.launchpad.net/~camptocamp/c2c-rd-addons/6.1/view/head:/sale_uos_entry/sale.py

somehow we didn't encounter problems

[Andrei Levin (andrei-levin)]

@Ferdinand

in your example there are no readonly fields in the sale_order_line form. Readonly fields are on the main form. I'm talking about the form that opens when you wanto to add a new sale_order_line

Thank you, for your interest to my problem

[Goran Kliska (gkliska)]

Hi,
I think that when field is (readonly and required and "dirty" ) it should become "readonly_writable".
3 LOC patch or web module like http://t.co/TFCbFYy9DB

Best regards.
Goran Kliska

[tim diamond (timdiam)]

@Olivier

In your comment you mentioned "new api" that would make this irrelevant. My firm is really starting to get behind openERP and this feature is on the top of our wishlist.

Could you elaborate a little on when the new api is coming and what exactly it contains?