Daily updates from Odoo
Wednesday, November 19, 2025
259 changes
6 changes
Enhancements to existing features
IoT Box information is now loaded ahead of time, so IoT requests can continue working even when the connection is unstable or temporarily offline. This also reduces the number of database requests, which should improve overall performance for connected point of sale and self-order flows.
Original PR description
In order to allow iot requests to work offline, and also reduce the amount of orm requests sent to the db, we now preload IoT Box records in the `iot_http` service. Task: 5258886
Resolved issues and error corrections
Reprinting a previously selected POS order now prints the correct receipt instead of always printing the latest one. This fixes an issue for Italian POS users who needed to reprint older tickets for customers or record-keeping.
Original PR description
before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected. Steps to reproduce: 1. setup an DB with an italian…
before this commit, when trying to reprint a past order it would not work. Instead it would print the last order no matter what order is selected. Steps to reproduce: 1. setup an DB with an italian POS 2. make 2 sales with a different product (easier tracking) 3. open the "orders" view 4. try to reprint the ticket of the firt order result: the receipt of the second order is printed the reason for this is that we were using the printer's built in command "printDuplicateReceipt" which is inteded for printing the very last receipt. With this commit, we changed the behavior and invoke another printer command. That command is meant to reprint any receipt, based on the provided reference. After this commit, trying to print any past receipt will print that exact receipt. IMPORTANT NOTE: In theory, the printer command can reprint any number of receipts. We decide that we will only use it to reprint the one receipt selected by the user. This moves the complexity of parsing date strings and ranges to the command component and therefore will keep the rest of the code cleaner. opw-5008702 opw-4882480 Forward-Port-Of: odoo/enterprise#96122
This fix corrects the activity counters shown in the top bar for Tasks, To-Dos, and Mailings. Previously, if several activities were linked to the same record, they were all counted separately; now each record is counted once based on its most urgent activity, matching the expected behavior.
Original PR description
Issue: When multiple activities were created on a single record (e.g., a Task, To-Do, or Mass Mailing), the systray counters for late/today/future activities would incorrectly count *all* of them. The standard behavior is to count only one (the most urgent) per record. Cause: Modules that split activity groups: `project` (for Tasks/To-Dos) and `mass_mailing` (for Email/SMS), used custom counting logic. This logic was outdated and did not follow the "one count per record" rule. Solution: Refactor the custom activity-grouping logic to make the count conform to the general rule again. This aligns all systray counters, ensuring Tasks, To-Dos, and Mailings are now correctly counted only once, based on their most urgent activity. Task-5059640 Forward-Port-Of: odoo/odoo#226940
This fix restores a missing setting needed to properly validate Wi‑Fi configuration before saving it. As a result, Wi‑Fi settings are kept after a device reboot, reducing the chance of connection issues.
Original PR description
In odoo/odoo#233813, the writable context was mistakenly removed. This commit adds it back to ensure Wi-Fi configuration is saved after reboot. Forward-Port-Of: odoo/odoo#234293
Contract templates now show only records that have assigned activities when users open the Activities view. This prevents the list from displaying all templates by mistake and makes it easier to find items that need attention.
Original PR description
The contract template’s activity view incorrectly displays all contracts, instead of only those with assigned activities. **Steps to reproduce this issue:** 1) Install the hr module. 2) Open Employees → Employees → Contract Templates. 3) Create multiple contract templates and add an activity to one of them. 4) Open the activities from the Activities (top right corner). **Issue:** You will end up in the all contract templates list, with no filters applied. **Cause:** When the user clicks on the activities, a default search filter is added in the context, which is then applied to the view. But in the contract template, we don't have any search filters for the activities. Therefore, it renders all contract records. **Solution:** Add the activity search filters for the contract template records. opw-5209691
Website translation mode now lets users edit regular translatable fields again, such as product names on translated pages. This also keeps menu item translation working, so editors can update website content more consistently across languages.
Original PR description
[FIX] html_builder, website: allow user to translate a field Steps to reproduce the problem: - With french installed on a website, go to `/fr/shop`. - Enter in translate mode. -> You can not edit product names. The problem is that since [1], regular fields are not translatable. This commit does two things: - It modifies the `o_editable_selectors` selector in edit mode to allow translation of regular fields. - Because we revert the logic of [1], the problem that was solved by this commit (translation of a mega menu item) still has to be fixed. To do so, the `o_editable` or `o_editable_attribute` is removed when setting the `data-oe-readonly` attribute on cascaded branded elements. The idea is to follow the same logic than in the `SetupEditorPlugin` where elements with the `data-oe-readonly` attribute are filtered before adding the `o_editable` class. task-5265949 [1]: https://github.com/odoo/odoo/commit/d4d428ff1d5be46135973aa806f206a1076bfcf7
8 changes
New functionality added to Odoo
This change adds a new EC Sales List report for Finnish businesses, along with the export file needed to submit it. It helps companies in Finland prepare and provide required EU sales reporting more easily.
Original PR description
The aim of this commit is adding the Finnish EC Sales List report. task-5126664 Forward-Port-Of: odoo/enterprise#95901
Enhancements to existing features
Finnish tax reporting now includes triangular taxes, which helps generate the EC Sales List more accurately. This improves compliance and reduces manual adjustments for businesses operating across EU borders.
Original PR description
The aim of this commit is adding the triangular taxes into the tax report to use it in EC Sales List report. task-5126664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229269
Resolved issues and error corrections
This fix removes an overly strict company check that blocked adding a user to a Sales Team when the team belonged to a company the user could access, but which was not their default company. It improves multi-company usability and prevents unnecessary errors when assigning team members.
Original PR description
### Steps to reproduce the issue: (Easier to reproduce client side with CRM installed) 0. Install crm 1. Create Second Company 2. Create New User with Current Company as Default Company and Second…
### Steps to reproduce the issue: (Easier to reproduce client side with CRM installed) 0. Install crm 1. Create Second Company 2. Create New User with Current Company as Default Company and Second Company in Allowed Companies 3. Create CRM Team belonging to Second Company 4. Add New User to Members of CRM Team 5. Receive error: > [New User] belongs to company [Current Company] and "Sales Team" (crm_team_id: [CRM Team]) belongs to another company. ### Explanation: `crm.team.member` is created when adding `res.users` to `crm.team.member_ids`. Contrary to `res.users`, a company_check is done when linking `crm.team` and `crm.team.member` together. `crm.team.member.company_id` is related to `user_id.company_id` and, in the case above, does not match `crm.team.company_id`, raising an error because of it. ### Fix reasoning: Removing restriction, as we want to avoid other multi-company issues by changing the behaviour. opw-4214192 --- @nd-dew note: Situation recap  So it was proposed to modify the field definition, seems to me that removing `check_company` from the field definition is a legal move, since it is an ORM level constraint (doesn't change db schema). However looking at the tests it seems like this is desired limitation. Note that https://github.com/odoo/odoo/pull/171079 introduced checking for allowed companies, but the **default company** still takes priority. Forward-Port-Of: odoo/odoo#189441
This fix ensures that when staff transfer, merge, link, or unlink tables, the kitchen preparation screens are updated right away. It also prevents duplicate preparation records when orders are merged or linked and some items are cancelled, helping keep POS and kitchen information consistent.
Original PR description
Task: [#5005179](https://www.odoo.com/odoo/1737/tasks/5005179) --- When executing table actions such as transfer, merge, link, or unlink, the related Preparation Displays (PDIS) were not being updated. This caused inconsistencies between the POS orders and the kitchen screens. Also, when merging or linking orders and cancelling some lines, a new `pdis_order` was created instead of reusing the existing one. This fix ensures that PDIS are correctly synchronized and notified on any table actions.
This fix keeps the kitchen preparation screens in sync when staff transfer, merge, link, or unlink tables in POS. It also prevents duplicate preparation records when orders are combined and some lines are cancelled, reducing mismatches between the cashier view and the kitchen display.
Original PR description
Task: [#5005179](https://www.odoo.com/odoo/1737/tasks/5005179) --- When executing table actions such as transfer, merge, link, or unlink, the related Preparation Displays (PDIS) were not being updated. This caused inconsistencies between the POS orders and the kitchen screens. Also, when merging or linking orders and cancelling some lines, a new `pdis_order` was created instead of reusing the existing one. This fix ensures that PDIS are correctly synchronized and notified on any table actions.
This change blocks live chat visitors from initiating calls, closing a gap in the server-side protection. It helps ensure only allowed users can start calls, improving control over customer interactions and avoiding unwanted call requests.
Original PR description
In [1], we fixed an issue where the start call button would be visible to portal partners. We do not want visitors to initiate calls on live chats. However, there also is a guard in the `rtc` controller which only checks that public users cannot start calls. The server code should also be adapted to properly ensure no live chat visitor can start a call. [1]: https://github.com/odoo/odoo/pull/236272 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
This fix restores the proper writable mode when validating Wi‑Fi settings. As a result, configured Wi‑Fi details are saved correctly and remain available after the device restarts.
Original PR description
In odoo/odoo#233813, the writable context was mistakenly removed. This commit adds it back to ensure Wi-Fi configuration is saved after reboot. Forward-Port-Of: odoo/odoo#234293
This update corrects an automated test so it matches how users actually change a product in the interface. As a result, the test now properly detects invalid event-related product settings and prevents false passes in simpler installations.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a minimal database with `event_product` installed; 2. run `:TestEventProduct.test_ensure_event_service_tracking`. Issue ----- > FAIL:…
Versions -------- - 18.0+ Steps ----- 1. Have a minimal database with `event_product` installed; 2. run `:TestEventProduct.test_ensure_event_service_tracking`. Issue ----- > FAIL: TestEventProduct.test_ensure_event_service_tracking > AssertionError: ValidationError not raised Cause ----- The test works as expected with `sale_project` installed due to a `write` override of `product.product`, setting the `service_tracking` to 'no' if `type` is no longer 'service': https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/sale_project/models/product_product.py#L25-L30 This change still occurs without `sale_project` installed, but via the `_compute_service_tracking` method defined in `product`: https://github.com/odoo/odoo/blob/dc57ea4d306f8745d37f2c5d2c3d3fa4bcaf7253/addons/product/models/product_template.py#L181-L183 As this value is set via a compute method instead of `write`, the `_check_event_ticket_service_tracking` method isn't triggered, and no error is raised. Solution -------- Simulate a front-end flow by changing the `type` to 'consu' on a product form. This way, the constraint method does get triggered as expected. runbot-234024 Forward-Port-Of: odoo/odoo#236045
3 changes
Resolved issues and error corrections
This fix makes the Timesheets stat button show the right total when teams use the Days/Half-days encoding method. It prevents inflated values from being displayed, so managers see accurate time summaries in team settings.
Original PR description
Steps to reproduce: -------------------- 1. Install helpdesk_timesheet 2. Create a new team with timesheets enabled 3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours) 4.…
Steps to reproduce: -------------------- 1. Install helpdesk_timesheet 2. Create a new team with timesheets enabled 3. Create a new ticket and add a timesheet line with some time (e.g., 20 hours) 4. Open the team’s settings and observe the Timesheets stat button 5. Go to Timesheets > Configuration > Settings 6. Set "Encoding method" to "Days/Half-days" 7. Reopen the team’s settings and observe the Timesheets stat button again Issue: ------ Incorrect value displayed in the Timesheets stat button. (e.g., 160 Days instead of 2.5 Days) Cause: ------ After commit d23ca81, the UoM model was restructured, changing how conversions between hours and days are computed. The field `factor_inv`, previously used in the computation of total_timesheet_time, was removed. Earlier, `factor_inv` handled this conversion correctly. After its removal, the computation now directly uses factor, which leads to incorrect values when converting to days. https://github.com/odoo/enterprise/blob/92bb923ffe185b7744adeadcc8f2972f9a64effb/helpdesk_timesheet/models/helpdesk_team.py#L32-L36 For ex: Consider unit_amount = 20 minutes: **Before** Case 1: Encoding method = Hours/Minutes (unit_amount_sum / product_uom.factor) * uom_team.factor (20 / 1) * 1 = 20 Hours --> CORRECT Case 2: Encoding method = Days/Half-days (unit_amount_sum / product_uom.factor) * uom_team.factor (20 / 1) * 8 = 160 Days --> INCORRECT **After** Encoding method = Days/Half-days (unit_amount_sum * (1.0 if helpdesk_ticket.encode_uom_in_days else product_uom_factor)) / uom_team.factor (20 * 1) / 8 = 2.5 Days --> CORRECT Reference: The [UoM’s factor ](https://github.com/odoo/odoo/blob/ca9df34f3a29796596f92e55647f61f95a95af52/addons/uom/data/uom_data.xml#L29-L37)has also been changed. **NOTE:** Before this change, when the user opened the timesheet sublist view in debug mode and clicked the View button, it opened the default form view of the `account.analytic.line` model instead of the intended timesheet form view. This allowed editing of the Unit of Measure (product_uom_id) field also. To prevent this, the form view reference has been explicitly specified, similar to the one used in the [Project module](https://github.com/odoo/odoo/blob/3f23bd9723d9065f17c1960d185d67a0a809a889/addons/hr_timesheet/views/project_task_views.xml#L41). Solution: ---------- This commit ensures accurate conversion of timesheet values between hours and days opw-5184077 Related community PR: https://github.com/odoo/odoo/pull/233803
This change makes the Belgian black box integration more tolerant of communication issues by retrying when the device returns invalid data or a negative acknowledgment. It also aligns the waiting time with the documented limit, which helps reduce failed transactions caused by brief device response problems.
Original PR description
Following documentation, max timeout should be 1.5s and we should retry 3 times on every bb NACK/invalid data. Forward-Port-Of: odoo/enterprise#99705
Opening the shop floor from a manufacturing order now takes users to the correct work center tied to that order, instead of relying on whichever work center was last used. This prevents the manufacturing order from appearing in the wrong place and makes returning to the shop floor app behave consistently.
Original PR description
Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key. BEFORE:…
Opening shop floor from MO smartbutton activates the WC "Overview". Subsequent opening of shopfloor app will also land on WC "Overview". Also removes an 'undefined' part of local storage key. BEFORE: Due to an oversight during this fix odoo/enterprise#93553, opening shop floor from MO smartbutton selects the WC from local storage (ie last clicked by user), with a filter for the current MO. (ie. when clicking Shopfloor smartbutton on an MO we can land on the wrong WC) NOW: Opening shop floor from MO smartbutton selects the WC "All MO" with a filter for the current MO. If we close shopfloor and come back to the shop floor app we land back on the "All MO" WC, which is the intended behaviour. Note: I did not rewrite tests I did here: https://github.com/odoo/enterprise/pull/93553/files#diff-2aa7dbd54334d280c72d91b7d472077aaae9af017408f1b0d71150bb16a022f4 as the setup is quite different in 18.0 (no access to the required stepUtils and the tour flow is quite different) task#4629641 Forward-Port-Of: odoo/enterprise#93841
28 changes
Enhancements to existing features
When a company installs a chart template from the SEPA region, the related ISO 20022 payment support is now installed automatically. This makes setup smoother and helps ensure the right payment features are available from the start.
Original PR description
This commit will allow to install account_iso20022 when installing a chart template from the SEPA zone. task-5163045
Resolved issues and error corrections
The VoIP keypad now correctly removes highlighted digits when using backspace, even if the selection starts at the first character. This restores expected editing behavior while keeping input handling safe and prevents users from being blocked by the earlier regression.
Original PR description
This commit fixes a regression introduced in commit [1] prevented deleting when a selection began at index 0; extend the guard so the numpad (keypad) backspace still removes the highlighted characters while keeping the cursor-safety logic. [1]: https://github.com/odoo/enterprise/commit/73b01fa5e1f56d4ab71d67760b15942fb2fa0e31 task-5217676 Forward-Port-Of: odoo/enterprise#99655 Forward-Port-Of: odoo/enterprise#99358
When a sales order’s pricelist is changed and prices are refreshed, optional products will now be recalculated correctly. This prevents optional items from keeping outdated prices, which helps avoid pricing inconsistencies for sales teams and customers.
Original PR description
### Steps to reproduce: - Create a sale order with a SOL and an optional product - Preview the sale order and add the optional product to the order - Go back to edit mode and change the pricelist -…
### Steps to reproduce: - Create a sale order with a SOL and an optional product - Preview the sale order and add the optional product to the order - Go back to edit mode and change the pricelist - Click on 'Update Prices' - Notice the optional product price won't change ### Cause: When updating the prices of the SOLs we filter some lines that we won't recompute. Upon this commit https://github.com/odoo-dev/odoo/commit/2d919694d5c9588e0644d5ba82b15b9d3f762373 we remove the optional products from the recordset that will get price recomputation. If sale_subscription is installed we will set the product's prices to 0 https://github.com/odoo/enterprise/blob/85e0689ba12442e22e83f3337749c7ad2eb9d7d8/sale_subscription/models/sale_order.py#L674 so the price of the 'Optional product' SOL will change but will be equal to 0 ### Fix: An exception for the filtering has been introduced as we will recompute the price of the optional products only if the pricelist is getting changed opw-5058609 Forward-Port-Of: odoo/odoo#234968 Forward-Port-Of: odoo/odoo#230053
When a vendor bill has only one related landed cost, clicking the Landed Costs button now opens that record directly instead of first showing a list. This removes an extra click and makes the workflow faster and smoother for users.
Original PR description
## Before this commit: When a user clicked the Landed Costs smart button on a vendor bill, even if there was only a single landed cost, the system opened the list view first. The user then had to click again to open the form view, which was unnecessary and inconvenient. ## After this commit: The system now opens the landed cost form view directly if only one record exists, avoiding the unnecessary step of displaying the list view. > Task-5231913 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update ensures chat sessions stay properly connected even when they are opened through alternate entry points, not just the usual sidebar or open actions. It helps prevent missed message updates in Discuss and Live Chat, improving reliability for users and support teams.
Original PR description
Discuss subscribes to channel the user is not a member of when it is displayed in the side bar or when `thread.open` is called. However, all flows are not covered. For example, chat hub opens chat windows without calling `thread.open`. So does the command palette. We shouldn't rely on specific flows, but instead detect when the correct conditions are met. This commit fixes this issue by adding a field on thread, that determines whether the subscription is required. When this field update, so does the bus subscription. 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 small dot shown on calendar events is now easier to see when an event is unpublished or hatched. The styling was also moved so it works consistently in related views, including Planning even when the Calendar app is not installed.
Original PR description
When pills are hatched (unpublished event) in the calendar view (eg. planning) the `o_event_dot` is barely visible. Additionally the styling to display the dot as outlined on hatched event is wrongly scoped in `/calendar` with the calendar status styling. It should be in the view instead. Otherwise, for the planning module which doesn't depend on calendar, the styling is not applied if calendar is not installed, rendering the filled dot. task-3916768 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235978 Forward-Port-Of: odoo/odoo#235286
This update fixes an error that could block adding a user to a sales team when the team belongs to another company the user is allowed to access. It now uses the user’s permitted companies instead of only their default company, which makes multi-company membership work as expected without changing the underlying company setup.
Original PR description
### Steps to reproduce the issue: (Easier to reproduce client side with CRM installed) 0. Install crm 1. Create Second Company 2. Create New User with Current Company as Default Company and Second…
### Steps to reproduce the issue: (Easier to reproduce client side with CRM installed) 0. Install crm 1. Create Second Company 2. Create New User with Current Company as Default Company and Second Company in Allowed Companies 3. Create CRM Team belonging to Second Company 4. Add New User to Members of CRM Team 5. Receive error: > [New User] belongs to company [Current Company] and "Sales Team" (crm_team_id: [CRM Team]) belongs to another company. ### Explanation: `crm.team.member` is created when adding `res.users` to `crm.team.member_ids`. Contrary to `res.users`, a company_check is done when linking `crm.team` and `crm.team.member` together. `crm.team.member.company_id` is related to `user_id.company_id` and, in the case above, does not match `crm.team.company_id`, raising an error because of it. ### Fix reasoning: Removing restriction, as we want to avoid other multi-company issues by changing the behaviour. opw-4214192 --- @nd-dew note: Situation recap  So it was proposed to modify the field definition, seems to me that removing `check_company` from the field definition is a legal move, since it is an ORM level constraint (doesn't change db schema). However looking at the tests it seems like this is desired limitation. Note that https://github.com/odoo/odoo/pull/171079 introduced checking for allowed companies, but the **default company** still takes priority. Forward-Port-Of: odoo/odoo#189441
Users can now mention any member of a group chat even when writing inside a thread. This removes a communication limitation and makes threaded discussions in chat behave as expected.
Original PR description
Before this commit, when inside a thread of a group chat, it would not be possible to mention channel members that are not inside said thread. Steps to reproduce: 1. Create group chat 2. Create a thread 3. Try to mention -> can only mention self This commit fixes the issue by: 1. In the `get_mention_suggestions_from_channel`: correctly adding in the store all partners inside the parent channel 2. In the suggestion service: taking the `channel_member_ids` from the `parent_channel_id` when present task-5233010 Forward-Port-Of: odoo/odoo#235998 Forward-Port-Of: odoo/odoo#234887
This fix prevents the website sitemap from crashing when a record does not have a last update date. If no date is available, the sitemap now skips that field and continues working normally, restoring the previous behavior.
Original PR description
In some cases, write_date can be Falsy, causing the sitemap to crash with: > '>' not supported between instances of 'datetime.datetime' and 'bool' Restore previous behavior, if there is no write_date, the lastmod key is not set.
The import screen now shows the same formatting options for files ending in either .csv or .CSV. This makes the import experience more consistent and avoids confusion for users uploading CSV files with uppercase extensions.
Original PR description
Before this fix, the import side panel displayed the formatting options only when the uploaded file had a lowercase .csv extension. Files with an uppercase .CSV extension could still be imported but did not show the format selection section, leading to inconsistent behavior. This commit updates the condition to perform a case-insensitive comparison on the file extension. Task-5145031 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236348 Forward-Port-Of: odoo/odoo#235061
This change updates the payment methods Odoo enables for Mollie so they match what Mollie actually supports by default. It also removes a payment method that Mollie is phasing out, reducing setup confusion and avoiding unavailable options for customers.
Original PR description
**[FIX] payment_mollie: remove iDEAL from the default payment methods** When a new Mollie account is created, it only accepts card payments out of the box. In Odoo, both the Cards and iDEAL payment methods were activated by default upon enabling the payment provider, while iDEAL required manual activation from Mollie's dashboard. --- **[FIX] payment_mollie: remove Sofort from the linked payment methods** See https://help.mollie.com/hc/en-us/articles/20904206772626-SOFORT-Deprecation-30-September-2024ard. Forward-Port-Of: odoo/odoo#236182 Forward-Port-Of: odoo/odoo#236044
Customers who place a takeout order through self-ordering will now receive the confirmation email as expected. The email is sent from the server when the order is created, which avoids the previous issue where disconnected customers could not trigger it.
Original PR description
When using the takeout preset with the self order, we're supposed to send a confirmation email to the customer. Currently, this mail does not get sent. Steps to reproduce: ------------------- * Open…
When using the takeout preset with the self order, we're supposed to send a confirmation email to the customer. Currently, this mail does not get sent. Steps to reproduce: ------------------- * Open the Restaurant config, make it only use the takeout preset (by default) and enable self ordering + QR * Log out * Open the mobile menu * Make an order * Fill out the information for takeout (slot, name, mail) and continue * Check the mails > Nothing being sent Cause: ------------ The email is supposed to be sent after entering the takeout informations and selecting the button "continue". https://github.com/odoo/odoo/blob/aec27a7b4fbf6826842e7b5945ef0d5670bc0603/addons/pos_self_order/static/src/app/pages/cart_page/cart_page.js#L131-L135 The call to the db is made here: https://github.com/odoo/odoo/blob/aec27a7b4fbf6826842e7b5945ef0d5670bc0603/addons/pos_self_order/static/src/app/pages/cart_page/cart_page.js#L156-L162 Which utlimately resolves in calling: https://github.com/odoo/odoo/blob/aec27a7b4fbf6826842e7b5945ef0d5670bc0603/addons/point_of_sale/static/src/app/services/data_service.js#L526 This uses the call_kw route which requires the user to be connected. https://github.com/odoo/odoo/blob/aec27a7b4fbf6826842e7b5945ef0d5670bc0603/addons/web/controllers/dataset.py#L28-L29 However the usecase we describe is mainly used by non connected users. If a user is not connected we will never call `action_send_self_order_receipt` which sends the email. Why the fix: ------------ We do not want to use a public route to send the email. What we want is to send the email directly from the backend when the order is created. In order to achieve this we need to send the email given by the customer when sending the order. To do that we need to override `serializeForORM` as the email is a computed field. Currently we cannot send the receipt by email as we cannot render it from the backend. This is currently a limitation but does not induce a stepback compared to using a public route as the route to send the email would usually be executed before the payment of the order, in which case we didn't sent a receipt. opw-5164546 Forward-Port-Of: odoo/odoo#232975
When a stock quantity is increased, Odoo now reserves from available inventory records first instead of creating a generic line with only product and location. This makes the additional quantity follow normal reservation rules, improving accuracy in stock and manufacturing operations.
Original PR description
Increasing the quantity of a stock move will create a move line with the same data as the stock move (location and product), no lot, nor package. This commit make the increase of quantity mimic the reservation process by getting first the available quants. The move line are then created accordingly. 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 website content generation runs into a known user-facing error, the system now records it as a warning instead of an error. This better matches the fact that users are already notified in the interface and avoids creating unnecessary error-level logs.
Original PR description
- Currently, we log an error whenever an error occurs during content generation for any webpage. - However, it is a non-blocking error so it can be safely converted to a `_logger.warning`, as we already notify user about the error through a notification [1]. - Additionally, the errors caught here will be all UserErrors so no need to log another error, so we log a warning instead. - This commit converts the `_logger.error` into `_logger.warning`. [1]: https://github.com/odoo/enterprise/blob/b001e9cc2af0f800e2a7965b61aa9b9c5bd4e89e/ai_website/static/src/components/dialog/add_page_dialog.js#L74-L80 sentry-6974000714
This change removes a Northern Ireland business-to-business tax setup that was no longer needed. When applicable, it now uses the standard domestic tax setup instead, reducing complexity and keeping tax configuration aligned.
Original PR description
After more verification, we found that the Northern Ireland B2B Fiscal Position was unnecessary and could be replaced by the domestic one. So this commit removes this fiscal position and replaces it if needed by the domestic one.
When support users open a visitor’s contact from live chat, the contact now opens in a way that keeps the navigation trail intact. This makes it easier to go back to the original chat session and continue working without losing context.
Original PR description
Previously, when we click on the "View Contact" button, the corresponding partner's form is opened but via a href link which does not preserve the breadcrumb. Purpose of this commit is to use the action service instead, to open the form view of the partner, which will preserve the breadcrumb so that navigating back to that session is handy. Part of Task-5190261
When the quantity of a stock move is increased, the system now updates the existing reservation correctly instead of behaving like a new line was created. This keeps stock handling more accurate and prevents test and workflow mismatches in barcode-related processes.
Original PR description
Increasing the quantity of a stock move will create a move line with the same data as the stock move (location and product), no lot, nor package. This commit correct some tests values because increasing the quantity on a stock move will increase the existing move line quantity instead of creating a new one.
This fix ensures the salary configurator applies the correct ATN-related payroll rules even when the payslip date falls outside the employee’s contract period. As a result, salary estimates and payroll calculations are more accurate and consistent.
Original PR description
The payslip date is in the current month of when the salary configurator is used which may be different from the date on the version. That would lead to have the payslip outside of the contracts date and not take the ATN into account.
This change removes a printer setting that was causing PDF labels to print misaligned on Zebra printers from Windows IoT devices. It restores the expected label layout so printed labels are accurate again.
Original PR description
Adding the argument "-dPDFFitPage" in the printer driver for the windows IoT broke the alignment when printing PDF labels on Zebra printers. Issue introduced in #232866 opw-5220275 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#236228 Forward-Port-Of: odoo/odoo#236041
This change prevents upgrade failures when creating timesheet entries from helpdesk tickets. It ensures the correct analytic account is kept so the system no longer triggers the “At least one analytic account must be set” validation error.
Original PR description
When creating an analytic line from a helpdesk ticket, we assigned the account_id from the project's account_id during the upgrade. However, in the standard code, the account_id is later overridden and updated from ticket.analytic_account_id, which is null. As a result, the constraint "At least one analytic account must be set" is triggered. see: https://github.com/odoo/enterprise/blob/dcfef2cc462631f376a596a7c85ae483826835ad/helpdesk_timesheet/models/account_analytic_line.py#L119 Multiple upgrade request failed due to this. Forward-Port-Of: odoo/enterprise#99201
This change reduces memory usage when opening the "To Receive" view for warehouses with many transfers and quality checks. It prevents the system from loading unnecessary data into memory, avoiding crashes and improving stability for large operations.
Original PR description
The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive"…
The fields `quality_check_todo` and `quality_check_fail` are calculated for stock.picking records by iterating all checks of a stock.picking. This causes a problem when clicking the "To Receive" button for a warehouse in the inventory app, in case there are many transfers each with many quality checks. The function will default to loading all data associated with quality checks in memory through field prefetching. However, since quality checks have too much data (particularly because of the HTML fields) associated with them, the cache can quickly bloat causing an OOM error and crashing the worker. This PR disables the prefetcher for quality checks before iterating them, preventing this issue from happening since we only need very light fields in the loop. For a specific customer (opw-5025162), this was the case. Benchmarks: | No. stock.picking | avg no. quality checks | peak memory before | peak memory after | | ----------------- | ---------------------- | ------------------ | ----------------- | | 25 | 20 | 2771 mb | 235 mb | opw-5025162 Forward-Port-Of: odoo/enterprise#95568
Users can now mark manufacturing work orders as done even when the related project’s accounting settings would previously block the action. This prevents an access error from stopping production progress in common manufacturing and timesheet setups.
Original PR description
[FIX] project_mrp_workorder_account: allow WO completion Steps to reproduce: - Enable Analytic Accounting. - Assign a project A to User A. - Create user B with Manufacturing User + Timesheet User…
[FIX] project_mrp_workorder_account: allow WO completion
Steps to reproduce:
- Enable Analytic Accounting.
- Assign a project A to User A.
- Create user B with Manufacturing User + Timesheet User rights.
- Create a storable product “P1” with the following BoM:
- Component: 1 unit of C1
- Workorder: Operation of 60 minutes
- Project: Project A
- As user B:
- Create a mo to produce one unit of “P1”
- confirm the MO
- start the workorder and try to mark it as done.
Issue:
An access error is raised when creating analytic lines:
"Sorry 'user B' doesn't have read access to account.analytic.line"
Explanation:
Since the project is assigned to Mitchell Admin and not to Marc Demo,
the access rule below applies:
https://github.com/odoo/odoo/blob/19.0/addons/hr_timesheet/security/hr_timesheet_security.xml#L50-L62
Because Marc Demo belongs to the "Timesheet User" group but not to
the "Accounting" group, he lacks the required access rights,
which triggers the analytic line read restriction.
opw-5262213This update corrects how the salary contract module retrieves the employee work-time rate. It now uses the proper stored field, which prevents errors and ensures the displayed calculations are based on the right information.
Original PR description
The function _get_work_time_rate doesn't exist, but the information we need is in the field work_time_rate.
This update fixes an issue where filtering replenishment records with a zero ‘To Order’ value could still show items that actually needed ordering. It makes the displayed value and search results consistent, so users can trust the filter results in Inventory replenishment.
Original PR description
**Issue** In replenishment, filtering with `to_order = 0` does not correctly exclude records where `to_order != 0`. **Steps to reproduce** 1. Go to Inventory > Operations > Procurement >…
**Issue** In replenishment, filtering with `to_order = 0` does not correctly exclude records where `to_order != 0`. **Steps to reproduce** 1. Go to Inventory > Operations > Procurement > Replenishment 2. Create a replenishment with a forecast quantity smaller than the min and max quantity (without editing the To Order) 3. Apply a custom filter `to_order = 0` → Records with non-zero `to_order` are incorrectly included **Cause** `qty_to_order` was split into `qty_to_order_computed` and `qty_to_order_manual` in [this commit](https://github.com/odoo/odoo/commit/156bed3f430d706e13822bbd95d91c8dfd3ea42d#diff-0eb18a8d7773b5f99b402392188594178c3ba2004e4bcab26dbc84b1c8d7256a). In the [`_search_qty_to_order` method](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L338), all records with `qty_to_order_manual = 0` are included. Since `qty_to_order_manual` defaults to 0 when untouched by the user, this causes incorrect results. Additionally, [`to_order`](https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_orderpoint.py#L323) displays `qty_to_order_computed` if `qty_to_order_manual = 0`, creating inconsistency. **Solution** Fix the inconsistency by ignoring `qty_to_order_manual` when searching for zero `to_order` values. opw-5150643 Forward-Port-Of: odoo/odoo#234908
This change includes the database identifier with SMS requests sent to Odoo’s cloud service. It helps support teams more quickly identify and troubleshoot issues for customers when a problem occurs.
Original PR description
Send the db_uuid to IAP such that we can more easily debug and support our users in case of a problem. task-none Forward-Port-Of: odoo/odoo#235540 Forward-Port-Of: odoo/odoo#233912
This fix prevents a permission error that could block manufacturing users from marking a work order as done when the related project uses timesheets and analytic accounting. It improves the completion flow so production can continue without requiring extra accounting access.
Original PR description
Steps to reproduce:
- Enable Analytic Accounting.
- Assign a project A to User A.
- Create user B with Manufacturing User + Timesheet User rights.
- Create a storable product “P1” with the following BoM:
- Component: 1 unit of C1
- Workorder: Operation of 60 minutes
- Project: Project A
- As user B:
- Create a mo to produce one unit of “P1”
- confirm the MO
- start the workorder and try to mark it as done.
Issue:
An access error is raised when creating analytic lines:
"Sorry 'user B' doesn't have read access to account.analytic.line"
Explanation:
Since the project is assigned to Mitchell Admin and not to Marc Demo,
the access rule below applies:
https://github.com/odoo/odoo/blob/19.0/addons/hr_timesheet/security/hr_timesheet_security.xml#L50-L62
Because Marc Demo belongs to the "Timesheet User" group but not to
the "Accounting" group, he lacks the required access rights,
which triggers the analytic line read restriction.
opw-5262213This update corrects how certain accounting template records are labeled behind the scenes. It helps ensure those records are associated with the right module, reducing the risk of setup or update issues for related accounting features.
Original PR description
Trying to fix the account_asset data records having `account` as a module while targeting the `account_asset` model that belongs to the `account_asset` model.
This change removes a unit test that belonged in a different module and depended on Enterprise-only fields. Removing it prevents test suite failures during builds and avoids keeping an invalid test in the standard codebase until it can be reintroduced in the right place.
Original PR description
The unit test `test_can_reset_deferred_invoice()` has several issues. 1. It should be in the `account_audit_trail` module, as the test requires this module. [Unit test documentation: modules](https://www.odoo.com/documentation/19.0/developer/tutorials/unit_tests.html#modules). 2. The test references fields from the Enterprise module `account_accountant`, `account.move.line.deferred_start_date` and `account.move.line.deferred_end_date`. This causes build tests to fail. As such, the test should be removed now and replaced later if necessary. Fixes [PR 235223](https://github.com/odoo/odoo/pull/235223) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235813
8 changes
Enhancements to existing features
This update clears existing UrbanPiper menu links and rebuilds them with a fresh synchronization. It helps keep the menu data aligned between Odoo and UrbanPiper, reducing mismatches after changes.
Original PR description
Following this commit: - Flush out all existing UrbanPiper product menu linkages and performs a fresh menu sync. task-5231247
Resolved issues and error corrections
This fixes an issue where some actions embedded in a document folder could disappear from the folder’s action list, even though they were still attached to the folder. As a result, users can now find and remove these actions through the interface as expected.
Original PR description
### ISSUE Certain embedded actions inside a folder may not appear in the folder’s server actions list (accessible via the gear icon), making them impossible to find or delete through the interface. This occurs because documents.document.get_documents_actions applies overly broad filtering that removes all child server actions, regardless of whether they are embedded in the folder. As a result, if two embedded actions are created in a folder and one is later set as a child of the other, the embedded child action disappears from the visible list but remains embedded in the folder, leaving no way to remove it from the UI. ### SOLUTION The method has been updated to exclude only non-embedded child actions. Embedded child actions are now preserved and correctly displayed in the folder’s actions list, allowing them to be managed and deleted as expected. opw-5213881
The point of sale now loads only draft delivery orders when a session starts, instead of loading every delivery order. This reduces slowdowns and helps the POS open more quickly. The delivery button warning was also cleaned up to improve system stability and reduce console noise.
Original PR description
Before this commit:
---
- The POS loaded all delivery orders (including paid ones) when starting a session, which caused significant slowdowns.
- The delivery button component was missing `static props = {}`, which produced a console warning.
After this commit:
---
- The POS now loads only *draft* delivery orders, improving performance.
- Added `static props = {}` to the DeliveryButton component to remove the console warning.
task-5343700This update fixes an issue that could cause an error when reopening a page that contains a Vimeo video block. It ensures the editor can recognize the selected video element correctly, so users can replace or edit videos without the page crashing.
Original PR description
Steps to reproduce: =================== 1- Website app > Open any page in Edit mode. 2- Drag a Video block into the page. 3- Paste a Vimeo video URL in the dialog and save. 4- Save the page, then…
Steps to reproduce:
===================
1- Website app > Open any page in Edit mode.
2- Drag a Video block into the page.
3- Paste a Vimeo video URL in the dialog and save.
4- Save the page, then re-open it in Edit mode.
-> traceback
Cause:
======
The Wysiwyg "openMediaDialog" passes the selected media DOM node as "media" to the MediaDialog.
The MediaDialog forwards that value as "media" prop to VideoSelector. VideoSelector declared "media" as "{ type: Object, optional: true }". Owl validates "type: Object" as a plain object, not as any "typeof object".
DOM elements such as HTMLImageElement do not pass this plain object check, so Owl raises an error.
Solution:
=========
Relax the "media" prop type in VideoSelector so DOM nodes are accepted. In web_editor VideoSelector, change the "media" prop to "{ optional: true }".
In html_editor VideoSelector, also keep "media" declared as "{ optional: true }".
opw-5239889
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis change prevents an error that could occur when a manufacturing order line is left without a product and the schedule date is updated. It helps users avoid interruptions while editing manufacturing orders with incomplete line information.
Original PR description
The error arises when the user removes the product name from add a line and change the `Schedule Date`. Steps to reproduce: --- - Install `MRP` - Create a New MO - Add a product and confirm it - Add a product from add a line and remove the product name, and change the `Schedule Date` Traceback: --- `ValueError: Expected singleton: uom.uom()` `AssertionError: precision_rounding must be positive, got 0.0(v18.0)` When a move line has no `product_id`, its Unit of Measure (UoM) is also empty. Changing the date triggers computation, which causes an error due to these missing values. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This change corrects an automated test for subscription order lines so it matches the actual product name and description format. It helps prevent false test failures and keeps future changes from being blocked by an incorrect expectation.
Original PR description
In the test "test_subscription_order_line_description", assertEqual compares name field with just the description of the product. The name field includes the name of the product, new line "\n", and the description of the product. So, we fix it by including the name of the product followed by the new line followed by the description of the product in the second value of the self.assertEqual(). This fix was done because the test was failing for the PR "https://github.com/odoo/odoo/pull/233884" opw-5266849
Miscellaneous changes
The aim of this commit is updating the POT file as we forgot to do it in this commit [[1]]. We also translate the Business ID term for the correct one. no task id [1]: https://github.com/odoo/odoo/commit/7ef02a48f3c93cb8aca9337a27c3c87636fb03a0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Original PR description
The aim of this commit is updating the POT file as we forgot to do it in this commit [[1]]. We also translate the Business ID term for the correct one. no task id [1]: https://github.com/odoo/odoo/commit/7ef02a48f3c93cb8aca9337a27c3c87636fb03a0 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The aim of this commit is updating the POT file as we forgot to do it in this commit [[1]]. We also translate report column names in the PO files as we have official translation for it. This commit also disables the translation on the TXT EC sales report. no task id [1]: https://github.com/odoo/enterprise/commit/4887ed53d3a22fdcd766ab0ae77da7cb0498e5a3
Original PR description
The aim of this commit is updating the POT file as we forgot to do it in this commit [[1]]. We also translate report column names in the PO files as we have official translation for it. This commit also disables the translation on the TXT EC sales report. no task id [1]: https://github.com/odoo/enterprise/commit/4887ed53d3a22fdcd766ab0ae77da7cb0498e5a3
6 changes
Resolved issues and error corrections
This fix removes an error that prevented users from generating a debit note from an existing credit note. It makes the correction flow work as expected, especially for localizations that rely on debit and credit notes to adjust posted invoices.
Original PR description
### 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…
### 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. 1. Install the Argentine localization 2. Create an invoice and post it 3. From the invoice using the wizard create a credit note and post it. 4. From the credit note open the wizard to create a debit note. 5. 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. Adhoc tiket 69428 - 69854 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents a crash that could happen when the same serial number was reserved on more than one rental delivery. It improves the reliability of rental order processing and avoids errors when checking whether a reserved item is still available.
Original PR description
Steps to reproduce: 1. Go to Rental module > Configuration > Enable Rental Transfer 2. Create a product and Update quantity by assigning "By Unique Serial Number" 3. Create a rental order 4. Unhide…
Steps to reproduce: 1. Go to Rental module > Configuration > Enable Rental Transfer 2. Create a product and Update quantity by assigning "By Unique Serial Number" 3. Create a rental order 4. Unhide the "Reserved Lot" field, select the lot created earlier, and confirm 5. Open the Delivery(Stat button), assign lots to both deliveries 6. Create a second rental order (same or different user), assign the same lot, confirm, and process delivery 7. Create a third rental order, enter the same reserved lot → traceback occurs Issue: - Traceback with error `ValueError: Expected singleton: stock.move(88, 90)`. Cause: - The compute method `_compute_available_reserved_lots` accessed `move_id.date_deadline` directly, assuming a singleton. When multiple stock moves existed for the same lot, it triggered a singleton error. - When the same lot is linked to more than one delivery, the system crashed when checking available reserved lot. Solution: - Handled multiple stock.move.line records per lot by iterating over them instead of assuming a singleton. - Replaced direct access to move_id.date_deadline with an any() check to safely evaluate deadlines. - This prevents singleton errors when the same lot is linked to multiple deliveries and ensures correct availability calculation. opw-4963263
This update prevents receipt registration errors with some Swedish blackbox devices. The system now checks which protocol version the device supports before sending commands, so it only uses features the device can handle.
Original PR description
The serial protocol used with the Swedish blackbox has 2 versions, with v2 adding some more commands. Before this commit, we assumed that the blackbox was compatible with v2, causing an 'unknown message type' error if it only supported v1. After this commit, we check the protocol version of the blackbox when we initialise the driver, so that we only send compatible commands when we register a receipt. opw-5077448
This change makes timesheet entries linked to a reversed invoice editable again. It fixes a case where users could not update recorded hours even though the original invoice had been reversed, which helps keep billing and time tracking accurate.
Original PR description
**Issue:** Timesheet entries linked to reversed invoices are uneditable. **Steps to reproduce:** - Create a service product invoiced by timesheets, and create a project & task. - In Sales, create a new quotation with the product. - Confirm the quotation, click on the task, and create a timesheet entry. - Create an invoice from the quotation. - Confirm the invoice, add a credit note, and reverse the invoice. - Go to the reversed invoice and access the timesheet through recorded hours. the timesheet entry is uneditable, even though the invoice is reversed. opw-4633121 Forward-Port-Of: odoo/odoo#201921
When users search on website pages, the system now checks whether the current page exists for that search. If the user is beyond the last available page, they are automatically redirected to the final valid page so results and pagination display correctly.
Original PR description
Scenario: - enable website_studio - go to contact -> open studio -> website - add a listing and open it on website - go to page 2 and search a specific terms with less than 20 results Result: we see "5 results" in the search bar, but no result are shown and the pager is hidden. Cause: the pager is hidden since there is only one page, and we are currently displaying the records of page 2 that do not exist. Fix: if we detect that we are on a page over the last page, redirect to the last page. Eg. if there is 2 pages and we are in page 500, redirect to page 2. opw-5008556
This update prevents users from manually changing the reply address on email templates unless it is intentionally configured. It helps keep customer replies linked to the right records and reduces email delivery problems caused by incorrect addresses.
Original PR description
Prior to this commit, the `reply_to` field on email templates (`mail.template`) was fully editable by users. This frequently led to misconfigurations where users would manually enter incorrect email…
Prior to this commit, the `reply_to` field on email templates (`mail.template`) was fully editable by users. This frequently led to misconfigurations where users would manually enter incorrect email addresses, bypassing the system's default catchall behavior. This resulted in: 1. Lost communication history: Replies were sent to private emails instead of routing back to the document chatter. 2. Deliverability issues: Manual values often failed SPF/DMARC checks, causing emails to bounce or land in spam. This commit addresses the issue by: 1. Modifying the `mail.template` form view to hide the `reply_to` field when it is not set (`invisible="not reply_to"`). This aligns the form behavior with the preview wizard and prevents users from accidentally overriding the system default on standard templates. 2. Setting the `reply_to` field to `readonly="1"` on the technical email message view to prevent manual tampering with emails already in the queue. opw-4894020 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr