And then when displaying the account.move invoice view, when trying to add a new invoice line, I had this error:
File "/odoo/src/odoo/http.py", line 639, in _handle_exception
return super(JsonRequest, self)._handle_exception(exception)
File "/odoo/src/odoo/http.py", line 315, in _handle_exception
raise exception.with_traceback(None) from new_cause
KeyError: "context.get('default_move_type')"
Using the Chrome network inspector, I could see that in the context default_move_type was not evaled client side as expected anymore, instead it was passed to the server as a string "context.get('default_move_type')" creating this stack trace on the server side.
You can see that some key/value pairs are properly preserved like:
'default_currency_id': currency_id or company_currency_id,
However, the value for 'default_move_type' is screwed:
'default_move_type': "context.get('default_move_type')"
It seems it's related to the fact that the value evals the context.
As such it will be treated as a string on the client side, and not properly evaled as expected.
Expected behavior
In the XML of the view, the context should look like:
context="{'default_move_type': context.get('default_move_type'), 'journal_id': journal_id, ... 'some_key': some_value}"
Context: I was stuck when migrating l10n_br_account to v14 because the invoice_line_ids context in the acocunt module got extra dict keys/values and we were simply replacing the context in l10n_br_account. Then I wanted to do it cleanly using python_dict from base_view_inheritance_extension as suggested in https://github.com/odoo/odoo/pull/26607 but I got stuck with this bug. As for now I will go back to a brutal context replacement, but if somebody has a patch to test for base_view_inheritance_extension I would be glad to test.
Module: base_view_inheritance_extension
Describe the bug
the python_dict extension seems escaping/quoting context dict values when it should not.
To Reproduce
In a module depending on base_view_inheritance_extension, I was loading a view like:
And then when displaying the account.move invoice view, when trying to add a new invoice line, I had this error:
Using the Chrome network inspector, I could see that in the context default_move_type was not evaled client side as expected anymore, instead it was passed to the server as a string "context.get('default_move_type')" creating this stack trace on the server side.
The original context from the account module is:
(https://github.com/odoo/odoo/blob/14.0/addons/account/views/account_move_views.xml#L727)
Further, by overriding account.move fields_view_get, I could print the relevant view part after base_view_inheritance_extension did its job:
Pay attention to the context:
You can see that some key/value pairs are properly preserved like:
'default_currency_id': currency_id or company_currency_id,
However, the value for 'default_move_type' is screwed:
'default_move_type': "context.get('default_move_type')"
It seems it's related to the fact that the value evals the context.As such it will be treated as a string on the client side, and not properly evaled as expected.
Expected behavior In the XML of the view, the context should look like:
context="{'default_move_type': context.get('default_move_type'), 'journal_id': journal_id, ... 'some_key': some_value}"
Additional context I think this is related to this part of the code but I'm not too sure what should be done instead: https://github.com/OCA/server-tools/blob/14.0/base_view_inheritance_extension/models/ir_ui_view.py#L117
Context: I was stuck when migrating l10n_br_account to v14 because the invoice_line_ids context in the acocunt module got extra dict keys/values and we were simply replacing the context in l10n_br_account. Then I wanted to do it cleanly using python_dict from base_view_inheritance_extension as suggested in https://github.com/odoo/odoo/pull/26607 but I got stuck with this bug. As for now I will go back to a brutal context replacement, but if somebody has a patch to test for base_view_inheritance_extension I would be glad to test.
cc @pedrobaeza @Yajo @gdgellatly @hbrunn @sergio-teruel @renatonlima @marcelsavegnago @sebastienbeau @alexis-via @clementmbr @hparfr