Friday, June 6, 2025
18 changes · 18.0
Enhancements to existing features
This change adds a customization point before sales orders are updated from electronic UBL documents. It makes it easier for businesses with custom workflows to adjust order details without duplicating updates or adding extra processing steps.
Original PR description
**Description of the issue/feature this PR addresses:** There's no hook to manipulate order values before write. **Current behavior before PR:** You cannot add custom logic easily w/o writing again on the order **Desired behavior after PR is merged:** Ease custom logic implementation. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
Tasks created from service products now use the product name unless the sales order line description was manually customized. This prevents standard sales descriptions from incorrectly becoming task names, keeping project records clearer for users.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a service product that creates a task on order confirmation; 2. give it a sales description; 3. add it to an order and confirm. Issue ----- The task is named using the sales description. Cause ----- Commits 47d223759f07 & c3877b2acd74 attempted to restore previous task/display name behavior by using the second line of the SOL description as the task/display name. This behavior only happened in previous versions when the line description was manually modified. Solution -------- Only use the new behavior if the line name isn't the same as the default. opw-4634149
Miscellaneous changes
Steps to reproduce ================== - Open the JS unit test page - Enable the "Mid-tier mobile" option in the devtools in order to have a 4X CPU slowdown - Run the test "url should not use the record last updated date when the field is related" => It fails Cause of the issue ================== We check that a timestamp generated after a patchDate is at most 100ms after. When we have a high CPU usage or a slow CPU, it can happen that the value is more than 100ms after. Soluti
Original PR description
Steps to reproduce ================== - Open the JS unit test page - Enable the "Mid-tier mobile" option in the devtools in order to have a 4X CPU slowdown - Run the test "url should not use the record last updated date when the field is related" => It fails Cause of the issue ================== We check that a timestamp generated after a patchDate is at most 100ms after. When we have a high CPU usage or a slow CPU, it can happen that the value is more than 100ms after. Solution ======== The test simply needs to check that the date is either the `2017-02-06` or the `2017-02-09`. We can use the luxon function `a.hasSame(b, "days")` runbot-115469 Forward-Port-Of: odoo/odoo#212608 Forward-Port-Of: odoo/odoo#212515
This change standardizes how tab width values are written in HTML editor tests so they match the way browsers format them. It helps prevent avoidable test failures without changing user-facing editor behavior.
Original PR description
Description of the issue this PR addresses: - Trailing zeros in tab width styles cause test mismatches with browser-normalized values. Current behavior before PR: - Tests may use widths like "24.0px" which differ from browser output "24px". Desired behavior after PR is merged: - Tab widths use Number() conversion to match browser formatting and avoid test mismatches. task-4853029 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Date and date-time columns in list views now get a little extra space when shown in bold. This prevents values from being cut off with ellipses, making records easier to read across languages and systems.
Original PR description
This commit is a followup of [1] where we compute the minimum required width for date and datetime fields in list views. However, it didn't take into account decorations that could be applied to list views, in particular `decoration-bf`, which may, for certain fonts, increase the width of date values. We tested all languages, on different systems (thus different standard fonts), and an increase of 5% of the computed width is enough on those systems to display date and datetimes without an ellipsis, even in bold. [1] odoo/odoo#210584 No task, issue reported on our prod Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Manufacturing users can now clear the End Date on productivity loss records without triggering an error. This prevents an avoidable form crash and keeps work center loss tracking smoother when dates are edited or removed.
Original PR description
If the `End Date` is already defined and the user removes that date in the form view of productivity losses, an error is generated. Steps to reproduce: --- - Install the `mrp` module - Manufacturing > Configuration > Work Centers > Open any of the Work Centers - In the form view of Work Center, click on the `Lost` stat button - Open a new Productivity Loss form, set a future date in `End Date`, click elsewhere, then clear the `End Date` Traceback: --- `TypeError: unsupported operand type(s) for -: 'bool' and 'datetime.timedelta'` If the end date is missing, we will return from the method sentry-6641245276 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A test related to refund orders with delayed shipping costs in Point of Sale was corrected. This helps ensure future updates do not break refund cost calculations, with no direct impact on daily users.
Original PR description
…talcost this commit fixes the test test_pos_order_refund_ship_delay_totalcost from PR https://github.com/odoo/odoo/pull/210868 opw-4614503
This update fixes an internal automated test for point of sale refunds involving shipping delays and total cost calculations. It helps keep quality checks reliable so future changes to the point of sale flow can be validated with greater confidence.
Original PR description
this commit fixes the test test_pos_order_refund_ship_delay_totalcost from PR #210868 opw-4614503
Users outside the Mexican localization who try to use the Mexico global invoicing action now receive a clear explanation instead of a generic validation error. This reduces confusion when the action appears for non-Mexican companies because of shared localization setup.
Original PR description
Currently, there is an button related to the MX localization that can be accessed outside the localization if `l10n_mx` is installed. Steps to reproduce: ------------------- * Install `l10n_mx` * With company other than MX, go to the pos orders * Select multiple pos orders, select the button **Actions** > Observation: The action `Create Global Invoice` is visible * Select the action `Create GLobal Invoice` > Validation error, Selected orders are not eligible for CFDI Why the fix: ------------ This is an `ir.actions.server` which is introduced in the `l10n_mx` localization. It does not look possible to add `invisible` on the xml for the action. https://github.com/odoo/odoo/blob/2540155b5e00a6547fcceee4af4b83f385dcd4ad/odoo/addons/base/models/ir_actions.py#L179-L215 What we can do instead is to throw a more explicit error when trying to use the action outside the MX loca. opw-4805257
This change rolls back a recent US tax reporting update because it caused crashes during deployment. It keeps the stable version working while the underlying dependency issue is addressed in a future release.
Original PR description
This reverts commit 1e8f79bd0a5e53f34cd8dfaea0a4d3e199aca0c7. The deployment of the reverted commit revealed an error: l10n_us_reports does not depend on l10n_us_account (only l10n_us), so it can't override the US tax report in data and crashes. We sadly cannot fix that in stable ; we'll do it in master.
Fixed an issue where messages linked to deleted records without an active discussion thread were not cleaned up correctly. This helps keep related communication data consistent and prevents leftover messages from deleted business records.
Original PR description
https://github.com/odoo/odoo/pull/209644
This fixes unwanted extra spaces in product or service descriptions on Uruguayan electronic invoice documents. It helps keep customer-facing invoice details cleaner and more consistent without changing business workflows.
After this PR - transporter gst number is not required while submitting ewaybill if vehicle number is present and mode of transportation is by road - vehicle number can be left empty if transportation document no is set however transporter gst is required for that case task-4807693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211088
Original PR description
After this PR - transporter gst number is not required while submitting ewaybill if vehicle number is present and mode of transportation is by road - vehicle number can be left empty if transportation document no is set however transporter gst is required for that case task-4807693 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#211088
Problem: When trying to align a separator to the left or right in the email editor using `ms-auto` or `me-auto`, it remains centered instead of aligning as intended. Cause: A global `margin: auto` rule was applied to all `hr` elements, overriding the directional margin utilities (`ms-auto`, `me-auto`), preventing correct alignment. Solution: Restrict `margin: auto` to only apply on `hr` elements that do *not* have `ms-auto` or `me-auto` classes. This preserves default centering while al
Original PR description
Problem: When trying to align a separator to the left or right in the email editor using `ms-auto` or `me-auto`, it remains centered instead of aligning as intended. Cause: A global `margin: auto` rule was applied to all `hr` elements, overriding the directional margin utilities (`ms-auto`, `me-auto`), preventing correct alignment. Solution: Restrict `margin: auto` to only apply on `hr` elements that do *not* have `ms-auto` or `me-auto` classes. This preserves default centering while allowing explicit left or right alignment. Steps to reproduce: - Open Email Marketing and add a "Separator" to an email. - Try to align the separator to the left or right. → The separator remains centered instead of aligning properly. opw-4805194 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#212496
When trying to send a vendor bill that uses a tax with l10n_es_type 'sujeto_agricultura' with TicketBAI using the agency bizkaia, we are faced with an error code. This is due to the amount of these taxes being different than what is allowed (10.5% and 12%). The two 'sujeto_agricultura' taxes are actually part of a special regime and should be exempted when sent [reference](https://sede.agenciatributaria.gob.es/Sede/iva/regimenes-tributacion-iva/regimen-especial-agricultura-ganaderia-pesca.htm
Original PR description
When trying to send a vendor bill that uses a tax with l10n_es_type 'sujeto_agricultura' with TicketBAI using the agency bizkaia, we are faced with an error code. This is due to the amount of these taxes being different than what is allowed (10.5% and 12%). The two 'sujeto_agricultura' taxes are actually part of a special regime and should be exempted when sent [reference](https://sede.agenciatributaria.gob.es/Sede/iva/regimenes-tributacion-iva/regimen-especial-agricultura-ganaderia-pesca.html) This PR adapts the data sent to Bizkaia, in a similar manner as https://github.com/odoo/odoo/pull/196017 did for SII, by setting `ClaveRegimenIvaOpTrascendencia` to `02` and `TipoFactura` to `06` if we have a 'sujeto_agricultura' tax. [reference](https://sede.agenciatributaria.gob.es/static_files/Sede/Procedimiento_ayuda/G417/FicherosSuministros/V_1_1/Validaciones_ErroresSII_v1.1.pdf) opw-4781267 Forward-Port-Of: odoo/odoo#211065 Forward-Port-Of: odoo/odoo#210141
Fixed onboarding document tours which was not working properly. Task-4210376 Forward-Port-Of: odoo/enterprise#72639 Forward-Port-Of: odoo/enterprise#70900
Original PR description
Fixed onboarding document tours which was not working properly. Task-4210376 Forward-Port-Of: odoo/enterprise#72639 Forward-Port-Of: odoo/enterprise#70900
Before this commit:- - In GST Return Return Period 'Push to GSTN' button triggers a cron to send GSTR-1 data, but on UI there is no information about whether the cron is running in backend or not? After this commit:- - Raise ValidationError if that required cron is disabled. - Show acknowledgement notification(ir.actions.client) after the cron is triggered. task-4653538 Forward-Port-Of: odoo/enterprise#84125
Original PR description
Before this commit:- - In GST Return Return Period 'Push to GSTN' button triggers a cron to send GSTR-1 data, but on UI there is no information about whether the cron is running in backend or not? After this commit:- - Raise ValidationError if that required cron is disabled. - Show acknowledgement notification(ir.actions.client) after the cron is triggered. task-4653538 Forward-Port-Of: odoo/enterprise#84125
Currently, if there is an error while generation print reports the use of the IoT will return the generic error `Failed to send to printer' which does not lead to understand there is a hidden issue to begin with. Steps to reproduce: ------------------- 1. Set up the iot and like the product labels report to a zebra printer 2. Modify the view of the product labels (`label_product_product_view`) to ensure there is an error during rendering (mistype a field name) 3. Go to a product and print
Original PR description
Currently, if there is an error while generation print reports the use of the IoT will return the generic error `Failed to send to printer' which does not lead to understand there is a hidden issue…
Currently, if there is an error while generation print reports the use of the IoT will return the generic error `Failed to send to printer' which does not lead to understand there is a hidden issue to begin with. Steps to reproduce: ------------------- 1. Set up the iot and like the product labels report to a zebra printer 2. Modify the view of the product labels (`label_product_product_view`) to ensure there is an error during rendering (mistype a field name) 3. Go to a product and print labels > Observation: Notification: Failed to send to printer Why the fix: ------------ In the example given an error occurs when trying to render the label here: https://github.com/odoo/enterprise/blob/968bf16c65a67791efd5fb94f5c95eaf09a47107/iot/static/src/iot_report_action.js#L50-L57 Technically the error makes it so that we fall into this catch block https://github.com/odoo/enterprise/blob/968bf16c65a67791efd5fb94f5c95eaf09a47107/iot/static/src/iot_report_action.js#L81-L88 We will now make a distinction between the RPC error and generic iot related error. If any error occur while making the RPC call we will now show the traceback. This should help anyone debugging. opw-4571350 Forward-Port-Of: odoo/enterprise#84589