[FIX] Readonly fields not being stored. #97
Conversation
If the wizard turns a field to readony because the combination means it is unenterable now, then the value needs to be submitted when the client attempts to write the record. Since the Odoo client does not submit readonly values, then we need to ensure we get that value by keeping an "invisible" equivalent of the real value, which is never readonly.
…to be custom, too.
Codecov Report
@@ Coverage Diff @@
## 10.0 #97 +/- ##
=========================================
+ Coverage 61.11% 64.71% +3.6%
=========================================
Files 14 14
Lines 1368 1386 +18
=========================================
+ Hits 836 897 +61
+ Misses 532 489 -43
Continue to review full report at Codecov.
|
|
@richard-willdooit when a field cannot be written because of the restriction rules then it means that the value should not be entered (invalid configuration). If we propagate the invalid value it will then likely return a ValidationError. I think it was you that made a fix that turns values empty when not provided by the client. Is there some other scenario that I'm missing? |
|
@PCatinean You are correct, but the problem is the Odoo front end. Consider this: Attribute Model:
Attribute Engine
Somebody configures a product: Then they choose to reconfigure. The wizard submits the value for Model as Advanced 2 because it has changed, but does not submit a value for Engine because it is unchanged. The backend correctly decides that unsubmitted values are unchanged, and uses the previously stored value of Turbo Now, they choose to reconfigure. The wizard is correct. It clears the options for engine, and makes it readonly. However, Odoo NEVER submits form values which are readonly, even if changed. So it submits the value for Model as Basic, but does not submit a value for Engine because it is readonly. The backend assumes that unsubmitted values are unchanged, and uses the previously stored value of Turbo, but this is invalid! |
|
I have thought about another way to solve this, and it would actually make the readonly/required domains on the wizard easier to manage as well. At the moment, add dynamic fields tries to create readonly/required "attrs" by pre-parsing the domains at that point. This has a couple of negatives:
While the solution I have proposed here sorts out one lot of things (passing of readonly values back) an alternate way would be to have an invisible field associated with each value which determines the attributes as readonly/required. The onchange would then set this value based on the calculated domains of the window. This means that the domain calculation could be as complex or as simple as needed and would only ever be in one place (at the moment, we have to implement the domain calcs, and then reverse engineer them to a degree to work with attrs). I will try and look at this soon and propose an alternative. |
|
@richard-willdooit sorry for the delayed response I'm really under pressure lately. For readonly fields I was thinking a simple javascript function to remove all readonly attribute from all fields just as clicking the submit button form. Would be much less work this way. I will do my best to review and integrate the mentioned PR's in the next version that I'm preparing. |
|
I think #104 is a better solution... |
If the wizard turns a field to readony because the combination
means it is unenterable now, then the value needs to be submitted
when the client attempts to write the record.
Since the Odoo client does not submit readonly values, then we
need to ensure we get that value by keeping an "invisible" equivalent
of the real value, which is never readonly.