Xavier Morel
ac3cb21836
The SSF had pretty much punted on nested o2m as that's... not usually a concern because few people are insane enough to put o2ms in their o2ms in their views. And also because even if somebody did, sometimes nothing would break because it turns out to be pretty difficult to actually get into *using* those things. MRP managed to do it though, and repro-ing required copying over parts of mrp.production and then understanding why it didn't fail: * obviously needs an o2m (f1) which contains an o2m (f2), in the view (an invisible tree inside a visible tree) * needs an onchange which somehow updates the sub-o2m * needs to actually trigger an onchange on the root form for f1, meaning f1 must be a dependency of a compute field or something (here I just marked every damn field as on_change as the optimisation of "don't call onchange when there's no need to" doesn't matter) Also needs to be working on an existing record with existing lines *and sublines* as the issue occurs with records to update. The issue here is that `_onchange_values` would clean up f1 e.g. send nothing for unmodified entries, and only send modified fields otherwise, but it would only do so for the toplevel, meaning the sub-level would not go through this step, and could send UPDATE commands with an `id` field (set to the original value but still). This would then proceed to blow up while loading the record, as id fields are not writeable. The fix is to perform `_onchange_values` recursively. Do that using a separate helper in order to avoid blowing up on override and whatnot, or faffling about with weird branching to get the "default" values in case they're not provided, the root function can get all the relevant bits and call the helper with them, then the helper does that setup internally and calls itself directly. An other issue I stumbled upon when investigating is a similar problem on *save*, due to an implementation detail of the SSF: UPDATE commands are fetched lazily. `_values_to_save` took care of "hydrating" all update commands (and validating and filtering them) of modified o2m fields, but as it would not do so recursively a modified f2 would not get properly hydrated and filtered, and could try to write `None` onto existing records. closes odoo/odoo#51350 X-original-commit: 3dfb4cfad849936748cc6a5b8f712e100461a86f Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>
4 lines
70 B
Python
4 lines
70 B
Python
# -*- coding: utf-8 -*-
|
|
from . import models
|
|
from . import nested_o2m
|