Friday, November 14, 2025
40 changes · saas-18.4
Resolved issues and error corrections
This update corrects how shipping data is rounded before being sent to DHL. It prevents validation failures caused by tiny floating-point precision differences, so shipments with prices or weights like 11.43 or 0.3 are accepted reliably.
Original PR description
Multiple rounding issues could cause DHL validation errors. Example with product price: - Create a storable product - Create a quotation with quantity 7, price 11.43 - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 11.429999999999998 not multiple of 0.001 Example with product weight: - Create 3 products, each 0.1 kg - Create a SO with these products - Validate the SO - Go to delivery, use DHL carrier, validate - DHL traceback: 0.30000000000000004 not multiple of 0.001 See official DHL API documentation: https://developer.dhl.com/api-reference/dhl-express-mydhl-api and check the POST /shipments data schema opw-5000193 Forward-Port-Of: odoo/enterprise#98913 Forward-Port-Of: odoo/enterprise#96012
This update ensures the first line of a bank statement is always identified correctly, even when certain values are set during creation or later updated. This prevents incorrect bank journal balances from appearing, improving the reliability of account balances.
Original PR description
Ensure proper computation of first_line_index when line.internal_index or line.state changes. Previously, the computation of first_line_index was grouped with the date computation. However, due to a specific ORM behavior, the compute method is not triggered when one of the computed fields (in this case, the date) is provided in the create values. As a result, first_line_index could remain falsy, leading to an incorrect balance in the bank journal. no task id --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235561
This change fixes a crash that could happen when checking which message was last seen by everyone in a discussion. It now uses a more reliable way to identify the current user’s member record, which prevents the error and makes the calculation more robust.
Original PR description
The `lastMessageSeenByAllId` compute function sometimes crashes when the persona linked to a member is unknown. This occurs because the compute function compares the member's persona to determine if it belongs to the current user. However, members are not always sent along with their persona. The compute function should instead compare the member directly to the current user's member. This fixes the issue and makes more sense. 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 Forward-Port-Of: odoo/odoo#235338 Forward-Port-Of: odoo/odoo#235253
This change ensures the system always sends the expected reconnecting and reconnect events when a websocket connection is lost unexpectedly, even if the closing handshake was incomplete. It improves the consistency of connection status updates and helps avoid intermittent failures in automated tests and live sessions.
Original PR description
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it…
The websocket worker broadcasts events that track connection state changes (connect, disconnect, reconnecting, reconnect). Sometimes a WebSocket can close without the client noticing, leaving it stuck in the `CLOSING` state. If the client starts the worker during this period, the worker detects the issue and triggers a disconnect event, but neither reconnecting nor reconnect is emitted. Conceptually, reconnecting/reconnect should fire on any unexpected loss of connection. This patch ensures those events are properly triggered in this case. This also fixes a runbot error ([1]) where a test simulates the loss of the connection. The test sometimes runs before another service's call to `bus_service.start`, reproducing this exact scenario. [1]: https://runbot.odoo.com/odoo/runbot.build.error/223185 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 Forward-Port-Of: odoo/odoo#235319
This update removes the requirement to enter share capital for Italian companies that are not limited liability companies. It prevents unnecessary validation issues when setting up or updating company details, making the registration process smoother.
Original PR description
Share capital should not be mandatory for non limited liability company. [Ticket link](https://www.odoo.com/odoo/project.task/5131029) opw-5131029 Forward-Port-Of: odoo/odoo#235498
This fix allows users to generate a debit note from an existing credit note in the Argentine localization. Before this change, the process failed with an error, which made it harder to correct invoicing mistakes after a credit note had been issued.
Original PR description
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of…
Co-authored-by: Katherine Zaoral <zaoral@users.noreply.github.com> THE FIX COMES FROM: 37faec2f38c9658a0f491c72f284908dc929fa17 ORIGINAL PR: https://github.com/odoo/odoo/pull/205430 Description of the issue/feature this PR addresses: - In debit notes wizards: If we make a wrong credit note and we want to correct it we must generate a debit note related to it. Currently odoo only allows to generate debit notes from an invoice. Steps to reproduce the error. - Install the Argentine localization - Create an invoice and post it - From the invoice using the wizard create a credit note and post it. From the credit note open the wizard to create a debit note. On submit the wizard we obtain an exception "You can not use a credit_note document type with a invoice" This happens because the debit note wizard use copy method without change the l10n_latam_document_type_id value. Current behavior before PR: When creating a debit note from a credit note get an error. Desired behavior after PR is merged: We can create a debit memo from a credit note. opw-4304256 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 Forward-Port-Of: odoo/odoo#233875 Forward-Port-Of: odoo/odoo#225501
This fix ensures submenu items in the hamburger menu automatically use the same font size as the header. As a result, when the header style is changed, the menu labels stay visually consistent and update correctly.
Original PR description
Steps to reproduce: =================== - Create a menu and a submenu - Change the header template to the hamburger menu - Update the navbar format ->The format of the submenu's parent is not updated. Cause: ====== The menu in the hamburger layout uses the `.accordion-button` class, which applies a fixed base font size defined here: https://github.com/odoo/odoo/blob/ebb250d3b56970c09ffb5ebefef38f97c622c33d/addons/web/static/lib/bootstrap/scss/_accordion.scss#L37 This prevents the submenu text from inheriting the updated header font-size. Solution: ========= Allow the `.accordion-button` font size to inherit from its parent. This ensures that submenu text correctly follows the header's font-size setting. opw-5223664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234276
This change fixes an issue where creating multiple journals of the same type could trigger a duplicate alias error. Odoo now checks all relevant aliases, even when no alias domain is configured, so journal creation works consistently.
Original PR description
**Issue** When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the…
**Issue** When creating two new journals and selecting the *type* before the *name*, Odoo generates an alias using the type (e.g. `sale--...`). When saving a second journal with the same type, the alias conflicts and raises a "This alias already exists" error. **Steps to Reproduce** 1. Navigate to Accounting > Configuration > Journals. 2. Create a new journal. 3. Set the Type to Sales before entering the Name. 4. Save the journal. 5. Repeat the process to create another journal of the same type. 6. Observe that an error occurs: alias name is already used. **Root Cause** The uniqueness check in _ensure_unique_alias only compares alias_name against existing aliases with the same alias_domain. However, many aliases are created with alias_domain = False. Since those were excluded from the domain, the check failed to detect duplicates correctly. **Fix** Update the domain in _ensure_unique_alias to also include aliases where alias_domain is unset. This ensures that aliases are always unique regardless of whether a domain is configured. Opw-5028713 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#233101 Forward-Port-Of: odoo/odoo#225537
The self-order IoT component now correctly reads newer image version numbers that use a full date format. This prevents version checks from failing and helps keep the device software update flow working smoothly.
Original PR description
New image versions are formatted as YYYY.MM.DD instead of YY.MM. The previous can be casted to float, but not the new one. We then only take the year and month to before casting. Forward-Port-Of: odoo/enterprise#99416
This update corrects how scheduling intervals are combined so they are consistently normalized before use. It prevents mismatches and errors when different interval types are merged, improving the reliability of planning-related operations.
Original PR description
Note: >The `WorkIntervals` class has been removed, and the `keep_distinct` flag has been introduced in `18.4` to simplify its logic. For the following explanation, we will refer to an `Intervals`…
Note: >The `WorkIntervals` class has been removed, and the `keep_distinct` flag has been introduced in `18.4` to simplify its logic. For the following explanation, we will refer to an `Intervals` class with `keep_distinct = False` as 'Intervals', and to one with `keep_distinct = True` as 'WorkIntervals'. ## The issue Prior to this commit, the `other` parameter in the `_merge` method could belong to a different class, not necessarily an instance of `Intervals`. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L158-L165 The comment indicates that normalization should be enforced; however, there is no corresponding reference to it within the `_boundaries` method. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L48-L53 That normalization just happens in the `__init__`. https://github.com/odoo/odoo/blob/8c737601327acec1d83e1e5e3c6e66c9fd226339/addons/resource/models/utils.py#L117-L132 ## Example For example, in Planning module, we perform operations between `Intervals` and `WorkIntervals`. The `WorkIntervals` class behaves differently from `Intervals`: while `Intervals` uses disjoint closed intervals, `WorkIntervals` uses disjoint semi-closed intervals. ## Side effects During these operations, the `_merge` method was not normalizing the `_items`, which caused inconsistencies and errors (when we are merging two unormalized intervals `([0, 10], [10, 20])` with an empty `others`). ## The fix This commit ensures that the `other` parameter is normalized before processing the `_merge` operation. The fix ensures that normalized intervals are always produced after `_merge`, even when unnormalized intervals are provided as input. ## Real case That issue has been found in that ticket: 5184291 Forward-Port-Of: odoo/odoo#235133 Forward-Port-Of: odoo/odoo#234352
This fix restores employee selection for users who do not have full Employees access, especially in mobile and Studio-created fields. It ensures public employee information can be read correctly so search results appear instead of showing no records.
Original PR description
**Steps to reproduce** - With Studio, create a many2one field in relation to the Employee model. - Have a user with no "Employees" rights. - With this user and in mobile view, click on the field to…
**Steps to reproduce** - With Studio, create a many2one field in relation to the Employee model. - Have a user with no "Employees" rights. - With this user and in mobile view, click on the field to select an employee. -> No records found. Note: the many2one_avatar_employee widget used in HR apps avoid this problem. **Cause** Issue since https://github.com/odoo/odoo/commit/e962860c6f0d8ec9e50bb376e1faab5c7bc69374 The `web_search_read` on the private employee model returns no records when an `image_*` or `avatar_*` field is part of the requested fields. This is because we try to fetch these fields https://github.com/odoo/odoo/blob/188a3fe45fb41463ff86d1fa5e930ab43fb70d0e/addons/hr/models/hr_employee.py#L240 but they are not stored on the public employee model, and will not be put in cache. When performing a read after that, these fields are missing from cache. We try to fetch them from the db https://github.com/odoo/odoo/blob/e962860c6f0d8ec9e50bb376e1faab5c7bc69374/odoo/models.py#L3185 but this fetch is again done using the public employee. This results in missing values and is interpreted as an access error, no data is returned in `web_search_read`. **Solution** Read the problematic fields to make them present in cache when the cache of the public employee is copied to the one of the private employee. opw-4297115 Forward-Port-Of: odoo/odoo#234456 Forward-Port-Of: odoo/odoo#197575
When a shape is already applied to a background or image, it is now clearly highlighted in the selector. This makes it easier for users to see the current choice, while also improving keyboard navigation and closing behavior for a smoother editing experience.
Original PR description
Before this commit, when a shape was applied to a background or an image, that shape was not highlighted in the shape selector. After this commit, active shapes are highlighted with a border in the shape selector. task-5187272
This change restores rounding calculations to the correct place in accounting scenarios and updates incorrect comments in the tests. It helps ensure invoices, refunds, and reconciliation behave consistently and are validated more accurately.
Original PR description
Also fixes the comments that were wrong. Change some values to better test things 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 Forward-Port-Of: odoo/odoo#235392 Forward-Port-Of: odoo/odoo#234213
The website now updates the displayed price without national taxes when a quantity-based fixed pricelist price applies. This ensures Argentinian customers see the correct price as they change quantities on product pages.
Original PR description
Versions -------- - saas-18.4+ Steps ----- 1. Have a company with Argentinian localization; 2. in Website settings, enable "Display Price without National Taxes"; 3. add a quantity-based fixed price on the website's pricelist; 4. go to a product page where the fixed price can be applied; 5. increase quantity so the fixed price should apply. Issue ----- The price without national taxes isn't getting updated. Cause ----- In the `_get_additional_combination_info` override, the given `quantity` gets ignored, as well as the pricelist price for product variants, instead defaulting to their `lst_price`. Solution -------- Pass the quantity to `_compute_price_rule`, and use the result for both templates & variants. opw-5040056
The Wave document layout now keeps multi-line footers from overlapping invoice content when viewed in the portal on mobile devices. This improves readability and prevents important information from being hidden in customer-facing previews.
Original PR description
In the Wave layout, a multi-line footer overlaps document information when the portal view is opened from a mobile interface. Steps to reproduce: - Open Settings > General settings > Configure Document Layout - Select Wave layout and add a multi-line footer - Open an invoice, go to portal preview, switch to mobile view Issue: The footer overlaps invoice information. This occurs because the boundaries of the SVG drawing are not well defined and it will unexpectedly shrink. opw-5023032 Forward-Port-Of: odoo/odoo#230230
This change makes the web editor test suite more reliable by giving each test its own time allowance instead of sharing one timer across all of them. It matters because slower test environments were causing occasional false failures, even though the product itself was working correctly.
Original PR description
Split the test timer between the four tests rather than applying
a single timer over all of them, for when the runbot is slower.
runbot-233975
Forward-Port-Of: odoo/odoo#235313This fix prevents a page error when an empty row is edited in the website builder. It adds a safety check so the system no longer tries to inspect columns that do not exist, improving stability for users working with empty layout blocks.
Original PR description
When a .row div was empty, the _areColsCustomized function was called with an empty HTMLCollection. This caused a traceback when the function tried to access columnEls[0]. This commit adds a safety check to _getNbColumns for avoiding extra calls to _areColsCustomized when columnEls is empty. And we also add a similar check to _areColsCustomized for safety, since it's also being called through the _computeWidgetVisibility. opw-5121738 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235555
Saudi invoices could lose their taxes when a customer was assigned a Saudi fiscal position. This update corrects the tax setup so the expected tax remains visible and applied on invoice lines.
Original PR description
Steps to reproduce: - With a SA company setup - Create an invoice - Set a Saudi Arabia partner - Add a product with 15% tax defined on it Issue: No tax shows up on the invoice line Analysis: This occurs because the default fiscal positions are all empty and empty fiscal positions remove all taxes. opw-5166882 Forward-Port-Of: odoo/odoo#234387
Warnings attached to products will only appear on sales, purchase, and stock documents when the warning feature is enabled in settings. This fixes the issue where old warnings could still show up even after the feature was turned off, reducing confusion for users.
Original PR description
Step to reproduce:
- install purchase
- go to setting -> (enable) warning
- create a new products and add purchase warning
- now disable the warning from setting
- create a PO with that product
Observation:
- warning is visible, even though we disabled the setting
Cause:
- After commit [1] , once a warning is set on a product, it is displayed on
document regardless of the warning setting.
[1]:https://github.com/odoo/odoo/commit/1e13520ca9bb18deba85110ce9362ac2adb55904
Fix:
- Fix the computes of warning message to run only,
when the warning setting is enabled
opw-5156107
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#231393This update fixes a configuration access issue in the bank transfer setup so the system can correctly read needed settings. It helps avoid errors when users prepare or send payments using ISO 20022 formats.
Original PR description
Forward-Port-Of: odoo/enterprise#99359
The receipt will now display the cashier/server name even when a preset like Eat In is used. This ensures customers and staff can always see who handled the order, making receipts more consistent and easier to review.
Original PR description
Currently cashier name is only shown if no preset is shown or if the present identification is set on name. Steps tot reproduce: -------------------- * Open restaurant * Make sure you use the Eat in preset * Place an order and pay it > Observation: On the receipt the "Served by:" indication is not shown. Why the fix: ------------ The cashier/server information should not depend on the preset used. opw-5154347 Forward-Port-Of: odoo/odoo#234767 Forward-Port-Of: odoo/odoo#231930
This update makes guided tours skip warning steps properly when moving backward. It prevents the interface from briefly jumping to a step that should not be shown, making tour navigation more reliable and less confusing for users.
Original PR description
Before this commit, the backward wasn't ignoring the warn steps. So, if the backward go to the previous step (warn's one) and the trigger is on the page, the tour interactive put the cursor there. But the step is then ignored and go back the step you came from. Now, the warn's steps are ignored. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235511
This update improves how fixed taxes are represented in electronic invoices, especially when some taxes must be excluded from the original line and shown separately. It also corrects rounding and grouping behavior so invoice totals and tax breakdowns are more accurate and consistent.
Original PR description
This commit contains 2 things: - an helper to extract any tax_data and move it to another base_line - the usage of this helper in UBL to turn emptying taxes into additional base_lines == Add helpers…
This commit contains 2 things: - an helper to extract any tax_data and move it to another base_line - the usage of this helper in UBL to turn emptying taxes into additional base_lines == Add helpers to turn tax_data into new base_lines easily == With this helper, you can now exclude any tax from any base line and turn them into new base lines. Also, I changed a bit the smooth distribution of rounding because the math.ceil is sometimes too greedy and make the whole results to be less accurate. == Make a different behavior between recycling contribution taxes / emptying taxes == In UBL, all fixed taxes are treated as allowances/charges. In this commit, we make a clear distinction between recycling contribution taxes that are treated as allowances/charges and emptying taxes that are exempted of tax and are treated as addition invoice lines in the document. == Fix a small issue with aggregate_function passed to reduce_base_lines_with_grouping_function == The aggregator wasn't called when setting the 'target_base_line' at the very first time. task_id: 5182783 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#234489
This update fixes an issue that could prevent pending transactions from displaying correctly in bank reconciliation screens. It also corrects how journal totals are retrieved, so the amounts shown to users are computed properly instead of being left unresolved.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/1691a9d6ec426566b81537544cafe09d9c62ad78 We added a template to inherit BankRecKanbanRenderer, but we forgot to add the extension. By doing that it broke the pending transaction template override. Also this: https://github.com/odoo/enterprise/commit/5d5a7aca4f0abb4492314324631e8b5463a35332 change the getJournalTotalAmount to use a super instead, but it was missing an await otherwise we just have a promise no task id Forward-Port-Of: odoo/enterprise#99066
This fix allows vendor bills and invoices with deferred amounts to be reset to draft multiple times, even when audit trail rules are involved. It removes a blocker that could prevent users from correcting and reprocessing these documents after a previous reset.
Original PR description
Resetting a vendor bill or invoice with deferred amounts will unlink or reset all existing deferred entries. If the audit trail is enabled, some of these entries must be cancelled instead. [AccountMove.button_draft()](https://github.com/odoo/enterprise/blob/a3f461040cb3443fbcb190c28fddae7044bbd1e7/account_accountant/models/account_move.py#L80-L88) If a protected entry is already cancelled, `AccountMove._unlink_or_reverse()` will still attempt to cancel it. This prevents entries from being Reset to Draft more than once. The current commit removes this restriction. opw-5187737 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235223