Thursday, August 20, 2026
40 changes · 19.0
Enhancements to existing features
SMS error messages now include the related record type and ID, making it easier to identify which business record caused the issue. This helps support teams trace the affected recipient faster and resolve messaging problems with less investigation.
Original PR description
- Error now includes the model and ID of the record triggering the SMS, allowing the recipient to be traced opw-6023401
This change enables an additional quality check for the web document test suite. It helps catch issues earlier during development, reducing the risk of preventable problems reaching users.
Original PR description
Task-5180137
This change gives automated web test checks more time to wait for expected page updates, matching other existing waits. It reduces false test failures on busy machines without slowing successful test runs, helping teams get more dependable build results.
Original PR description
Before this commit, waitFor, waitForNone and waitUntil gave the DOM 200 milliseconds, which the loop turns into 12 animation frames, while contains() and expect.waitForSteps sitting in the same tests…
Before this commit, waitFor, waitForNone and waitUntil gave the DOM 200 milliseconds, which the loop turns into 12 animation frames, while contains() and expect.waitForSteps sitting in the same tests give 10 seconds. 430 call sites in addons reach these three helpers and 29 pass an explicit timeout, so 12 frames is what the other 401 get. The problem is that 12 frames is less than what the client needs on a loaded machine. Measured on "should remove file from html editor if removed from attachment list", on the wait that follows the Full composer button: - 5 to 7 frames on an idle machine; - 11 to 18 frames over 8 runs with the machine at load 10 to 20, 5 of the 8 above the 12 frames the default allows. Those 5 are failing runs, and the same test at load 13 to 29 fails 6 runs out of 6 with the 200 milliseconds, 0 out of 6 with 10 seconds. Note that a longer timeout costs nothing on a green build: the wait ends on the frame the DOM matches, so it only delays the report of a test that was going to fail anyway. Hoot fails the test itself after 5 seconds, 15 in test_js.py, which keeps bounding a wait that never resolves. This commit raises the default to 10 seconds, the delay a tour step already gets in macro.js and the one contains() and expect.waitForSteps already have. https://runbot.odoo.com/odoo/error/946094 Forward-Port-Of: odoo/odoo#282702
The Dutch payroll localization now includes the 2026 resident income tax rate values. This helps payroll calculations stay aligned with upcoming tax rules for employees residing in the Netherlands.
Original PR description
Added 2026 values for the residents' income tax rates rule parameter. task-6462877 Forward-Port-Of: odoo/enterprise#127556
Resolved issues and error corrections
This fix restores color styling for labels that appear outside the standard color list component, such as resource indicators in Planning configuration. It keeps the intended colors consistent across regular and dark-mode styling, improving visual clarity without changing workflows.
Original PR description
The `o_colorlist_item_color_*` classes were scoped to `.o_colorlist > button` by 1aa9b957afdd , but they are also used standalone outside any colorlist, e.g. in Planning's `many2one_avatar_resource` field. `web_enterprise`'s dark-mode counterpart also defines them unscoped, so the two stylesheets disagreed. Move the color rules back to the root scope. The colors themselves and the `color-contrast()` text color introduced by the refactoring are kept. Steps to reproduce: - Go to "Planning" - Open "Configuration" => the resources in the "Resources" column. 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
The point of sale product display now avoids showing a confusing placeholder when no product code exists. This keeps receipts or product labels cleaner and prevents staff or customers from seeing incorrect code text.
Original PR description
As we built the defaultCode to contain the `[]` by default, it is never actually false, and `t-if` in template will still display it as `[false]`. This commit fixes it by adding `[]` in the template.
The mail composer flow now waits for the mention suggestion list to close before simulating a file drop. This prevents intermittent failures in automated checks, helping keep the messaging experience stable for users.
Original PR description
Before this commit, the full composer tour can fail on the step that drops a file on the composer, waiting for a `.o-Dropzone` that never shows. This happens because the channel mention list is sometimes still open when the tour drags the file in. The composer gets no dropzone then, as a dropzone only shows when the UI active element contains its target, and the open mention list is the UI active element. The dropzone is only updated on the drag events, therefore closing the mention list never brings it back. Note that the same race is reported on saas-19.1, where the tour crashes on `dispatchEvent` of null instead, as the `dragFiles` helper there queries the dropzone once where `dropFiles` waits for it. This commit waits for the mention list to close before the drag. https://runbot.odoo.com/odoo/error/946097 Forward-Port-Of: odoo/odoo#282716
Fixed a bug in the Mail chatter where reopening a note composer and pressing Escape or arrow keys in the continuation popup could cause an error. The popup now safely ignores those keys, allowing users to continue their work without interruption.
Original PR description
Reproduction steps: - Open a record that has a chatter where you can log notes - Start logging a note in the composer - Close the composer - Click log note again - See "Continue with Full Composer?" popup - Hit escape, up, or down - See traceback This shouldnt really do anything, so this fix makes it do nothing instead of crashing. opw-6476660
The Attendance location warning dialog now closes properly when users choose Discard after browser location access is blocked. This prevents employees from getting stuck on a confirmation pop-up while checking in or out from the backend systray.
Original PR description
Steps to reproduce: -------------------------------------------- 1. Install Attendance module. 2. Enable `Device & Location Tracking` & `Attendance from Backend` in settings. 3. Block location access…
Steps to reproduce: -------------------------------------------- 1. Install Attendance module. 2. Enable `Device & Location Tracking` & `Attendance from Backend` in settings. 3. Block location access from the browser for this site (Site settings) 4. Try to checkIn/checkOut from the Dot in the systray 5. We'll have one confirmation pop-up asking to Proceed Anyway OR Discard Observation: -------------------------------------------- On clicking the discard button, Nothing happens. Issue: -------------------------------------------- In `confirmChecking()`, the `cancel` callback was defined as an arrow function using an expression body. In JavaScript, an assignment expression returns the assigned value. Since `this._attendanceInProgress` is set to `false`, the callback implicitly returns `false`. `ConfirmationDialog.execButton()` treats a `false` return value as a signal to keep the dialog open (used intentionally to block closing on validation failure) This caused the dialog to never call `this.props.close()`, leaving it permanently open when Discard was clicked. https://github.com/odoo/odoo/blob/5e84fdd99e34836a15cadc4fdf4b6bc449727e58/addons/web/static/src/core/confirmation_dialog/confirmation_dialog.js#L75-L89 Solution: -------------------------------------------- Change the `cancel` callback from an expression body to a block body, A block body arrow function returns `undefined` by default. This ensures `execButton` does not interpret the return value as a 'keep dialog open' signal, and correctly calls `this.props.close()` to dismiss the dialog. opw-6462439
When a cashier closes the product configurator without adding the main product, optional add-on products are no longer shown. This avoids confusion and prevents staff from adding extras for a product that was not actually selected.
Original PR description
When discarding the product configurator, we still showed the optional product. We no longer do that as no one wants to add optional products to a not-added product. task-6442422
Odoo now safely ignores default search filters that point to records that no longer exist. This prevents users from encountering crashes when opening affected screens and keeps search behavior stable.
Original PR description
…'t exist Have a search view with a m2o field Have an action that sets search_default_m2o: [/BAD ID/] Before this commit there was a crash After this commit, we simply ignore the filter. task-6469841 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
The Discuss message search now ignores extra blank spaces in search terms before highlighting results. This prevents a crash when users type a word followed by many spaces, keeping conversations searchable and stable.
Original PR description
**Steps to reproduce:**
- Go to Discuss app
- Open a conversation
- Click on the Search Messages button
- Enter a word, then a lot of spaces
- `RangeError: Maximum call stack size exceeded`
**Issue:**
During highlighting, if the search term contains multiple spaces, `searchTerm.split(" ")` produces empty terms `""`. Then the empty regex will match on every character, creating a lot of highlight `<span>` elements and eventually causing the error on `element.replaceChildren(...newNode);`.
**Fix:**
Filter out empty terms before processing.
opw-6446173Fixed a Sale report issue where PDFs could show an empty column after a user removed fields such as Taxes or Discount with Studio. This keeps customized sales documents cleaner and avoids confusing blank space in customer-facing quotes and orders.
Original PR description
**Steps to reproduce:** 1. Open a Sale Order report in Studio 2. Delete the Taxes column 3. Save 4. Create a sale order with at least one section line and products that have taxes 5. Print the sale…
**Steps to reproduce:** 1. Open a Sale Order report in Studio 2. Delete the Taxes column 3. Save 4. Create a sale order with at least one section line and products that have taxes 5. Print the sale order PDF **Issue:** - A blank column is rendered in the PDF report on section (and combo) rows whenever a column such as Taxes or Discount is removed via Studio. **Why this happens:** - The section row's `colspan` and the combo row's `colspan` were computed using `3 + (1 if display_discount else 0) + (1 if display_taxes else 0)`. - `display_taxes` and `display_discount` are derived from order data (i.e. whether any line has taxes/discounts), not from which columns are actually rendered in the table. - When Studio removes a column it deletes the `<th>` and matching `<td>` elements via XPath, but these Python variables remain `True`. As a result, section/combo rows still accounted for the removed column in their `colspan`, producing one extra cell and a visible blank column. **Fix:** - Introduce a `colspan_count` variable which is incremented inside each `<th>` body - Use that counter for `td_section_name` and `td_combo_name` instead of the previous formula. - Because the increment occurs inside the `<th>` element, it is skipped whenever the element is not rendered, whether because `display_taxes`/`display_discount` is `False` or because Studio's XPath removed the element entirely. opw-6433679
The mail compose process now uses the current progress-tracking method instead of an outdated one. This prevents unnecessary warning messages from filling server logs during scheduled mail queue processing, without changing how users send or process emails.
Original PR description
Since 19.0 `_notify_progress`` is deprecated in favor of `_commit_progress``. See: https://github.com/odoo/odoo/commit/ee337934f9885834d95592946f435c6e1c8ef970 Currently, the mail compose wizard still calls an explicit _notify_progress followed by an explicit commit. This leads to warning tracebacks being dumped into the server logs (for example everytime the "Mail Marketing: Process queue" cron runs). We replace it with an equivalent `_commit_progress` call, which should log the progress and implicitly take care of the cursor commit. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes the scheduled email queue process so it correctly recognizes when it is being run by the system scheduler. It also adds clearer logging of the email send limit, helping support teams investigate silent failures related to large batches or memory limits.
Original PR description
The changes introduced by https://github.com/odoo/odoo/commit/19d5367862528979abdcd411095f18d36bdbe7b8 aimed at aligning the mailing cron job logic with the new `_commit_progress` system. While doing…
The changes introduced by https://github.com/odoo/odoo/commit/19d5367862528979abdcd411095f18d36bdbe7b8 aimed at aligning the mailing cron job logic with the new `_commit_progress` system.
While doing so, it accidentally added an if condition based on `self.env.get('ir_cron')`, which will always return False and never run the progress commit as intended.
To address this, in this PR:
- we change the condition to `if self.env.context.get('cron_id'):`, the cron_id context variable being set when the method was called from a scheduled action
- additionally we take the occassion to add an info log that outputs the computed send limit at the time the method was triggered. This will make it easier to investigate the logs ad-hoc in situations where the "Mail: Email Queue Manager" cron job fails silently because of a memory limit error. A high send limit (batch_size) increases the chances of memory errors proportionally. Knowing what the exact sending limit was at a given point in time makes investigation easier when trying to build a sequence of past events that could explain issues related to email sending.
OPW-6396087
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe Uruguay localization now shows realistic, valid examples when a CI/NIE identity number fails validation. This helps customers understand that separators are optional and reduces confusion that could block online purchases.
Original PR description
## Description When a CI/NIE number fails the check digit validation, the raised error suggests `3:402.010-2 or 93:402.010-1 (CI or NIE)` as the expected format. This is misleading for two reasons: -…
## Description When a CI/NIE number fails the check digit validation, the raised error suggests `3:402.010-2 or 93:402.010-1 (CI or NIE)` as the expected format. This is misleading for two reasons: - The colon notation comes from Uruware's technical manual and is not how identity card numbers are written in Uruguay: users write `3.402.010-1` or plain digits (`34020101`). Real users facing the error keep reformatting a number whose check digit is simply wrong, believing the problem is the format. - The CI example shown is itself an **invalid** number: the check digit of `3.402.010` is `1`, not `2` — the module's own test suite (`l10n_uy/tests/test_check_vat.py`) uses `3:402.010-2` as an invalid sample. This was reported by an Uruguayan eCommerce user who lost sales because buyers interpreted the message as requiring an unusual format that does not exist in Uruguay. ## Change Replace the examples with valid numbers written in the notations actually used in Uruguay, and clarify that separators are optional — which is exactly what `_l10n_uy_ci_nie_is_valid()` already accepts (it strips `:. ,-` before checking the verification digit): ``` 3.402.010-1 or 34020101 (CI), 93.402.010-1 (NIE); dots and dash are optional ``` Only the `expected_format` string changes; the validation logic is untouched. Existing tests only assert the fixed part of the message (`The CI/NIE number.*does not seem to be valid`), so they are unaffected. Forward-Port-Of: odoo/odoo#282489
This fix prevents an error when users create accrued expense entries for purchase orders whose quantity was changed to zero. The accounting wizard now handles zero-value orders safely, allowing the accrual process to continue instead of showing an RPC crash.
Original PR description
### Steps to Reproduce: 1. Have a product where Track Inventory is enabled and the product category is FIFO and Perpetual 2. Create a PO for the product 3. Validate the receipt 4. Update the quantity…
### Steps to Reproduce: 1. Have a product where Track Inventory is enabled and the product category is FIFO and Perpetual 2. Create a PO for the product 3. Validate the receipt 4. Update the quantity on the PO to 0 5. Create Accrued Expense Entry > Traceback ### Description of the issue/feature this PR addresses: **Issue:** Currently when generating an Accrued Expense Entry for a PO where quantity on the line is updated to 0, the system crashes with an RPC error. This happens because reducing the line quantity to 0 sets the overall order amount to 0.0. Then. when the accrued orders wizard tries to calculate line-item ratios, it triggers a `ZeroDivisionError`. **Solution:** We can add a zero-check fallback condition when computing the line ratio inside `_compute_move_vals` in the `AccountAccruedOrdersWizard` class. The ratio calculation now defaults to 0.0 if the order total is zero, preventing division by zero. ### Current behavior before PR: Triggering the Accrued Expense Entry wizard on a PO with a changed quantity of 0.0 causes a `ZeroDivisionError` server error. The user receives an RPC error dialog and cannot proceed with creating the journal entry. ### Desired behavior after PR: The wizard should be able to process Purchase Orders with a line quantity of 0 without throwing an RPC error. The system should now cleanly generate the accrual entry based on received quantities. opw-6459403 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a spreadsheet issue where a single related record value could be treated as text instead of a number in locales that use a comma decimal separator, such as French. Users can now calculate correctly with these values when only one related record is returned, reducing formula errors in localized spreadsheets.
Original PR description
Steps to reproduce:
- insert a sale.order list into a spreadsheet
- change the locale to FR_fr
- add the formula in A1: =ODOO.LIST(1, 1, "invoice_ids.amount_total"
- in A2: =A1+1 => error
The value for the "amount_total" is stringified
to something like "4.5" because of the `[].join(",")` but "4.5" is not interpreted as a number in the FR locale where the decimal separator is "," and it should be "4,5"
With this commit, when there's a single record in the x2many, we fallback on the "normal" case and return the real value.
When there are multiple values, we volontarily keep the current behavior. We can't "just format it" because we join with "," and it wouldn't work if "," is also the decimal separator. This is a known and accepted limitation, especially in stable
Task: 6307092
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSplitting a restaurant order now correctly selects the full quantity when a combo includes the same choice more than once. This prevents under-counting items during bill or order splitting, helping restaurant staff avoid mistakes with combo meals.
Original PR description
Steps to reproduce: --- - Install `pos_restaurant` demo data. - Open a session for `Restaurant`. - Go to any table. - Add a Sushi Lunch Combo line with the same sushi choice multiple times. - Click the "More" button and select "Split". - Click on any combo product line. Issue: --- - Only one quantity is selected instead of the full combo choice quantity. Cause: --- - Combo child lines were incremented by a fixed value of `1` during split, without considering the quantity ratio between the combo root line and combo child lines. Fix: --- - Compute the selection step based on the combo line quantity relative to the combo root line quantity. - Properly update split quantities for repeated combo choices. - Added test coverage for combo lines with repeated quantities. task-6197879 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#282547 Forward-Port-Of: odoo/odoo#264049
This update cleans up data submitted when users post messages, helping ensure only appropriate and well-formed information is accepted. It reduces the risk of incorrect or unwanted message content being stored or shared, improving reliability and user trust.
Original PR description
This change sanitizes some post data before allowing the post, making sure the data received by `message_post` is clean based on the current user. part of task-6452761 Forward-Port-Of: odoo/odoo#282693 Forward-Port-Of: odoo/odoo#280894
Point of Sale and self-order screens now show discounted combo options with the correct minus sign instead of confusing formats like '+ -0.30'. This makes prices clearer for customers and staff and reduces checkout confusion.
Original PR description
When a combo choice has a negative extra price, the POS and Kiosk would incorrectly display a '+' sign in front of the negative price (e.g., '+ -0,30 €'). Additionally, depending on the currency formatting rules, a negative price might be displayed with the minus sign after the currency symbol (e.g., '$ -1.00'). This commit fixes this by conditionally displaying the '+' sign only when the extra price is strictly positive, and handling the minus sign manually to ensure it is always prepended correctly (e.g. '- $ 1.00'). task-id: 6226406 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#271772 Forward-Port-Of: odoo/odoo#265210
Fixed an issue where clicking a mention suggestion in the message composer could leave the typed search text instead of inserting the selected person’s name. This improves reliability when users mention contacts, especially after filtering suggestions with names containing special characters.
Original PR description
Before this commit, clicking a composer suggestion could leave the composer with the typed search instead of the selected name, as in the test "Mention a partner with special character (e.g. apostrophe ')" on runbot: Failed to find 1 of ".o-mail-Composer-input" with value "..." (Timeout of 10 seconds). Found 0 instead. This happens because NavigableList looks up the clicked option by index in its current props, while the item clicked comes from the last render. Typing "@" lists the two members of the channel and typing "Pyn" drops one of them: owl assigns the filtered options one frame before it patches the list, so a click in between looks up index 1 in a list of one option, finds nothing and returns. This commit passes the rendered option to the click handler, keeping the index lookup as a fallback so that the signature stays the same on a stable version. https://runbot.odoo.com/odoo/error/946154 Forward-Port-Of: odoo/odoo#282897
Argentinian delivery document setup now allows Class X delivery notes to be saved without CAI authorization codes or expiration dates. This aligns the workflow with government rules that require those details only for Class R delivery notes, reducing unnecessary blocking during warehouse configuration.
Original PR description
Currently, when the user attempts to create a delivery operation for a class X document type, the system prompts the user to provide values for the CAI and CAI Expiration Date fields. ## Steps to…
Currently, when the user attempts to create a delivery operation for a class X document type, the system prompts the user to provide values for the CAI and CAI Expiration Date fields. ## Steps to produce: - Install `l10n_ar_stock` with demo data - Switch Company to `(AR) Exento` - Create a warehouse - Configuration > Operation Types > Delivery Orders - Set Document Type to `'(94) MAILING X' `and try to save ## Observed Behavior: The fields 'CAI' and 'CAI Expiration Date', which represent the authorization code and expiration date issued by the government, are currently configured as required fields. **Expected Behavior:** As specified on the [government site](https://www.argentina.gob.ar/normativa/nacional/resoluci%C3%B3n-1415-2003-81316/actualizacion#:~:text=Los%20datos%20indicados%20en%20el%20inciso%20a%29%2C%20puntos%207%2C%2010%2C%2011%2C%2012%20y%2013%2C%20s%C3%B3lo%20ser%C3%A1n%20para%20los%20remitos%20clase%20%27R%27%2E): > > 12. Printing authorization code, preceded by the acronym 'CAI No. ...'. > 13. Expiration date of the receipt, preceded by the legend 'Expiration Date ...' > > 'The data indicated in section a), points 7, 10, 11, 12 and 13, will only be for 'R' class delivery notes.' These statements indicate that the information mentioned in points 12 and 13, including the **CAI** and **CAI Expiration Date** fields, is applicable only to **'R'** class delivery notes. Therefore, for class X delivery notes, these fields should be optional rather than required. ## Root Cause: According to [1], the field is configured as a required field when a Document Type ID is selected. This configuration causes the **CAI** and **CAI Expiration Date** fields to become mandatory, regardless of the document type requirements defined by the government specification. [1]- https://github.com/odoo/odoo/blob/62b05c4ea61942072b6b1fb420fe3efedb11ed14/addons/l10n_ar_stock/views/stock_picking_type_views.xml#L11-L16 ## Solution: Apply constraints that align with the government specifications, allowing the CAI and CAI Expiration Date fields to remain optional for document types where they are not required. opw-6359503 Forward-Port-Of: odoo/odoo#275533
This fix makes an internal messaging test wait until all peer connections are fully established before checking the result. It reduces random test failures on busy machines, helping keep development and release validation more reliable without changing user-facing behavior.
Original PR description
Before this commit, "mesh peer to peer connections" fails at random on a loaded machine, counting fewer connections than its ten users make:
[toBe] expected values to be strictly equal
> Expected: 90
> Received: 81
This happens because the test counts the peers as soon as its addPeer calls resolve. addPeer awaits the readiness promise of the peer, which also resolves, with false, when that peer is disconnected. A connection slow to open reaches the recovery watchdog, which tells the other side to drop the peer, drops it locally and adds it back without awaiting it. The awaited promises can therefore all be settled while recovered peers are still connecting.
This commit waits for the mesh to reach its full size before counting, so that a recovery in flight no longer decides the result. With the browser CPU throttled, the test fails about half of its runs before this commit, and none after.
Forward-Port-Of: odoo/odoo#282719Edited chatter messages now preserve contact mentions correctly when contact names or IDs overlap. This prevents broken mention links, helping users keep conversations clear and reliable after editing messages.
Original PR description
# Introduction This PR fixes broken mention links linked to the fact that we replace strings without paying attention to the fact that some strings may contain others that we want to replace later.…
# Introduction
This PR fixes broken mention links linked to the fact that we replace strings
without paying attention to the fact that some strings may contain others
that we want to replace later. This affects both id's and names of records.
See commit messages for more details.
# How to reproduce
- Create Contact A and then Contact B and either :
- Contact B's id need to contain Contact A's id (e.g. Contact B id = 12; Contact A id = 1)
- Contact B's name need to contain Contact A's name (e.g. Contact B name = ABC; Contact A name = AB)
- In a chatter create a message mentionning first Contact B and then Contact A
> Depending on the version, you might need to reload the page here
- Edit the message and save
# The issue
We see a broken mention in the chatter
# Cause
When saving an edited message, we give the raw body of the message (without the mention links) and the mentionend partners to `generateMentionsLinks` : https://github.com/odoo/odoo/blob/f9f605b1783d252d5e005bec50a2a72dd4ae0e13/addons/mail/static/src/utils/common/format.js#L152
This method's purpose is to replace the text links ("@Contact A") with actual html links. It does so by enumerating each partner given as an argument and replace the text mention with a placeholder :
https://github.com/odoo/odoo/blob/f9f605b1783d252d5e005bec50a2a72dd4ae0e13/addons/mail/static/src/utils/common/format.js#L158
It will then replace the placeholders with actual links : https://github.com/odoo/odoo/blob/f9f605b1783d252d5e005bec50a2a72dd4ae0e13/addons/mail/static/src/utils/common/format.js#L208-L218
The issue is that in both of those steps, we can try to replace a string that is contained
in another string we want to replace.
For exemple :
"string123 some text string12"
If we try to replace "string12" first, then we will select the wrong string :
"[string12]3 some text string12".
opw-6313748
Forward-Port-Of: odoo/odoo#282125
Forward-Port-Of: odoo/odoo#272549Spreadsheet exports now wait until map data has fully loaded before saving the file. This prevents incomplete or incorrect geo chart information from appearing in exported spreadsheets, improving reliability for users who share or archive these reports.
Original PR description
[FIX] spreadsheet: wait for spreadsheet data We now wait for the geo json to be loaded before freezing the spreadsheet data. Task: [4632983](https://www.odoo.com/web#id=4632983&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes a flaky automated test for the web image field by allowing a little more time for uploaded images to appear. It helps keep validation runs stable, especially when systems are under heavy load, without changing user-facing behavior.
Original PR description
Before this commit, this image field test sometimes failed because it could not find the image that had just been uploaded. Similarly to [1], we increase the waitFor timeout to 1s. Indeed, uploading an image can take time, and with high CPU usage, it could happen that the default 200ms delay wasn't enough. [1] https://github.com/odoo/odoo/pull/168196 runbot error-242406 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#281200
The mail thread data request now returns only the information that is actually needed for the current user and conversation. This reduces unnecessary data handling and helps keep messaging views more reliable and focused.
Original PR description
This change cleans up the requested data from `/mail/thread/data` route, ensuring it aligns with what is actually needed depending on the user and thread. part of task-6452761 Forward-Port-Of: odoo/odoo#282694 Forward-Port-Of: odoo/odoo#280713
Chat windows can now use an adjustable display priority instead of always appearing at a fixed layer on mobile screens. This helps other Odoo apps place their own panels or overlays correctly without being hidden behind chat.
Original PR description
The z-index of chat windows on mobile views was previously fixed at `1020`, preventing other modules from adjusting their stacking order. This commit introduces a configurable z-index for chat windows, defaulting to `1020` while allowing other modules to override it when needed. task-6412411
Clicking a table of contents item in the HTML editor now scrolls the page so the target heading is more clearly visible. This avoids confusion where users might think navigation did not work because the heading only appeared at the very bottom of the screen.
Original PR description
When clicking on a title in the TOC, we auto-scroll to that section of the HTML, allowing users to read that part. Since [1], scrollIntoView is replaced to consider top-aligned sticky elements. As a result, instead of scrolling to make it comfortable to read the section, it stops as soon as the title is visible. Unless you are really attentive at the bottom of the screen, it can look like the scrolling did not work. This commit computes the appropriate offset to make the TOC heading more visible after scrolling. [1]: https://github.com/odoo/odoo/commit/f5cf8565e7d09edd3a29fd95537381fb70d75785 Task-6394193 Forward-Port-Of: odoo/odoo#278304
Fixes an issue in the HTML editor where gradient-colored text inside a link could disappear while selected. This keeps linked text readable during editing, reducing confusion for users creating styled content.
Original PR description
Problem: When text formatted with `.text-gradient` is inside a link with `.o_link_in_selection`, the selected text becomes invisible. `.text-gradient` sets `-webkit-text-fill-color: transparent`, which prevents `color: black !important` on `.o_link_in_selection` from taking effect. Cause: `-webkit-text-fill-color: transparent` from `.text-gradient` overrides standard text `color` rendering, causing the text to stay transparent against the selection highlight background. Solution: Set `-webkit-text-fill-color: black` on `.o_link_in_selection` to ensure text inside gradient links is rendered in black and remains clearly visible when selected. Steps to reproduce: - Add text "ABCD". - Apply gradient color to all text. - Create a link on "BC". - Place cursor/selection inside the new link. - Observe that the text is not visible. opw-6479350 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixed an issue where AI chat windows on mobile could open behind other chat windows. This ensures users can immediately see and interact with newly opened AI chats, improving the mobile messaging experience.
Original PR description
AI chats opened on mobile views could appear behind other chats. This was inconsistent with the expected stacking behavior, where newly opened chats should appear on top of existing ones. To reproduce: * Open the chatter of any module. * Open the message composer in fullscreen mode. * Click the AI button. This commit increases the z-index of AI chats on mobile views so they are displayed on top of other chats. task-6412411
Invoice scanning now compares recognized bank account numbers against a cleaned version of partner IBANs, ignoring spaces and punctuation. This helps match vendors more reliably when invoices contain IBANs formatted differently from stored bank details.
Original PR description
When looking for a matching IBAN, we were searching on the `acc_number` field, which can contain spaces or special characters (dots, dashes, etc). But the OCR always returns the IBAN in a sanitized format, without any space or special characters, so it should be compared against the sanitized IBAN of the partners. task-none (issue found by chance) Forward-Port-Of: odoo/enterprise#127775
This change adds automated coverage for an Italian tax report carryover scenario, helping ensure VAT amounts are handled correctly across reporting periods. It reduces the risk of regressions in Italian localization reports after related fixes.
Original PR description
Add test for https://github.com/odoo/odoo/pull/279471 opw-6354509
Fixed an issue where attendance records at Monday midnight could be missing from the weekly Gantt view when the week starts on Monday. This ensures managers and HR teams see the same attendance information in weekly planning views as they do in list and monthly views.
Original PR description
### Current behavior: With first day of week set to Monday, a Monday attendance that starts and ends at local midnight does not appear in Attendances weekly Gantt. The same record is visible in List…
### Current behavior: With first day of week set to Monday, a Monday attendance that starts and ends at local midnight does not appear in Attendances weekly Gantt. The same record is visible in List and Monthly Gantt. Switching the first day of week to Sunday also shows it in weekly Gantt view. ### Expected behavior: Monday attendances should appear in weekly Gantt view when the week starts on Monday, including 0-duration records at Monday 00:00. ### Steps to reproduce: 1. Set first day of the week to Monday 2. Create an attendance on Monday with check-in and check-out at 00:00 3. Open Attendances > Gantt > Weekly 4. The Monday column is empty while List still shows the record ### Cause of the issue: `AttendanceGanttModel._getDomain` filters with check_out > range start. When the week starts Monday, range start is Monday 00:00, so a record whose check_out equals that bound is excluded. ### Fix: Fix the comparison to be `check_out >= range start` so records ending at week start are still fetched and rendered. opw-6414884
The bank journal screen now hides online synchronization prompts when the selected bank statement source is not set to synchronization only. This prevents users from seeing misleading send-now actions or connection requests after changing how bank statements are handled.
Original PR description
Before this commit, the "send now" button and the connection request were shown as soon as we had an account online account link to the journal. But when changing the bank statement source, the information would still be there. Changing the invisible condition to hide it when the bank statement source is different from only_sync no task id
The update adjusts automated testing for restaurant appointment flows in Point of Sale so tests continue working after POS data reloads. This keeps production behavior unchanged while improving confidence that the appointment workflow remains reliable.
Original PR description
A recent PR in the community repository introduced a full clear of both `localStorage` and `sessionStorage` when reloading POS data. While this is the intended behavior in production, it breaks the test framework. This commit mocks the `clear` methods directly within the tour steps right before the reload action. This ensures the test survives the page reload and keeps its state, without polluting the core production code with test-specific logic. task-6456447
This fix prevents an unnecessary warning popup from appearing in self-order kiosk setups when the system checks for an IoT printer. It helps avoid confusing customers or staff with an alert that is not relevant for that ordering flow.
Original PR description
This PR fixes the test where iot request triggers a "failed to contact your iot box on local network popup"
This fix prevents spreadsheet-related data from being converted into plain text when it should keep its structured format. It helps ensure users see and interact with linked records accurately in spreadsheet views and controls.
Original PR description
See community PR task-6307092
Acerta payroll exports for Belgian employees now include weekend days when an eligible leave period overlaps a weekend. This ensures sick leave and similar absences are reported according to Acerta requirements, reducing missing data in payroll submissions.
Original PR description
## Steps to reproduce: - Install l10n_be_hr_payroll_acerta - Create an employee in a belgian company - Create a sick time off for the created employee that overlaps with a weekend - Export acerta report for the employee - Notice the weekend that overlaps with the time off is not present in the report ## Cause: While exporting the report file we only loop over the created work entries' dates and since weekends doesn't have work entries we don't consider them in the report. ## Fix: When generating the line of a leave's start date we check if the leave overlaps with a WE, we fetch the WE's date and we generate a line for each day of the WE. According to Acerta this is the correct behavior for their reports for specific types of leaves. **opw-6313534** Forward-Port-Of: odoo/enterprise#127852 Forward-Port-Of: odoo/enterprise#124500