Monday, May 26, 2025
9 changes · 17.0
Enhancements to existing features
Manual customer follow-up reminders will no longer select printing by default unless the follow-up step is configured to send a letter. This avoids generating unnecessary PDFs and keeps the reminder wizard aligned with the intended communication method.
Original PR description
Problem --------- Follow-ups can be configured to execute multiple type of follow-ups (email, whatsapp, sms, ...) One of those is to print a letter, but it's not the most used. When you try to execute a follow-up manually, a wizard opens and follows the setup of the to-be-executed level ; so for example if the next level is configured to send a SMS, SMS should be ticket by default. But the "Print" option is always ticked, even if the "Letter" option is not selected in the configuration of the level. This always generates an additional PDF that is often not needed. Objective --------- Do not tick "Print" by default when manually executing a follow-up level, unless "Letter" is ticket in the configuration of the level. Solution --------- Set "Print" default value in the wizard to the "Letter" value of the follow up line instead of leaving it as True (which is the default). task-4574971
Resolved issues and error corrections
This update prevents searches from failing when a user enters a value that can be read as one type of data but not another. It improves reliability for currency-related searches, such as looking up exchange rates, by ignoring incompatible fields instead of showing an error.
Original PR description
Encountered an issue where `_name_search` would crash if a search term couldn’t be converted to all expected field types — specifically when using a string like "1971-01-01" that gets interpreted as a date, but also hits a float field in the comodel. This happened when searching currencies by exchange rates, which involve both a date field (`name`) and a float field (`rate`) in `res.currency.rate`. The original implementation only caught `ValueError` during type conversion, but in my case it was raising a `TypeError` when attempting to convert a `datetime.date` to a float. To fix this, I expanded the exception handling to also catch `TypeError`, ensuring `_name_search` gracefully skips over fields where conversion is invalid. This aligns with the intended behavior described in the original fix — to silently ignore incompatible fields instead of failing. Failing in Distro Build , python version >=3.10 raises a `TypeError` build_error-110207
Miscellaneous changes
When writing a new formula on a tax_tags expression, but also providing the 'engine' key with 'tax_tags' value, this condition https://github.com/odoo/odoo/blob/16.0/addons/account/models/account_report.py#L539 triggered and the return at the end of it caused the tag to be recreated instead of renamed. This case can happen when changing the name of a tag in a data file, then updating the module. We saw it while working on an cleaned version of a localized report for master. Forward-Port-Of:
Original PR description
When writing a new formula on a tax_tags expression, but also providing the 'engine' key with 'tax_tags' value, this condition https://github.com/odoo/odoo/blob/16.0/addons/account/models/account_report.py#L539 triggered and the return at the end of it caused the tag to be recreated instead of renamed. This case can happen when changing the name of a tag in a data file, then updating the module. We saw it while working on an cleaned version of a localized report for master. Forward-Port-Of: odoo/odoo#210811
This fix updates the blog testing setup so it properly verifies the month shown for blog posts. It helps prevent incorrect blog date behavior from passing unnoticed in automated checks.
Original PR description
This PR updates the blog tour configuration to match what the Python test expects. The tour was designed in a way that avoids checking the actual month name, so even if the blog's publish month and the tour's month were different, the test wouldn’t fail. To make sure the test behaves correctly, we needed to update the tour so it fully aligns with the Python test case. Related PR: [#197172](https://github.com/odoo/odoo/pull/197172) task-4546888
This fix prevents the system from flagging nearly identical Date headers as duplicate issues when they are only milliseconds apart. It reduces misleading warnings for valid website or API requests, helping teams focus on real problems.
Original PR description
The code proved unreliable, emitting warnings for genuine controllers because the two headers were milliseconds appart. Made the warning ignore some almost equal headers.
This fixes an error that could appear when creating automation rules using rental pricing filters. Business users can now set up these rules without running into a confusing technical failure.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Go to Automation Rules; 2. create a new automation; 3. set model to `product.pricing`; 4. in one of the filters, check the record(s) that fit in the domain. Issue ----- > EvalError: Can not evaluate python expression: (bool(parent.product_variant_count < 2)) > Error: Name 'parent' is not defined Cause ----- `parent` is not defined because the `product_variant_ids` field in the view does not have a parent field to evaluate. Solution -------- Remove the `parent` checks. opw-4788215
The Swiss payroll module now uses a longer external code for the 13th salary provision, preventing display issues on payslips. This is a small correction that helps payroll documents appear correctly for users handling Swiss salary processing.
Original PR description
…de for payslip display We increase the size of the external CH code to not impact payslip display
When an iframe is removed from the DOM, it is unloaded, which can cause errors in some cases (e.g. fetch/loadJs). This has not been a significant issue for the web client since it is designed with the assumption that users either keep the browser tab open or close it at some point. However, on the website, there are some iframes (e.g. when editing the website) and unloading these iframes appears to cause tracebacks to be logged in the console and a dialog is quickly display to the end user.
Original PR description
When an iframe is removed from the DOM, it is unloaded, which can cause errors in some cases (e.g. fetch/loadJs). This has not been a significant issue for the web client since it is designed with…
When an iframe is removed from the DOM, it is unloaded, which can cause errors in some cases (e.g. fetch/loadJs).
This has not been a significant issue for the web client since it is designed with the assumption that users either keep the browser tab open or close it at some point. However, on the website, there are some iframes (e.g. when editing the website) and unloading these iframes appears to cause tracebacks to be logged in the console and a dialog is quickly display to the end user.
According to the Fetch specification, the user agent may terminate an ongoing fetch if that termination cannot be observed through script. In our case, however, the fetch cannot be terminated because the termination can be observed through the promise and a TypeError is thrown[1].
Here a sample to reproduce the errors with firefox on github:
```js
window.onbeforeunload = () => console.log("beforeunload");
fetch("https://github.com/").then(() => console.log("fetch"));
window.location = "https://github.com/";
```
Should log inside the Firefox console:
```log
beforeunload
Uncaught (in promise) TypeError: NetworkError when attempting to fetch resource.
```
Another errors can occur when we unload a page, if we manipulate the DOM when it's unload a DOMException can be trowed[2], we also handle these case inside this commit.
This commit prevents displaying these errors on dialog inside Odoo.
task-4457865
[1]: https://fetch.spec.whatwg.org/#http-network-fetch
[2]: https://webidl.spec.whatwg.org/#dom-domexception-abort_err
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#210786Fixes were made regarding the fraud prevention headers, but we have still odoo requests that send invalid headers. When checking the odoo requests on the hmrc website, we can group by `Gov-Vendor-Version`, which is currently set to the Installed Version of the base module, twice (for some reasons). This commit send the version of the `l10n_uk_reports` module. So when a new fix is made, we can bump the module version and see if failing requests are up-to-date. task-4627086 Forward
Original PR description
Fixes were made regarding the fraud prevention headers, but we have still odoo requests that send invalid headers. When checking the odoo requests on the hmrc website, we can group by `Gov-Vendor-Version`, which is currently set to the Installed Version of the base module, twice (for some reasons). This commit send the version of the `l10n_uk_reports` module. So when a new fix is made, we can bump the module version and see if failing requests are up-to-date. task-4627086 Forward-Port-Of: odoo/enterprise#84692