[8.0/9.0/10.0/11.0/master] Incorrect multi-level onchanges #20163
Comments
|
@pedrobaeza I have a similar module which works using |
|
Thanks for the tip. I'm going to try and tell you. |
|
@gdgellatly I'm afraid it doesn't work. In fact, in the real module I'm just doing like you say: https://github.com/OCA/account-closing/pull/50/files#diff-a1e53f9a256c02d42410243e01d9cc71R138 |
|
Bugger, I had hoped these onchange + relational field issues like these would have been smoothed out in the move to v11 |
sle-odoo
added
Framework
|
@dhannyz we have now the tools to properly fix such issues, and make sure they do not come back. @pedrobaeza thanks for such a nice bug report. I'll work on it tomorrow and see what I can do. |
|
@pedrobaeza The issue is fixed in v11 from rev. 16c9013 Regards |
|
Thank you very much for the patch. Isn't there any possibility to backport it, taking into account that I have backported the ORM part?: |
|
The webclient code (including the JS part of the onchange mechanism) has been completely rewrote in v11, so there is no chance that this can be backported. |
|
OK, it's a pity, but thanks again. |
|
@aab-odoo |
|
@aab-odoo Seems that this is not correctly fixed. In OCA/account-closing#58 we try to implement this onchange. According to the instructions in 16c9013, when you change the o2m_1, the o2m_2 is proposed. But if you save WITHOUT OPENING the form view of the o2m_1, the o2m_2 is not saved. If you open FIRST the form view for each o2m_1 record, and then you save the main record, then it is fine. If I manually open the form view of the o2m_1 record. If I save without opening the form view of the o2m_1 record: |
|
Hello @jbeficent Yes, we are aware of this behavior. We discussed a lot about it, actually. The problem is that we can't save the value of o2m_2 when the form view hasn't been opened as it is right now, because without opening the form view, we don't know the type of o2m_2 and we don't know if it is readonly or not, so we don't even know if we are allowed to save it (this is a technical limitation). We could have fix it (for instance, by making an extra fields_view_get at some point). However, it would have implied a lot of unnecessary fields_view_get. Our point for deciding not to fix it is that onchanges should not be used to ensure the business logic. They are meant to show to the user the impact of a change, in live, in the interface. So the specs are as follows: every onchange that the user sees is saved. What he doesn't see isn't saved. So if you open the form view, it will save the fields that are in the form (including o2m_2, with its value from the onchange). If you don't open it, it will only save the values from the list view. Note that actually, it saves all fields that are in the definition of the list view, even those that are invisible, so a workaround would be to add the field o2m_2 to the list, with attrs invisible="1". Regards |
|
I think the workaround can be enough, isn't it, @jbeficent ? |
|
@jbeficent @pedrobaeza Sorry for the late reply. I face the same issue if i don't define the list and form subviews inline in the main form view, but it works fine with inline views. This is a bug. I'll try to fix it this week. Could you confirm that you can make it work using inline views? Regards. |
|
@jbeficent did you try this again? |
|
@aab-odoo today I have experimented with this multi-level onchange, and even adding the
The form is saved without an error, but looking in the content, the records of the Any way, it's a pity also to require the inline view definition, as this kills in a practical way the inheritance possibilities (you have to explicitly add other fields to this inline view that other modules can add to the Can you please check what is happening? |
|
I think we should reopen this and extend it for newer versions. |
|
I just tried the zipped module, had to change the version to
|
|
Yes, there has been some improvements on the ORM side as well and now all should be handled correctly. |
Impacted versions:
8.0, 9.0, 10.0, 11.0, master
Steps to reproduce:
With the following demonstration module:
onchange_multi_level.zip
Current behavior:
There are 3 levels of models:
Assigning both levels through an onchange:
should fill them correctly, and more after the commit 886003a
But instead, you get different incorrect behaviors depending the version:
Expected behavior:
You know, everything working correctly 😉
I think there's some problem with the information passed from server to client or how to interpret it. @rco-odoo @ged-odoo please investigate it as this is a blocking point for advanced modules like OCA/account-closing#50 / OCA/account-closing#51
cc @Tecnativa
The text was updated successfully, but these errors were encountered: