Daily updates from Odoo
Tuesday, June 30, 2026
30 changes · saas-19.4
Resolved issues and error corrections
This change keeps the Base Unit Count value at very high precision, so products sold in large packs can be priced correctly at the unit-reference level. It fixes cases where values like 0.0001 were being rounded too aggressively, which could distort the displayed reference price for bulk items.
Original PR description
**Description of the issue/feature this PR addresses:** The `Product Reference Price` feature in `website_sale` cannot correctly handle products sold in large packs when the reference quantity…
**Description of the issue/feature this PR addresses:** The `Product Reference Price` feature in `website_sale` cannot correctly handle products sold in large packs when the reference quantity requires a very small `base_unit_count`. For example, a product sold as a `box of 10000` screws should be able to use `0.0001` as its `Base Unit Count`, so the reference price can be computed against the box quantity correctly. **Current behavior before PR:** `base_unit_count` uses the default float precision, so values with more than two decimal places are rounded in the product form. When trying to set `Base Unit Count` to `0.0001`, the value is rounded to `0.00` / `0.01`, which makes the Product Reference Price computation incorrect. Steps to reproduce: 1. Go to Settings > Website and enable Product Reference Price. 2. Create or open a product named `Screws`. 3. Set Sales Price to `$ 1.00`. 4. On the product form, set Base Unit Count to `0.0001`. 5. In Custom Unit of Measure, type `box of 10000` and press Create. <img width="1374" height="740" alt="1" src="https://github.com/user-attachments/assets/2d4f7863-b2cd-4c7c-87e1-11526dc50551" /> **Desired behavior after PR is merged:** `base_unit_count` keeps high-precision values such as `0.0001`. This allows `Product Reference Price` to correctly support large-pack scenarios, such as selling screws in a `box of 10000`, by storing `base_unit_count` with unlimited numeric precision. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#270261 Forward-Port-Of: odoo/odoo#262579
This fix ensures orders paid through the Viva app-to-app flow complete the same follow-up steps as normal payments, including automatic receipt and preparation printing. It also makes sure Viva’s payment prompts still appear for fast payment methods and clears outdated saved choices so users can correct mistakes more easily.
Original PR description
[FIX] point_of_sale, pos_viva_com: automatic receipt printing 3 Fixes for the app-to-app integration of Viva 1. Under the normal flow the `OrderPaymentValidation` does the payment validation and post…
[FIX] point_of_sale, pos_viva_com: automatic receipt printing 3 Fixes for the app-to-app integration of Viva 1. Under the normal flow the `OrderPaymentValidation` does the payment validation and post validation operations (such as receipt printing or preparation prints). Then it launches the `FeedbackScreen` with the validation promise on the `waitFor` prop. The `pos_viva_com` app-2-app integration does the payment validation on the backend on the callback endpoint. Then it redirects the user directly on the `FeedbackScreen` skipping the normal validation and post validation operations. This means that receipts and preparation prints do not get processed. This PR adds a check on the `FeedbackScreen` to see whether there is anything set on the `waitFor` prop. If the prop is undefined, we can expect that the screen was mounted outside the normal flow, so we run the post validation operations manually. --- 2. Using the fast payment method with Viva would use `order.addPaymentLine` instead of the overloaded `payment_screen.addNewPaymentLine`. So the integration pop up which is defined in the `payment_screen` would never fire. Now I've added a check on `validateOrder` to detect whether we're about to use a `fastPaymentMethod`, in which case it will apply the same behaviour as the override of the `payment_screen.addNewPaymentLine` --- 3. Added a patch for `reloadData` which will remove the answer for the Viva wallet pop up from local storage in case users change their minds or made a mistake Task-[6251297](https://www.odoo.com/odoo/project/1737/tasks/6251297) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267714
This update fixes an editing issue where the cursor could jump to the wrong side of template content after deleting text. It helps users edit email templates more smoothly and avoids unexpected cursor behavior in <t> blocks.
Original PR description
## Problem:
`<t>` elements are classified as self-closing, even if they aren't used that way in a mail template. If you press backspace in the editor on some plain text that happens to be inside a `<t></t>` block, the editor would prevent the cursor from being placed back inside the block after merging because of `normalizeSelfClosingElement`. The result is the cursor being left on the outside edge of the block.
## Solution:
We will remove "T" from the list of self-closing tags.
## Steps to replicate (runbot v18):
1. Open an email template (Purchase: Purchase Order)
2. Place your cursor in some text inside a t-if element ('The receipt is expected for...'). Press backspace. Your cursor will snap to the end of the t-if block.
opw-6124284
Forward-Port-Of: odoo/odoo#272285
Forward-Port-Of: odoo/odoo#266816This update fixes an issue where font formatting could be applied outside the part of the page that can actually be saved. As a result, style changes made in website builder and translation views are now preserved correctly after saving.
Original PR description
Commit e0cf601ab6fc1d7cb007fcb16ee4bb6097ba6fdd added a condition to apply format on the parent of fully selected unsplittable nodes. But this could lead to format applied outside of `contenteditable=true` nodes in some cases of website builder. This commit adds a condition to only apply format outside the unsplittable if it is not the node with `contenteditable`. Steps to reproduce: - In event page, open website builder - Double click on "Starts" in the sidebar inside the event page - Change font size - Save - Bug: the changed font size is not save (a span with the font class was created outside the savable element) ### - In translate mode - Select a whole translation span - Change font size - Save - Bug: the changed font size is not save (the font class was added on the translation span) task-6308352 Forward-Port-Of: odoo/odoo#271888 Forward-Port-Of: odoo/odoo#270401
Tracked links generated without an active website context now fall back to the system base URL instead of using a company website by mistake. This ensures emails and queued marketing jobs keep the correct public link domain in multi-company setups.
Original PR description
The [`_compute_short_url_host`](https://github.com/odoo/odoo/blob/a81fa8699c89385d2cccb260ada07255c6ea1275/addons/website_links/models/link_tracker.py#L20-L24) override builds link.tracker short URLs…
The [`_compute_short_url_host`](https://github.com/odoo/odoo/blob/a81fa8699c89385d2cccb260ada07255c6ea1275/addons/website_links/models/link_tracker.py#L20-L24) override builds link.tracker short URLs from `website.get_current_website()` and the current company's website domain. It was introduced by https://github.com/odoo/odoo/commit/f13ecb15af7f0bdc67e37dfb41e8bac77f5a541a for a multi-company backend flow (users switching companies to post social marketing links), but it runs for every compute, including CRON contexts with no HTTP request such as the mass-mailing queue. Without a request, `get_current_website()` picks an arbitrary website (the first in the database) and `self.env.company` resolves to the user's main company, so the short URL uses that company's website domain instead of `web.base.url`. Fall back to `super()._compute_short_url_host()` (which uses `web.base.url`) when no website is resolvable from the request, session, or context. Backend flows with a real request still hit the company-aware branch. Steps to reproduce: 1. Install Email Marketing and Website. 2. Settings > Companies: create a second company B. Settings > Websites: ensure website A points to company A with domain A, and create website B for company B with domain B. 3. Settings > Technical > Parameters > System Parameters: set `web.base.url` to a third domain C, and add `web.base.url.freeze` = `True`. 4. On company A, Email Marketing: create a mailing with body `<a href="http://example.com">test</a>` and a recipient list, then click Send. 5. Settings > Technical > Automation > Scheduled Actions > "Mass Mailing: Process queue" > Run Manually. 6. Email Marketing > Configuration > Link Tracker: open the tracker generated for the mailing. => The Tracked URL uses domain A. => The Tracked URL uses domain C. Ticket [link](https://www.odoo.com/odoo/project.task/6038590) opw-6038590 Forward-Port-Of: odoo/odoo#259200
This change fixes an issue where product costs could be calculated incorrectly when a business uses multiple companies or branches. The system now considers stock movements from all relevant companies, so inventory valuation stays accurate and lot-based product costs are shown correctly.
Original PR description
The quantity on hand for a main company with branches is calculated to be the the sum of all its child companies + its own quantities. `_run_fifo_get_stack()` doesn't include the child companies in…
The quantity on hand for a main company with branches is calculated to be the the sum of all its child companies + its own quantities. `_run_fifo_get_stack()` doesn't include the child companies in the `moves_domain`, so it is unable to create a FIFO stack for moves from a child. This leaves extra quantity unaccounted for, which defaults to the standard_price. **Video of the bug:** https://drive.google.com/file/d/11PIfNAIb_Yyo4A-3R0CRF0NV6_HE6EwF/view **Issue:** When multiple companies are selected, the displayed quantity on hand for a product is calculated as the sum of all selected companies. However, the moves domain only looks at the main selected company instead of all selected companies, leading to an incorrectly calculated standard price when using FIFO. This is more apparent on lot-valuated products because the lot standard price is recalculated every time the field is accessed. **Reproduction steps:** - Have a main company - Create a branch company - Create a product, configure it as FIFO on both the main company and branch company - Let the product be tracked by lots and set to `Valuation by Lot` (for demonstrative purposes) - On the main company, set the product cost to $15 (for demonstrative purposes) - Go to only the branch company, make a purchase for one unit of the FIFO product at $100 (make a warehouse for delivery) , validate the receipt - Go to the lot -> When logged in to only the branch company, quantity is 1 and cost is $100 (correct). When logged in to both the main and branch company and viewing from the main company, quantity is 1 and cost is $15 (incorrect) **Fix:** Allow `_run_fifo_get_stack()` to see the moves from all companies in the environment instead of just the main company Related ticket: opw-6064126 Forward-Port-Of: odoo/odoo#270695 Forward-Port-Of: odoo/odoo#258199
This fixes an issue where the timesheet button could disappear from the top bar when attendance options were turned off. Users can now still start or record timesheets from the toolbar, which keeps the feature easy to access in all attendance setups.
Original PR description
Steps to reproduce: - Install Attendance + Timesheets - Disable "Attendances from Backend" - Timesheet icon disappears from toolbar Current behavior: Bridge module permanently removes the `timesheet…
Steps to reproduce: - Install Attendance + Timesheets - Disable "Attendances from Backend" - Timesheet icon disappears from toolbar Current behavior: Bridge module permanently removes the `timesheet systray` from the `registry` and merges it inside the attendance dropdown. When `attendance_from_systray` is off, the dropdown hides itself and takes the timesheet icon with it, leaving no way to log hours from the toolbar. Expected behavior: Timesheet icon should remain accessible when attendance from systray is disabled. Issue: `registry.remove()` at module load made the timesheet icon impossible to restore. Fix: Keep the timesheet systray registered. Patch TimesheetSystray to read `display_systray from lazy_session` on startup and show itself standalone when attendance from systray is off. The template no longer replaces nodes. Header and total_hours are toggled via `position="attributes"` (`t-if="!props.signInOut"`, a prop only passed by the attendance dropdown), and a self-contained dropdown-only footer with the Check out button is added after total_hours. Ref: odoo/enterprise#104347 task-6285068 Forward-Port-Of: odoo/enterprise#121551 Forward-Port-Of: odoo/enterprise#119840
This change prevents a warning from being shown or logged for every uploaded document when automatic OCR is turned off. It reduces noise in the system logs and makes it easier to spot messages that actually need attention.
Original PR description
The warning "Automatic OCR does not apply to this document" was logged for every upload when automatic OCR isn't enabled, it isn't very useful. Manually backported as branch 19.4 was created during fw-port of original PR. opw-[6232122](https://www.odoo.com/odoo/unassigned-tasks/6232122) X-original-commit: 49b7d2bdc8ba20f6286c51c2721045cda36c4b8e
The website generator now uses a more general page limit note instead of showing a specific number. This gives the system more flexibility to adjust page limits later without confusing users.
Original PR description
Page limit note fixed by being more general instead of stating a blatant 200. This gives us more leeway to control the nbr of pages IAP side. X-original-commit: d82ef3a10c671972131bab7d28c76cce82e55105
This change fixes a timing issue in the WhatsApp channel test so message status updates are applied in the correct order. As a result, the test no longer fails intermittently, making the WhatsApp chat experience more reliable to validate.
Original PR description
The "Allow SeenIndicators in WhatsApp Channels" test awaited the bus subscription so the simulated seen notification is no longer dropped, but that exposed a second race between the init RPC and the bus return. openDiscuss does not await the channel data fetch (channels_as_member), whose response carries each member seen_message_id=false. When it is applied after the _sendone seen notification, it clobbers the member back to unseen, the indicators never render, and the assertion times out. Wait for the message to render before simulating the seen notification: the thread message comes from the message fetch, which only runs once the channel (with its members) is loaded, so the seen data is guaranteed applied. This mirrors the message seen indicator tests in mail. https://runbot.odoo.com/odoo/error/242021 Forward-Port-Of: odoo/enterprise#122041
This change fixes memory leaks in the web test suite, making tests more reliable and reducing the chance that one test affects another. It also prevents unwanted server calls during cleanup, which helps avoid test failures at the end of runs.
Original PR description
Fix memory leaks introduced by https://github.com/odoo/odoo/pull/271765 See commit messages for details. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The system restores a previous performance optimization when checking access rights for views. This keeps the fix for earlier loading issues while improving speed again, so users should benefit from a smoother experience without the earlier slowdown.
Original PR description
This reverts commit f2442a193584d6a2ecc8af4f9cd06002148211f5, which was avoiding method ir.access._get_all_access() to fail on not yet loaded fields. Commit 1570432f930baac8b018f7339338057ac8c2226c now avoids the method to fail in such cases. Therefore the de-optimization is no longer necessary.
This update prevents website forms from crashing when a user quickly edits a field or deletes it, especially on slower networks. It also makes an existing form test more reliable, reducing occasional failures during automated checks.
Original PR description
Before this commit, on slow networks users could trigger a traceback by quickly selecting a form field and deleting it. This happened because code executed from `FormFieldOption` `onWillStart` assumed the form field element still existed after awaiting asyncronous functions. This also caused the tour `test_website_form_conditional_required_checkboxes` to occasionally fail on runbot. This commit hardens the method `FormOptionPlugin.loadFieldOptionData` against DOM mutations that may happen while awaiting asyncronous code. In particular, `fieldEl` is now validated after every await. The code is also optimized such that syncronous code relying on the existance of the form field element is executed before the asyncronous one. Note that this change would not be necessary inside builder actions, but it is required because the code is also executed from `FormFieldOption` `onWillStart` and `onWillChangeProps`. runbot-940447
This update corrects the color shown in the Timesheets grid when an employee’s schedule includes fractional working hours. It prevents the app from marking a cell as warning/orange by mistake when the worked time exactly matches what is expected.
Original PR description
## Issue In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color…
## Issue
In the Timesheets app, the color of the *Time Spent* cell at the end of a row indicates the current status of the timesheets based on the expected number of working hours. The selected color (green/orange/red) is sometimes wrong when an employee has a work schedule with fractional hours.
## Steps to reproduce
1. Install *Timesheets* (`timesheet_grid`)
2. For an employee E, edit the *Standard 40 hours/week* schedule:
- Change *Monday Afternoon* "Work to" column from 17:00 to 17:20.
3. In Timesheets > All Timesheets, go back one week and fill the timesheet for the employee E. We need 8 hours everyday but on Monday, where we need 8 hours and 20 minutes.
4. __The background of the *Time Spent* cell is orange, even though there's no overtime anywhere, and the value in the cell is precisely 40:20, which is the expected amount of hours worked.__
## Cause
When comparing the amount of hours worked and the expected amount of hours, small rounding errors occur. At this point of the execution:
https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L157
We obtain the following values:
```js
> monday = section.cells[1]
> monday.value
8.333333333333336
> workingHours[monday.column.value]
8.333333333333332
> monday.value - workingHours[monday.column.value]
3.552713678800501e-15
```
This small difference differing from 0, the wrong color is selected by `_getSectionTotalCellBgColor`:
https://github.com/odoo/enterprise/blob/19b7f5a6961dbce7367c07fcc55eea1925832634/timesheet_grid/static/src/views/timesheet_grid/timesheet_grid_renderer.js#L160-L172
## Fix
The same issue was fixed elsewhere by https://github.com/odoo/enterprise/commit/3340c0610ae6d7d3087f20da04309512771cc4b7. The same fix is applied here for consistency.
opw-6193181
Forward-Port-Of: odoo/enterprise#121463This update prevents the AI assistant from asking for confirmation twice when creating project tasks. It checks that all required information is available before showing the preview or creating the item, which avoids confusion and makes the task creation flow more reliable.
Original PR description
This commit removes an issue where the LLM would retry on error when performing a creation which would give the impression that it created items twice. To do so, this commit now validates that the fields exists before calling the `create()` method, and before showing the preview to the user. Ensuring it avoids throwing an error after the message has been confirmed (resulting in the double preview). task-6229596 X-original-commit: c21dcfe8e4a2c399ee25ebeadd408ce303ce2ff9
This update adjusts the holiday calendar side panel to work with the latest Owl framework version used in Odoo. It helps keep the scheduling interface stable and prevents issues caused by outdated component behavior.
Original PR description
This commit is a follow-up of 197d0ca5, as part of the Owl 3 migration, replace onWillUpdateProps hook with the appropriate Owl 3 alternatives 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
When users switch companies while viewing a payroll pay run, the system now checks access before reloading the page. This prevents a brief error message from appearing and takes users directly back to the pay run list when the record is not accessible in the new company context.
Original PR description
Steps to reproduce: 1- Open a payrun 2- Switch companies Issue: You get an access error for a moment and then get redirected to payrun list view Cause: When switching companies, the payrun reloads but since it is in the context of a different company, you get an access error. Solution: First check in js before fetching that you have access to the payrun, if not, redirect to the list view instead. Task-6008140 Forward-Port-Of: odoo/enterprise#120004
Fixed an issue where some conversation threads could fail to show their messages after reloading. This helps ensure users reliably see the latest messages instead of an empty placeholder.
Original PR description
The Thread component mirrors `thread.isLoaded` into the `state.mountedAndLoaded` flag that gates whether the real messages (as opposed to the empty phantom placeholder) are rendered. The mirroring…
The Thread component mirrors `thread.isLoaded` into the `state.mountedAndLoaded` flag that gates whether the real messages (as opposed to the empty phantom placeholder) are rendered. The mirroring effect both read `mountedAndLoaded` as a dependency and wrote it. `useEffect` records its dependency array before running the body, so right after the effect sets `mountedAndLoaded` to true the recorded dependencies still hold the pre-write pair `[isLoaded=true, mountedAndLoaded=false]`; that update only settles on a later, microtask-deferred patch. When a second reload runs `reset()` in that window, it drives `mountedAndLoaded` back to false while `isLoaded` stays true. The settling patch then computes the very `[true, false]` pair that was already recorded, so the effect never re-runs: `mountedAndLoaded` is stranded at false and no message is ever rendered. Depend on a monotonic `resetCount` bumped by `reset()` instead of on `mountedAndLoaded` itself. It is never written by the effect, so the recorded dependencies can no longer match the current ones after a reset and the effect always re-runs to re-sync `mountedAndLoaded` with `isLoaded`. `reset()` keeps clearing `mountedAndLoaded` as before (the false dip is needed for the reload scroll handshake), so the behaviour is otherwise unchanged. https://runbot.odoo.com/odoo/error/940032 Forward-Port-Of: odoo/odoo#272589 Forward-Port-Of: odoo/odoo#272281
We fixed an automated test in the chat features that was sometimes failing at random. The check now looks directly at the chat title instead of relying on a brief loading moment, making test runs more reliable and reducing false failures.
Original PR description
The hoot `:text('X')` pseudo-class matches an element only when its whole inline text equals "X". `.o-mail-ChatWindow:text('slytherins')` therefore matched the chat window only during the brief frame where it showed nothing but its title, before the thread body (start message, composer) was rendered. Catching that frame is a race, so the assertion times out intermittently on runbot.
Assert against the title element itself: add a dedicated `o-mail-ChatWindow-name` class on it and match it with `.o-mail-ChatWindow-name:text('X')`. This is exact and no longer depends on the rest of the window being empty.
https://runbot.odoo.com/odoo/error/939914
Forward-Port-Of: odoo/odoo#272567
Forward-Port-Of: odoo/odoo#272380This update corrects how sales margins are calculated when different tax display modes are used on documents. It ensures the reported margin stays accurate and consistent for users regardless of how taxes and prices are shown.
Original PR description
A newly introduced feature in commit 001d3255cd134656970c98b6e367d6ae3ec77124 caused the tax and price computation to differ, making the margin computation to be inaccurate depending on the document tax mode chosen. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the ticket screen numpad could appear when it should stay hidden in certain point-of-sale setups. It improves the consistency of the interface for users working with specific POS configurations, such as Urban Piper and HR-related flows.
Original PR description
Steps to reproduce: =================== - Ensure `pos_hr` and `pos_urban_piper` is installed. - Install `l10n_in_pos_urban_piper`. - Open a draft Urban Piper order and notice that the numpad is visible. Cause: ====== - The numpad visibility depends on a `t-if` condition in XML. - Due to the asset loading order, this condition gets overridden by another module. Fix: ==== - Move the visibility logic to a getter method. - Override the getter in other modules instead of using XML to control the visibility. Task-6299415 Related Enterprise PR: https://github.com/odoo/enterprise/pull/120571 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an unstable automated test in the messaging app that could fail intermittently under slower conditions. It does not change user behavior, but it helps ensure future releases are tested more reliably.
Original PR description
The "Jump to old reply should prompt jump to present (RPC small delay)" test clicked the jump-to-present button right after clicking the in-reply, without waiting for the jump to the old reply to render. The button only shows once that load has settled, so under load the button could still be absent when the click polled for it, making the test flaky. Wait for the messages to be reloaded around the old reply before clicking, mirroring the non-delayed sibling test. https://runbot.odoo.com/odoo/error/941200
This update corrects a display issue in the Point of Sale ticket screen where some buttons and the numpad could appear when they should be hidden. It also improves consistency across installed extensions and fixes a dark-mode styling issue for the prep order time field.
Original PR description
Issue 1: ====== Numpad Visibility in TicketScreen of draft urban piper orders Steps to reproduce: =================== - Ensure `pos_hr` and `pos_urban_piper` is installed. - Install…
Issue 1: ====== Numpad Visibility in TicketScreen of draft urban piper orders Steps to reproduce: =================== - Ensure `pos_hr` and `pos_urban_piper` is installed. - Install `l10n_in_pos_urban_piper`. - Open a draft Urban Piper order and notice that the numpad is visible. Cause: ====== - The numpad visibility depends on a `t-if` condition in XML. - Due to the asset loading order, this condition gets overridden by another module. Fix: ==== - Move the visibility logic to a getter method. - Override the getter in other modules instead of using XML to control the visibility. - Also fixed the css issue for prep order time input when using it in dark mode --- Issue 2: ====== Invoice button visible on Chile Company's TicketScreen Steps to reproduce: =============== - Ensure `pos_urban_piper` is installed, open the Chile company's PoS Config - In the ticket screen, we have an invoice button on paid orders. Cause: ===== - Button visibility handled through XML conditions; this condition gets overridden by another module. Fix: === - Move the visibility logic to the getter method and override it in submodules to control visibility. Task-6299415 Related Community PR: https://github.com/odoo/odoo/pull/270088
This change prevents a crash that could happen when a user canceled a new webhook record and then tried to create another one right away. It improves stability in Studio’s Webhook screen and avoids an interruption caused by a timing issue after a frontend update.
Original PR description
Go in studio => Webhook tab Click on new Click cancel and back to list view again click on new Before this commit, there was a crash due to a race condition that appeared after owl3 migration. This commit solves this by protecting the first update in favor of the second opw-6332360 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 spreadsheet app was updated to the latest version, bringing several usability fixes and small interface improvements. Users should see smoother chart interactions, better font handling on Linux, and fewer pop-up issues when editing spreadsheets and charts.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b0b4c4027f [REL] version 19.4.0 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/b0b4c4027f [REL] version 19.4.0 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/4ce11c6918 [IMP] package: update to owl alpha 40 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/209e5072a9 [IMP] header_size: make getters consistent [Task: 6332479](https://www.odoo.com/odoo/2328/tasks/6332479) https://github.com/odoo/o-spreadsheet/commit/4520b613fe [IMP] statistic bottom bar : close the menu [Task: 6316288](https://www.odoo.com/odoo/2328/tasks/6316288) https://github.com/odoo/o-spreadsheet/commit/2ab649b389 [FIX] sheet: close the color picker on external click [Task: 6322171](https://www.odoo.com/odoo/2328/tasks/6322171) https://github.com/odoo/o-spreadsheet/commit/2ab8f9a641 [IMP] charts: annotation tool [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/0ff30dd158 [REV] typing: exclude non-exported symbols in type resolution [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/f982c69ff5 [IMP] package: update owl to 3.0.0-alpha.39 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e40bf0cc08 [IMP] tools: run esm version is node [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/61f99a225c [FIX] Fonts: Add default font for Linux [Task: 6328646](https://www.odoo.com/odoo/2328/tasks/6328646) https://github.com/odoo/o-spreadsheet/commit/2687933537 [FIX] typing: exclude non-exported symbols in type resolution [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/1263a6e8de [FIX] components: use owl3 syntax [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update prevents a rare conflict when uploading vendor bills with automatic OCR enabled. It makes sure the bill’s access token is saved earlier, so OCR processing no longer clashes with the bill creation flow and cause processing failures.
Original PR description
When a new bill is created from an attachment, the import flow may commit inside `_extend_with_attachments`. If automatic OCR is enabled, this commit can run the OCR postcommit callback, which writes on the same account.move. The access token was flushed after that import flow, so it races with the OCR callback and triggers a serialization failure. Create and flush the access token before entering the import flow, so the write happens before OCR postcommit callbacks can run. task-[6340793](https://www.odoo.com/odoo/project/967/tasks/6340793) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change moves a self-order-related check out of the standard Point of Sale flow and into the self-order feature where it belongs. It helps prevent failures in automated testing and keeps the regular Point of Sale behavior aligned with its intended scope.
Original PR description
This commit moves the usage of `has_valid_self_payment_method` from `point_of_sale` to `pos_self_order`, where it belongs. The method usage was introduced in https://github.com/odoo/odoo/pull/269502, causing runbot failures Runbot Errors- [941124](https://runbot.odoo.com/odoo/error/941124), [941125](https://runbot.odoo.com/odoo/error/941125), [941126](https://runbot.odoo.com/odoo/error/941126)
The chatter now refreshes properly when a record is reloaded without changing to a different record. This means new attachments and similar updates appear immediately, instead of requiring a full browser refresh or showing outdated indicators.
Original PR description
Since 71336f7f7d25 ("[REF] mail: introduce useOnChange hook"), the chatter only refetched its data (attachments, followers, ...) when the thread identity changed. A same-record form reload keeps the same thread, so nothing was refetched: an attachment created on the record without a message_post (e.g. the pdf generated by "Send & Print", or an account return validation) only showed up after a full browser refresh, the paperclip icon staying stale.
The messages were still refreshed because Thread listens to MAIL:RELOAD-THREAD and calls fetchNewMessages(); the chatter had no such listener. Add the symmetric listener so the chatter reloads its data on a same-record reload too.This fix ensures an employee’s basic salary is classified correctly on Form 2316. Salaries below the tax-exempt cap are now reported as non-taxable, while salaries above the cap remain taxable, which helps prevent incorrect payroll tax reporting.
Original PR description
Previously, a regular (non-MWE) employee's basic salary was always reported as taxable (item 39), regardless of amount. This commit fixes that by checking the yearly basic salary against the tax-exempt cap. If it is below the cap, it is now reported as non-taxable (item 29) and when the amount is above the cap it will be taxable (item 39) Backport of odoo/enterprise@a7362ad273ba8c38aa0908f0765526f8ed8b8193 task-6328424
Searching messages could previously send the same request twice, which could slow down the interface and create unnecessary load. This update ensures the search only runs once per action, improving responsiveness and reliability when users look for messages.
Original PR description
Previously, searching messages could trigger two RPCs for a single search. This was caused by the search effect executing 'run()' even after the search had already been performed. This PR ensures that the search effect only clears results when inactive, preventing duplicate search RPCs. task-6311095 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr