Friday, June 6, 2025
10 changes · 18.0
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
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.