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 protected]> 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: +54 911 5498 2515 Email: [email protected] Skype: gustavo.adrian.marino -- You received this bug notification because you are a member of OpenERP sa GTK client R&D, which is a bug assignee. 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 _______________________________________________ Mailing list: https://launchpad.net/~openerp-dev-gtk Post to : [email protected] Unsubscribe : https://launchpad.net/~openerp-dev-gtk More help : https://help.launchpad.net/ListHelp
