Thursday, February 17, 2022
8 changes
New functionality added to Odoo
This change adds a dedicated test module to make sure rental product configuration flows work reliably with the needed sales dependency. It also expands automated checks around configurator behavior, reducing the risk of future issues in rental and sales setup screens.
Original PR description
Before this commit, some tours from `sale_product_configurator` and `sale_product_matrix` were not working since there wasn't a dependency with `sale_management`. They are now in a test module with all the other configurators and the missing dependency. Additionally, other tests are added to improve the coverage of the configurators' logic. task-2049081 See also: - https://github.com/odoo/odoo/pull/82108
Resolved issues and error corrections
A barcode-related automated test was adjusted to avoid occasional false failures caused by timing conflicts. This helps keep the validation pipeline stable without changing how users interact with the barcode app.
Original PR description
The JS tour test `test_gs1_and_packaging` can fail because of a concurrency error. This commit makes the trigger more specific to avoid that issue. Fixes runbot build error id 3303.
Miscellaneous changes
[[FIX] l10n_lu_reports: Profit & Loss: don't ignore moves with fiscal positions when exporting ECDF] The Luxembourg Profit & Loss report's ECDF XML export calls account.coa.report. For this, it forges new options for it. However, due to the fact _get_options() wasn't called, some option keys stayed uninitialized. This was wrong, and led to an unexpected behavior: since the usually mandatory 'fiscal_position' key wasn't provided in the options, get_options_domain (more precisely _get_options_f
Original PR description
[[FIX] l10n_lu_reports: Profit & Loss: don't ignore moves with fiscal positions when exporting ECDF] The Luxembourg Profit & Loss report's ECDF XML export calls account.coa.report. For this, it…
[[FIX] l10n_lu_reports: Profit & Loss: don't ignore moves with fiscal positions when exporting ECDF]
The Luxembourg Profit & Loss report's ECDF XML export calls account.coa.report. For this, it forges new options for it. However, due to the fact _get_options() wasn't called, some option keys stayed uninitialized. This was wrong, and led to an unexpected behavior: since the usually mandatory 'fiscal_position' key wasn't provided in the options, get_options_domain (more precisely _get_options_fiscal_position_domain) entered an unwanted condition and returned [('move_id.fiscal_position_id', '=', False)], which then caused the Luxembourg XML file to ignore every move with a fiscal position set.
[IMP] account_reports: make get_options_domain more robust when fiscal_position option is missing]
Before, when 'fiscal_position' option wasn't set in the options dictionary, we entered the else and added [('move_id.fiscal_position_id', '=', False)] to the domain, which was wrong. Though this case doesn't happen when properly initializing options with a call to _get_options(), we had a case in Luxembourg where it wasn't done. Making this change makes the code more robust against any future misuse of this nature.
OPW 2751338
Forward-Port-Of: odoo/enterprise#24416This update fixes a template issue in the Documents Spreadsheet Bundle that could affect spreadsheet autofill behavior after a framework upgrade. It helps keep spreadsheet-related document features working reliably without changing business workflows.
Original PR description
Since owl 2 (aa95e275eec157d999e8a6eecdaefb90f54d4fa8), t-key is required in a t-foreach tag. task-id 2766634
Currently, if a company has "-" in their company address, the get_xml() crashes when exporting the report, because of the encoding. Report export shouldn't crash, special characters should be ignored. Task: 2760141 Forward-Port-Of: odoo/enterprise#24277
Original PR description
Currently, if a company has "-" in their company address, the get_xml() crashes when exporting the report, because of the encoding. Report export shouldn't crash, special characters should be ignored. Task: 2760141 Forward-Port-Of: odoo/enterprise#24277
Steps : Install Field Service and Contacts. Create a FSM task > Customer : Demo. Note that the displayed address is his Demo's current one. Click Navigate To : it points this same address. Go to Contacts > Demo > change the address and return to task. Note that the displayed address is his Demo's new one. (Or else refresh) Issue : Click Navigate To : it points the OLD address. Cause : action_fsm_navigate calls partner.geo_localize only if partner has no geocoordinates. Yet he sti
Original PR description
Steps : Install Field Service and Contacts. Create a FSM task > Customer : Demo. Note that the displayed address is his Demo's current one. Click Navigate To : it points this same address. Go to Contacts > Demo > change the address and return to task. Note that the displayed address is his Demo's new one. (Or else refresh) Issue : Click Navigate To : it points the OLD address. Cause : action_fsm_navigate calls partner.geo_localize only if partner has no geocoordinates. Yet he still have the old coordinates. Fix : Call when the address changes and not in action_fsm_navigate. opw: 2743926 Related PR: https://github.com/odoo/odoo/pull/84266 Forward-Port-Of: odoo/enterprise#24198
If you execute the scheduled action "1. Cron Job - Run SII Sales Book Report Process", this will result in a traceback because we call `decode` on a `Markup` object which doesn't have that method. This is due to a change in `ir_qweb.py`'s `_render` implementation which now returns a `Markup` object instead of a `bytes` one: https://github.com/odoo/odoo/pull/68299 . It looks like daily sales book was missed during the corresponding refactoring. Forward-Port-Of: odoo/enterprise#24421
Original PR description
If you execute the scheduled action "1. Cron Job - Run SII Sales Book Report Process", this will result in a traceback because we call `decode` on a `Markup` object which doesn't have that method. This is due to a change in `ir_qweb.py`'s `_render` implementation which now returns a `Markup` object instead of a `bytes` one: https://github.com/odoo/odoo/pull/68299 . It looks like daily sales book was missed during the corresponding refactoring. Forward-Port-Of: odoo/enterprise#24421
On inter-company transactions the SO created in Company B when the PO was confimed in Company A you want to see the message "Automatically generated from P12345 of Company A". Currently you see the message like "... from P12345 of Company B" when opening the SO in Company B. Forward-Port-Of: odoo/enterprise#24431 Forward-Port-Of: odoo/enterprise#24123
Original PR description
On inter-company transactions the SO created in Company B when the PO was confimed in Company A you want to see the message "Automatically generated from P12345 of Company A". Currently you see the message like "... from P12345 of Company B" when opening the SO in Company B. Forward-Port-Of: odoo/enterprise#24431 Forward-Port-Of: odoo/enterprise#24123