Daily updates from Odoo
Tuesday, February 24, 2026
59 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue where consolidated invoices were incorrectly listing orders. The fix ensures that all orders from POS sessions are accurately included when generating a consolidated invoice. This improves the reliability of financial reporting and simplifies invoice reconciliation.
Original PR description
Step to Reproduce: * Install l10n_my_edi_pos and switch to that company * Configure two POS sessions (POS 1 and POS 2) * Create orders as follows: POS 1: * 2 uninvoiced orders * 1 invoiced order *…
Step to Reproduce: * Install l10n_my_edi_pos and switch to that company * Configure two POS sessions (POS 1 and POS 2) * Create orders as follows: POS 1: * 2 uninvoiced orders * 1 invoiced order * Close POS 1 POS 2: * 1 uninvoiced order * 1 invoiced order * Close POS 2 Reopen POS 1: * 1 uninvoiced order * Close POS 1 Reopen POS 2: * 1 uninvoiced order Close POS 2 * Go to Orders → Consolidated Invoice * Create a consolidated invoice using the correct date range Observation: * Two documents are created * No. of orders linked to each document are incorrect Cause: * `_split_pos_orders_in_lines` overwrites entries in the `lines_per_config` dictionary * Previous orders for the same config are lost Fix: * Extend the existing recordset in `lines_per_config` instead of overwriting it Before <img width="1230" height="231" alt="order consolidation bug" src="https://github.com/user-attachments/assets/26657f34-998e-41c4-a68a-0939cbe6de1d" /> After <img width="1265" height="206" alt="consolidated order fixed" src="https://github.com/user-attachments/assets/7c703416-ac3b-412e-bb28-0d6f73fa25f2" /> opw-5904420 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248402
This update resolves a problem where products weren't loading correctly when switching between companies within the Point of Sale (POS) loyalty system. The fix prevents errors that occurred when trying to load products directly, ensuring all products are accessible regardless of the company setting. This improves the reliability of the POS loyalty functionality.
Original PR description
Step to reproduce - install `pos_loyalty` and have two companies - for this record: `loyalty.gift_card_product_50` set company_id = company1 - switch to company b and start pos Observation: - no products are loaded Cause: - `browse()` was used to load records `gift_card_product_50` and `ewallet_product_50` - when any of them is restricted on one company it fails to load whole model Fix: - Instead of directly loading them, we use `search()` to avoid `AccessError` so that rest of the products can be loaded. - Gift card is still not shown as expected opw-5449466 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244912
This update fixes a security vulnerability that allowed internal Odoo users to access invoice download links (JSON/XML files). The change now restricts access to these links to only authorized invoicing users, preventing unauthorized access to sensitive data. This ensures data privacy and compliance.
Original PR description
Steps to reproduce: 1. Create an Invoice 2. Send for EDI (should in error, easy way to do it in local turn off the internet) 3. Turn Debug mode 4. Click Download (A new window with URL with will be open) showing the JSON/XML 5. Change Marc Demo (or any user) being internal user without Invoicing rights 6. That user can access the JSON/XML with that particular URL After this commit- We make sure only Invoicing Users can download the JSON/Export task-5481114 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243257
This update fixes an issue where work entries created from attendance archives were incorrectly including existing entries on the same day, leading to inaccurate work duration tracking. The change ensures that work entries accurately reflect the correct duration for each date, resolving a potential discrepancy in employee time records.
Original PR description
Current behavior: work entries created from attendance archive "included" existing work entries on the same day, even when they do not overlap in time frame. This happens because the attendance intervals are created from records in self, not all attendances on a given day Expected behavior: work entries should reflect the correct duration for a date. opw-5499002 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#107704
This update resolves a crash in the Delivery Slip report when printed in Spanish. The issue stemmed from the report using English labels for key fields, leading to errors. The fix now correctly targets technical fields for accurate reporting in all supported languages.
Original PR description
Steps to reproduce: 1. Switch the partner language to Spanish. 2. Print the Delivery Slip. 3. The report crashes due to translated XPath anchors. Cause: XPath targeted hardcoded English strings 'Tracking Number' and 'Total Weight'. Solution: Target technical fields o.carrier_tracking_ref and o.shipping_weight instead of text labels. opw-5493498 Forward-Port-Of: odoo/odoo#248679
This update fixes an issue where changes to order quantities on the ticket screen weren't being saved. The fix ensures that modifying a loaded order, such as increasing the quantity of a product, accurately reflects the updated order details. This improves the accuracy of order processing and prevents discrepancies between the ticket and the actual order.
Original PR description
Currently, modifying a loaded order (e.g., changing product quantity) does not save the changes, and the old order without modifications is shown on the ticket screen. ### **Steps to Reproduce:** 1)…
Currently, modifying a loaded order (e.g., changing product quantity) does not save the changes, and the old order without modifications is shown on the ticket screen. ### **Steps to Reproduce:** 1) Install the POS Restaurant app with demo data. 2) Open a Restaurant Session. 3) Click on 'Register' to create a Direct Sale. 4) Add a product (e.g., Water with Qty 2) and a customer (e.g., 'Billy Fox'). 5) Click on 'Orders' from the navbar and load the recently created order. 6) Update the quantity of Water from 2 to 5 and click on 'Orders' again. ### **Error:** The quantity of Water is not updated, the order line still shows a quantity of 2. Ref video: https://drive.google.com/file/d/1XR5W5Klyyll3KujirKb3UuAELjMcA7yD/view ### **Root Cause:** Clicking on 'Orders' calls `syncAllOrders` (see [1]), which is responsible for updating the orders. However, `this.getPendingOrder()` returns null in this scenario, causing the orders array to be empty and the function to return early without syncing. ### **Fix:** Override `updateSelectedOrderline` in `OrderSummary`. This method is invoked whenever the Numpad modifies an orderline. By calling `addPendingOrder` within this method, we ensure that Numpad modifications are correctly registered. This allows `syncAllOrders` to properly sync the updated order with the server when navigating away. [1]- https://github.com/odoo/odoo/blob/7fd5f90fe8fce4de49ec10c683f92e7a3557981a/addons/point_of_sale/static/src/app/services/pos_store.js#L1485-L1512 opw-5405402 Forward-Port-Of: odoo/odoo#240366
This update corrects a problem in the payment dashboard query that was causing performance issues and errors. By aligning the query with previous behavior, the issue of unnecessary joins and ambiguous column errors has been resolved. This ensures the dashboard functions correctly and efficiently.
Original PR description
In v19 `_where_calc` was merged[^1] into `_search`, where `bypass_access=True` replicates the previous behavior. The dashboard query for payments to check was executed with the default…
In v19 `_where_calc` was merged[^1] into `_search`, where `bypass_access=True` replicates the previous behavior.
The dashboard query for payments to check was executed with the default `bypass_access=False`, causing record rules to be applied. This introduced extra joins (e.g. on `res_company`) and resulted in ambiguous column errors during aggregation.
```py
File "/home/odoo/src/odoo/19.0/addons/account/models/account_journal_dashboard.py", line 414, in _get_journal_dashboard_data_batched
self._fill_sale_purchase_dashboard_data(dashboard_data)
File "/home/odoo/src/odoo/19.0/addons/account/models/account_journal_dashboard.py", line 600, in _fill_sale_purchase_dashboard_data
self.env.cr.execute(sql)
File "/home/odoo/src/odoo/19.0/odoo/tests/test_cursor.py", line 79, in execute
return self._cursor.execute(*args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 433, in execute
self._obj.execute(query, params)
psycopg2.errors.AmbiguousColumn: column reference "currency_id" is ambiguous
LINE 1: SELECT journal_id, company_id, currency_id AS currency, invo...
^
```
Set `bypass_access=True` to match the original `_where_calc` behavior and avoid unnecessary joins.
opw-5951694
upg-3902613
[^1]: https://github.com/odoo/odoo/commit/6f95152b00df75f503f445e3b77b891b5f83c055
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#250003This update resolves an issue where users without access to a company's organization chart would encounter an error when trying to view employees in that company. The fix involves adding a necessary security check (sudo) to ensure proper access control across multiple companies within the organization chart. This ensures all users can view the correct organizational structure.
Original PR description
## Short functional explanation of the error When an employee A tries to access to the page of another employee B, if that employee has a manager belonging to a company to which employee A doesn't…
## Short functional explanation of the error When an employee A tries to access to the page of another employee B, if that employee has a manager belonging to a company to which employee A doesn't have access, the employee A will see an AccessError, even if employee A can have access to the page of employee B. ## Reproduction Steps 1. Create a second company to your database. Let's call these companies Company A and Company B. 2. Select Company A as your main company, but make sure Company B is also selected. 3. Create an Employee A. 4. Select Company B as tour main company; but make sure Company A is also selected. 5. Create an Employee B who has A as manager. 6. Create Employee C who has B as manager. 7. With a user only having access to Company B, log in and try to access Employee C's page. ### Expected behavior Employee's C page loads correctly. ### Unexpected behavior An access error occurs. ## Origin of the issue A sudo() was missing. __ opw-5910036 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247817
This update removes a problematic printing library, `python-escpos`, from the IoT drivers. While this library offered features like QR codes, it caused frequent printer issues and reliability problems. Switching to a simpler CUPS-based approach prioritizes stable printing performance, even if it means losing some advanced features.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/108109 The `python-escpos` library was being used for compatible printers since it allowed easier use of features such as QR codes, as well as…
Enterprise PR: https://github.com/odoo/enterprise/pull/108109 The `python-escpos` library was being used for compatible printers since it allowed easier use of features such as QR codes, as well as letting us query the status of the printer to check if it was e.g. out of paper. However, using this library has complicated the code and caused many reliability problems when using USB printers. In particular, the printer could print garbage and then become stuck until it was restarted. This seems to be due to a multi-threading issue, as the print is interrupted half-way through when the `USBInterface` checks for devices. Since the added value is small compared to the extra maintenance and reliability costs, the `python-escpos` library is being removed in favour just using CUPS for all print jobs, as was the case in 18.0. This means we will no longer have a QR code on the status receipt or a warning when the paper is running low, but these are unimportant compared to reliability. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249819
This update fixes an issue where deactivated tax rates were still being included in vendor payment calculations. The fix ensures that inactive tax rates are no longer considered when generating payments, improving the accuracy of financial reporting. This change was implemented by adding a filter to the tax retrieval process.
Original PR description
# How to reproduce - Install the l10n_ar_withholding module - Pick a Vendor and add a Purchase Withholding tax in the accounting tab - Go into configuration and disable that tax - Create a Vendor Bill with that Vendor - Confirm the bill and create a payment # The problem The deactivated tax is still computed in the payment # Why The function that fetches the withholding taxes does not check if the taxes are active or not # The fix I though of 2 solution : - Add an override to remove the taxes from the Vendor when they are deactivated - Add a filter to the fetch function to check if the taxes are active I chose the 2nd solution as it is the least invasive one. opw-5917257 Forward-Port-Of: odoo/odoo#247831
This update resolves an error that occurred when generating the XML FatturaPA for invoices in Italian companies. The issue stemmed from a mismatch in how data was being returned, leading to a technical error. This fix ensures invoices can be correctly downloaded in the required XML format.
Original PR description
When downloading the XML FatturaPA of an invoice in an Italian company, A traceback will generate. Steps to reproduce the error: - Install ``l10n_it_edi`` module with demo data - Switch to IT Company…
When downloading the XML FatturaPA of an invoice in an Italian company, A traceback will generate. Steps to reproduce the error: - Install ``l10n_it_edi`` module with demo data - Switch to IT Company - Create a new invoice > Customer: IT Company > Add a product > Confirm > Send > Send - Actions > Print > XML FatturaPA Traceback: ```py TypeError: string indices must be integers, not 'str' ``` In commit [1], ``_get_invoice_legal_documents`` was updated to return a list instead of a dictionary. However, the ``l10n_it_edi`` module was not adapted accordingly and still returns a dictionary at [2]. If ``_get_invoice_legal_documents`` returns a dictionary instead of a list, the following logic incorrectly iterates over dictionary key which leads to the above traceback. https://github.com/odoo/odoo/blob/a74e7e2fa96a56737e9105f3b54d5db2d9c2dba3/addons/account/controllers/download_docs.py#L24-L26 [1]: https://github.com/odoo/odoo/commit/90dcd6cfe904974dfa077c2d8d9e168a09eeecf9 [2]: https://github.com/odoo/odoo/blob/a74e7e2fa96a56737e9105f3b54d5db2d9c2dba3/addons/l10n_it_edi/models/account_move.py#L399-L403 sentry-7272542156 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes issues with downloading Activitywatch, specifically adding a link for the Linux (Ubuntu) build and correcting the existing Windows link. The update also improves how the system detects the user's operating system, ensuring a smoother download experience.
Original PR description
This PR adds the download link for the Ubuntu build of activitywatch, fixes the windows link, and fixes the platform detection.
This update resolves an issue preventing users from sharing document templates with read-only fields. By separating validation logic and removing unnecessary security checks, shared templates now function as expected, improving the usability of the document sharing feature. This ensures a smoother experience for users collaborating on shared documents.
Original PR description
Currently, attempting to share a document template that contains readonly fields fails. When `_populate_constant_items` calls `_fill` to pre-fill these fields, `_fill` aggressively checks that the request state is 'sent'. Since shared links create requests in the 'shared' state, the transaction crashes. Additionally, `_fill` throws a `UserError` if not called with `sudo`, which inappropriately treats a developer/privilege error as an end-user error. This commit resolves the issue by separating concerns: - Moves the `state == 'sent'` validation out of the `_fill` helper and into `_sign` (the caller responsible for actual user signatures). - Removes the artificial `sudo` check in `_fill`, relying instead on standard ORM Access Errors to block unauthorized database writes. (only in master) Task: 5949263
This update resolves a technical issue causing emails sent by Odoo to be rejected by some email servers (like Yahoo). The fix prevents the system from folding subject headers, ensuring they comply with strict email standards and improving email delivery rates. This ensures our communications are reliably received by our customers.
Original PR description
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554…
…r rejections Yahoo and other strict mail servers reject emails with folded Subject headers containing RFC 2047 encoded-words when the folding occurs at inappropriate positions, resulting in "554 Invalid Subject header" errors. The root cause is in Python's stdlib (bpo-144156). In an ideal world we would be fixing the issue there, but experience tells us that they are very slow to fix bugs / merge PRs in the email module, and even when they do they usually don't backport the fixes in the python versions we use. This commit extends the existing IdentificationFieldsNoFoldPolicy to also prevent Subject header folding, keeping long subjects on a single line (up to 998 characters per RFC 5322 "MUST" requirement, from the 98 "SHOULD" limit). Since at it, include the other "user defined" smtp headers: to, from, ... The solution follows the same pattern already established for identification headers (Message-ID, In-Reply-To, References) where Odoo prevents folding to avoid MTAs rewriting these critical headers and breaking email threading. See-also: #243119 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 update adds a test to ensure the employee onboarding flow within the HR module functions correctly. It's a follow-up to a previous change designed to improve the stability and reliability of the employee onboarding process. This test helps ensure a smoother experience for new employees.
Original PR description
This commit adds a test for the following related PR: https://github.com/odoo/enterprise/pull/104888 task-5779779 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 update corrects a restriction preventing HR officers from creating new employees in Belgium. The fix utilizes 'sudo' to grant access to a specific field, allowing the correct creation process to proceed. This ensures all users can properly manage employee records.
Original PR description
Steps to reproduce: - Install l10n_be_hr_payroll - Have a user with only HR officer rights - Try to create a new employee with that user (in BE) - You have an access error on the field l10n_be_resident_situation The field `l10n_be_resident_situation` has the HR Payroll officer group. This field is used on the inverse of the is_non_resident field, which is accessible to HR officers. This commit fixes the issue by using sudo to read the field's value. task-5779779
This update resolves a technical issue related to the accurate calculation and reporting of cycle transportation declarations within the Belgian payroll module. The fix ensures compliance with Belgian tax regulations by correcting a data processing error, improving the reliability of payroll reports for businesses operating in Belgium.
Original PR description
Forward-Port-Of: odoo/enterprise#108069
This update resolves an issue where certain website snippets were unintentionally nested within other snippets, causing display inconsistencies. The changes prevent these specific snippets – related to popups, navigation tabs, and content tables – from being dropped into other snippets, ensuring a cleaner and more reliable website experience. This improves the overall presentation and stability of the website.
Original PR description
This commit prevents the following snippets to be dropped inside other snippets like tabs, toc, and more: - s_popup - s_newsletter_subscribe_popup - s_newsletter_benefits_popup - s_tabs - s_table_of_content - s_faq_horizontal task-5439635 Forward-Port-Of: odoo/odoo#242035
This update resolves an issue where the payroll sheet calculation would fail if there were minor warnings during processing. The change allows the sheet to be generated even with warnings, ensuring payroll data is always available. This improves the reliability of payroll reporting.
Original PR description
Revert https://github.com/odoo/enterprise/pull/104137 Forward-Port-Of: odoo/enterprise#108340
This update resolves a problem where test data wasn't correctly applied during the development of the HR expense reporting feature. The team identified that changes made in a previous commit weren't being recognized by the tests. The fix ensures the tests run accurately using a default test company, maintaining the stability of the expense reporting system.
Original PR description
When adding the tests, the changes in d15faf0 were not taken into account. The tests wouldn't fail as the `hr_expense_stripe_demo` module would contain the necessary data runbot-241008 Forward-Port-Of: odoo/enterprise#108307
This update fixes an issue where the default putaway strategy wasn't consistently applied in stock transfers. The change ensures that the putaway strategy defaults to the child location of a stock move, improving the accuracy and efficiency of stock management processes. This resolves a potential misdirection of materials.
Original PR description
Steps to reproduce ----- - Enable locations & by products - Create 4 locations - View A of type view (parent: Stock) - View B of type view (parent: Stock) - Storage A of type internal location…
Steps to reproduce ----- - Enable locations & by products - Create 4 locations - View A of type view (parent: Stock) - View B of type view (parent: Stock) - Storage A of type internal location (parent: View A) - Storage B of type internal location (parent: View B) - Create a "Manufacture to A" route - Rule 1: Manufacture, Stock -> Stock - Rule 2: Push To, Internal Transfer, Stock -> View A - Create a "By Products to B" route - Rule 1: Push To, Internal Transfer, Stock -> View B - Create a "Bonus" product with route "By Products to B" - Create a "Finished" product with route "Manufacture to A" - BoM with "Bonus" as by product - Create a MO for Finished, and produce it - Open the linked transfers' list view - Open the "Bonus" transfer > "Destination Location" states View B - Open the line's details (hamburger button) > "Store To" states View A/Storage A Cause ----- When retrieving the location in https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L280-L282 we pass `locations` as a context key. The problem is that `locations` contains the childs of **all** of the SMLs' locations https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_move_line.py#L260 This means that, in `_get_putaway_strategy`, when no `putaway_location` is found, we end up defaulting to the first element of the list https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L370-L371 which might not be a child of the location. Solution ----- By removing the context key, locations get populated as such https://github.com/odoo/odoo/blob/26dbbdaf460a91ef4b33392c27a28951d5de2c57/addons/stock/models/stock_location.py#L328-L330 This is ok because we know the call to `_get_putaway_strategy` is made on a single record (`sml.move_id.location_dest_id`) so the default will correctly be a child of said location. ----- Ticket: opw-5359945 Forward-Port-Of: odoo/odoo#249708 Forward-Port-Of: odoo/odoo#247403
This update resolves an issue preventing proper testing of the Arabic VAT (AREDI) functionality. By using 'sudo()' when writing test data, the system now bypasses permission restrictions, ensuring reliable validation in testing environments. This improves the stability and accuracy of the AREDI module.
Original PR description
This pull request makes a minor update to the `_dummy_afip_validation` method in `account_move.py`, improving its reliability for testing environments. * Testing reliability: The method now uses `sudo()` when writing dummy AFIP fields, ensuring that the operation succeeds even if the current user lacks write permissions. Without this fix, if the user doesn't belong to group "base system", it won't be able to validate invoices in testing environment. <img width="1258" height="454" alt="image" src="https://github.com/user-attachments/assets/522bfd9d-33be-4bcd-a60b-ef4c09a8e0d6" /> Forward-Port-Of: odoo/enterprise#107937
This update resolves an issue where tasks remained linked to sales orders even after sales order items were removed. Previously, this prevented users from properly billing tasks. Now, tasks are only unlinked from sales orders when there are no associated sales order items and the task isn't a field service task, ensuring accurate billing and task management.
Original PR description
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be…
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one. **Steps to produce:** * Install Sales, Project * Products > Virtual Home Staging > Create On Order > Project and Task * Create and confirm quotation with that product. * Tasks > Empty the Sale Order Item Field **Observed Behavior:** * Sale Order is still linked to the task despite sale order line has been unlinked from that task. **Root cause:** * Compute method [1] only detaches the sale order if the customer has been changed. **Solution:** * Only detach the sale order when there are no sale order items and the record is not a field service task. * Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed. [1]: https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 [2]: https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194 Related Enterprise PR: https://github.com/odoo/enterprise/pull/103487 opw-5215989 Forward-Port-Of: odoo/odoo#249574 Forward-Port-Of: odoo/odoo#241446
This update resolves an issue where tasks remained linked to sales orders even without a related sales order item. Now, users can unlink tasks from sales orders, preventing billing issues and simplifying task management. This ensures tasks can be properly detached and re-linked when needed.
Original PR description
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be…
Currently, a task remains linked to its original sales order even when it has no sales order item. This prevents users to not bill a task and temporarily detach it from a sales order until it can be linked to a new one. **Steps to produce:** * Install Sales, Project * Products > Virtual Home Staging > Create On Order > Project and Task * Create and confirm quotation with that product. * Tasks > Empty Sale Order Item Field **Observed Behavior:** * Sale Order is still linked to the task despite sale order line has been unlinked from that task. **Root cause:** * Compute method [1] only detaches the sale order if the customer has been changed. **Solution:** * Only detach the sale order when there are no sale order items and the record is not a field service task. * Field service tasks should always keep the sale order linked so materials can still be added to the existing sale order, even when the task is non-billable (i.e., no sale order line is linked). This logic is handled by the compute override at [2], which reassigns the sale order when needed. [1]: https://github.com/odoo/odoo/blob/3f4e45ecaca46a98c904536658728a1f1571bdbd/addons/sale_project/models/project.py#L916-L935 [2] https://github.com/odoo/enterprise/blob/6658581828dcdc43ffc5823814a05cb936cd0500/industry_fsm_sale/models/project_task.py#L178-L194 Related community PR: https://github.com/odoo/odoo/pull/241446 opw-5215989 Forward-Port-Of: odoo/enterprise#107990 Forward-Port-Of: odoo/enterprise#103487
The display of available rental products on the website was incorrect when 'continue selling' was enabled. This fix ensures that the quantity shown accurately reflects the available rental units, considering the selected renting period. This improvement prevents customers from seeing inaccurate stock levels and improves the overall e-commerce experience.
Original PR description
**Issue**: The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled. **Steps to reproduce**: - Create a rental product…
**Issue**: The displayed available quantity on the ecommerce product page is incorrect for rental products when "continue selling" is enabled. **Steps to reproduce**: - Create a rental product tracked in stock with a quantity of 5 - Enable "continue selling" and "show available quantity below 10" - Go to the ecommerce page of this product - Rent 3 units for a given period, confirm and pay - Return to the ecommerce product page -> Whatever the selected renting period, the displayed quantity is always 2 **Cause**: The website displays `free_qty`: https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/static/src/xml/website_sale_stock_renting_product_availability.xml#L15 `free_qty` is computed in: https://github.com/odoo-dev/odoo/blob/0935829ddaecd7b2b6eec9157f8f790b546d06ff/addons/website_sale_stock/models/product_template.py#L36 which leads to: https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L10 and ultimately relies on: https://github.com/odoo/odoo/blob/37bf1703c7478a3010b71cd60bbb43b3295a605b/addons/stock/models/product.py#L213 This computation does not take the selected renting period into account. There is a period-aware computation here: https://github.com/odoo/enterprise/blob/41c729e22c5fd1abb690f8335e933f793be0b319/website_sale_stock_renting/models/website.py#L15C17-L21C1 but it is only triggered when `product.allow_out_of_stock_order` is False (i.e. when "continue selling" is disabled). opw-[5354163](https://www.odoo.com/web#id=5354163&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#104686 Forward-Port-Of: odoo/enterprise#103333
This update corrects a reporting issue with Italian invoices (l10n_it) by ensuring the total invoice amount (`ImportoTotaleDocumento`) is always displayed in EUR, as required by Italian tax regulations. This change aligns with government guidelines and prevents potential discrepancies in financial reporting.
Original PR description
With an `l10n_it` company: - Create an invoice in a foreign currency and export the XML. In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to…
With an `l10n_it` company: - Create an invoice in a foreign currency and export the XML. In the XML, the field `ImportoTotaleDocumento` is expressed in the invoice currency, while `Divisa` is set to the company currency. `ImportoTotaleDocumento` must be expressed in EUR, as stated in the following document: https://www.agenziaentrate.gov.it/portale/documents/20143/0/10FAQ+pubblicate+il+19+luglio+2019+(aggiornate+il+1+luglio+2021).pdf/6e8acb34-b7c5-730e-6a39-79c0a296e02b > L'art. 21, comma 2, lettera l) del d.P.R. n. 633/72 specifica che > “aliquota, ammontare dell'imposta e dell'imponibile con arrotondamento al centesimo di euro”. > Conseguentemente, se la fattura è emessa da soggetti residenti o stabiliti il codice da inserire nel campo `<Divisa>` > deve essere obbligatoriamente “EUR”. > Article 21, paragraph 2, letter (l) of Presidential Decree No. 633/72 specifies that > “the tax rate, the amount of the tax, and the taxable amount must be stated with rounding to the euro cent.” > Consequently, if the invoice is issued by resident or established taxpayers, the code to be entered in the `<Divisa>` > field must mandatorily be “EUR”. As a result, we now use the **company currency amount** for the `ImportoTotaleDocumento` field (assuming the company currency is always EUR for `l10n_it`). Ticket [link](https://www.odoo.com/odoo/project.task/5913088) opw-5913088 Forward-Port-Of: odoo/odoo#249272 Forward-Port-Of: odoo/odoo#247537
This update fixes a bug where empty loyalty cards were created when not all loyalty programs applied points to an order. Now, loyalty cards are only created when points are actually earned, reducing unnecessary record creation and improving data cleanliness. This improves the efficiency of our loyalty program tracking.
Original PR description
Currently, when you have multiple loyalty program but only 1 applies points on the current order, the other will have a loyalty card created with 0 points. steps to reproduce: ------------------- * Create a loyalty program giving you 1 point per $ on product 1 * Create a loyalty program giving you 1 point per § on product 2 * Make a pos order with just product 1, add a customer * Check the programs in the backend > Observation, a loyalty card with 0 points was create for the second loyalty program Why the fix: ------------ This creates a lot of unecessary records. We now only create cards where there are points or when there 0 points because a reward has been applied, thus keeping history. opw-5405109 Forward-Port-Of: odoo/odoo#248653 Forward-Port-Of: odoo/odoo#244254
This update fixes an issue where location, notes, and privacy settings weren't being properly carried over from the quick event creation form to the full event details view. The change ensures that all entered information is accurately reflected when editing events, improving data consistency and user workflow. This was a simple fix to a data loss issue.
Original PR description
Steps to produce: --- - Install `calendar` module. - Go to `Calendar and create a new event using quick create`. - Set Location and Notes and other values. - Click `More options`. Issue: --- - When…
Steps to produce: --- - Install `calendar` module. - Go to `Calendar and create a new event using quick create`. - Set Location and Notes and other values. - Click `More options`. Issue: --- - When the full form view opens, the `Location, Notes and Privacy` fields are empty, even though they were filled in the quick-create dialog. Root cause: --- - At [1], [2] & [3], `Location, Notes and Privacy` values are correctly stored in the location, notes and privacy fields respectively. - When opening the full form, default values are built via `getDefaultValuesFromRecord`. - And here at [4], location,notes and privacy are missing from the `QUICK_CREATE_CALENDAR_EVENT_FIELDS`. - As a result, these fields are skipped and not passed through the context, causing data loss. Solution: --- - Add the location and privacy fields to the `QUICK_CREATE_CALENDAR_EVENT_FIELDS` dictionary so they are included when generating default values for the full form view. - And replace `description` with `notes`. Note: --- - As this is a small and simple case, the test has not been added to avoid unnecessary overhead. [1]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L378-L381 [2]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L404-L407 [3]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/views/calendar_views.xml#L400-L403 [4]: https://github.com/odoo/odoo/blob/7abd7ba2f38fdb1953c39fd3693f012c2ad1b497/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L7-L17 opw-5504553 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247117
This update fixes an issue where receipts printed with the l10n_gcc_pos module were displaying English text instead of Arabic. The fix adds Arabic translations to the receipt files, ensuring that all text is displayed in the user's chosen language – mirroring the behavior of other Odoo receipts.
Original PR description
Problem: When printing a receipt in arabic using the l10n_gcc_pos module, some of the text is in English. Cause: Translation is not enabled for the module and the text is written in English only in the receipts XML. Solution: Add the arabic translations of texts to the receipts XML and choose the display language based on the user's language (same behaviour in other receipts). Steps to reproduce: - Install l10n_gcc_pos module - Activate and choose Arabic as the language - Open Point of Sale and validate an order - See how some text (specifically "Tax Invoice" and "Simplified Tax Invoice") are printed in English although the rest of the receipt is printed in Arabic. opw-5501464 Forward-Port-Of: odoo/odoo#245795
This update addresses usability issues in the mobile version of the bank reconciliation widget. Specifically, the layout has been adjusted to better accommodate the smaller screen size, and some secondary buttons have been moved to a dropdown menu to maximize screen space. This enhances the user experience on mobile devices.
Original PR description
The mobile style on bank rec widget is a bit buggy, this commit adds few improvements: 1 - When in mobile view, chatter is shown on the right (like in desktop view), but the screen is way too tight to display both chatter and st_lines at the same time. Solution: Display the chatter at the bottom of the screen. 2 - If the screen is too tight to show 2 primary buttons (Example: Set Partner & Set Account), We remove the "Set " on the buttons label to save some space. 3 - In tablet view, we don't have enought place to show all the secondary buttons we are showing in desktop view. This commit removes the reco model secondary buttons. (Now accessible in the dropdown menu) task-5114831 Forward-Port-Of: odoo/enterprise#96103
This update adds the municipalities of Guatemala to Odoo, resolving a previous limitation where only departments were available. This enhancement ensures correct address data for Guatemalan businesses, aligning with best practices and improving consistency with other localized versions of Odoo.
Original PR description
Impacted versions: - 19.0 Steps to reproduce: 1. Install module l10n_gt 2. Go to Contacts > City field 3. Select country Guatemala Current behavior: - Only departments are available, municipalities are missing. Expected behavior: - Municipalities of Guatemala are available in res.city, linked to their respective departments (res.country.state). - Each municipality includes its zipcode and translation in es_GT. Explanation: This PR extends the localization for Guatemala by adding official municipalities and their zip codes to res.city. It improves consistency with other localizations (e.g. Brazil) and allows proper address management for Guatemalan companies. Forward-Port-Of: odoo/odoo#247719
This update fixes an issue where message actions in the meeting chat were taking up excessive space, making message bubbles appear too small. The change adds necessary padding to the "..." button, ensuring a cleaner and more efficient display of message actions. This improves the overall user experience within the meeting chat.
Original PR description
Before this commit, message actions in meeting chat were taking too much space, reducing the size of message bubbles. This happens because the "..." button had no explicit padding and thus fall-backed to the default padding of a button, which is way too much. This commit fixes the issue by providing the proper padding to message actions in the inline presentation, which is necessarily with a tiny padding. Before / After <img width="297" height="565" alt="Screenshot 2026-02-20 at 18 38 05" src="https://github.com/user-attachments/assets/580bd0ff-ff3a-4830-bac4-6764e78863e2" /> <img width="296" height="562" alt="Screenshot 2026-02-20 at 18 37 41" src="https://github.com/user-attachments/assets/2f3eda5e-4016-402f-9450-157fe7be69bc" />
This update fixes a bug where overtime calculations were incorrect for employees in timezones like India (Asia/Kolkata). The change ensures that shifts crossing midnight are accurately calculated, preventing overpayment for overtime hours. It includes updated code, tests, and a revised interval calculation for improved accuracy.
Original PR description
**Description of the issue/feature this PR addresses:** Fix the overtime calculation logic for resources in timezones ahead of UTC (specifically Asia/Kolkata +05:30) where shifts crossing midnight incorrectly attribute the second half of the shift as overtime. **Current behavior before PR:** shifts crossing midnight incorrectly attribute the second half of the shift as overtime. **Desired behavior after PR is merged:** . Fix version_periods_by_employee interval . Update get_dates() method to return date objects . Add corresponding tests coverage task-5949757 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where Odoo incorrectly defaulted to USD as the Stripe currency, causing potential blocking for EU companies with non-USD currencies like EUR. The change switches the default to EUR, ensuring accurate Stripe integration for all users.
Original PR description
Right now, we need to guess the correct stripe currency for the stripe account depending on the country, we used the USD as an ultimate fallback But, the USD currency is easy to guess, where the EUR is way harder (it may not be the company currency). So, it is too error-prone to set the USD as the default fallback, and it can lead to EU companies being blocked as their stripe currency is the wrong one. We therefore switch it to EUR. opw-5393508 opw-5913327 opw-5953025 Forward-Port-Of: odoo/enterprise#108293
This update fixes a bug where the Odoo website would crash when a breadcrumb was displayed without the standard header. The change ensures the breadcrumb interaction works correctly regardless of whether the header is enabled or disabled, improving website stability and user experience.
Original PR description
When the header is disabled globally via the Theme tab in edit mode, navigating to a page containing a breadcrumb caused a crash. The PageBreadcrumb interaction did not handle the case where no header was present on the page. This commit updates the interaction to safely handle pages without a header. Task-ID: 5927177 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 update fixes an issue where the 'is_company' field wasn't accurately determined in Odoo's localization modules (l10n_br and l10n_ec). Now, Brazilian CNPJ and Ecuadorian RUC identification types correctly mark partners as companies, and foreign partners with VATs are also recognized as companies. This ensures accurate reporting and functionality for international business operations.
Original PR description
`is_company` was not correctly computed in some localization modules. This commit adds a compute method for: - l10n_br*: Company if identification type is CNPJ - l10n_ec*: Company if identification type is RUC For foreign partners (country ≠ BR/EC), a partner is considered a company if a VAT is provided. Follow-up of: https://github.com/odoo/odoo/pull/211043 Task-5947797
This update corrects a bug where the system incorrectly identified companies in Brazil and Ecuador. Now, the system accurately determines if a partner is a company based on their identification type (CNPJ or RUC in those countries) or if a VAT is provided for other countries. This ensures accurate reporting and accounting.
Original PR description
`is_company` was not correctly computed in some localization modules. This commit adds a compute method for: - l10n_br*: Company if identification type is CNPJ - l10n_ec*: Company if identification type is RUC For foreign partners (country ≠ BR/EC), a partner is considered a company if a VAT is provided. Follow-up of: https://github.com/odoo/enterprise/pull/86089 Task-5947797
This update resolves an issue where signature requests would fail with error messages due to a missing link to an employee offer. The fix ensures that signature requests are properly validated, preventing redirection errors and date validation issues. This improves the user experience for employees signing contracts.
Original PR description
Steps to reproduce: 1- On an employee page, create a new signature request for a document through the gear icon 2- Log in with the employee (ex. Marc Demo) and sign the contract 3- It will be signed but you will still get an <error 404 not found> page as it redirects to an offer that does not exist 4- Log in with the admin again to counter sign the document 5- You will get an error saying contract end date cannot be before contract start date Cause of the bug: We don't have an offer linked to the document we're signing. We can test this with the demo employee_contract.pdf or Employee Termination.pdf. The logic inside the sign() function will try to update the employee's version with fields from the offer which we don't have as it assumes this is a new offer. Fix done: Check if we have an offer linked to this sign request at first, if not return the default behavior that validates the signature. task-5423393
This update resolves an issue where a misleading warning appeared on payslips, even when employee wages were correctly calculated. The fix corrects a technical error in how the system checked net wages, ensuring the warning only appears when a payslip genuinely has a negative or zero net wage. This improves the accuracy and clarity of payroll reporting.
Original PR description
Steps to Reproduce: 1. Generate payslips for a batch of employees (e.g., Employee A and Employee B). 2. Ensure the last processed payslip (Employee B) has a negative net wage or is uncomputed (net…
Steps to Reproduce: 1. Generate payslips for a batch of employees (e.g., Employee A and Employee B). 2. Ensure the last processed payslip (Employee B) has a negative net wage or is uncomputed (net wage 0.0). 3. Ensure Employee A has a valid, positive net wage. 4. Open the payslip for Employee A. Issue: Employee A displays the warning "The net pay for this payslip is zero or negative," even though their net wage is positive. This occurred because the lambda filter used the `slip` variable from the outer loop scope instead of the iterator, causing the last record's net wage to determine the warning for the entire batch. Additionally, uncomputed payslips (which have no lines) default to a net wage of 0.0, which triggered the warning condition prematurely. Expected Behavior: The warning should only appear if the specific payslip being checked has a negative or zero net wage. Furthermore, the warning should be suppressed if the payslip lines have not yet been computed. Additionally, added a test to check the message is not displayed if we don't have net salary, and appears if the net is indeed negative. task-5484107
This update fixes a bug where users could accidentally create duplicate lines within Point of Sale orders. Previously, a refreshed page might send redundant requests, leading to multiple entries for the same item. Now, the system checks if a line already exists and updates it instead, ensuring data accuracy and a smoother user experience.
Original PR description
Before this commit, it could happen that a user send a request to the backend to create a pos.order.line that already exists because it didn't know it was already synced for some reason (the page was reloaded before getting the response and the frontend was then relying on indexedDB for example). It would then send a create command and we would have multiple lines with the same values. We have a constraint that usually works but for people where the bug happened before the constraint was created, the constraint would not be created and so the bug could still happen We now prevent that by changing the create command into an update command if the line to create already exists by comparing its uuid to the uuids of the lines related to the order. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249109
This update resolves an issue in Odoo 19.0 where uploading encrypted KSeF certificates caused server crashes. The fix allows users to correctly configure KSeF authentication using encrypted private keys by adding a password argument to the key loading process. This ensures KSeF functionality is reliably accessible.
Original PR description
In Odoo 19.0 (Master), the handling of KSeF certificates introduced an issue where uploading an encrypted private key caused a server crash, blocking the configuration of KSeF. This functionality worked correctly in v18 (where keys were often unencrypted). The `XadesSigner` class was not designed to accept a password argument. The `serialization.load_pem_private_key` method would fail with a `TypeError` because the password was not passed to the underlying Updated the `XadesSigner.__init__` method to accept a `private_key_password` argument. Passed this password correctly to `serialization.load_pem_private_key`. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248423
This update fixes an issue where users could add more than the available quantity of products to their cart when using the Click & Collect feature. The change removes a previous workaround that allowed this behavior, ensuring accurate inventory tracking and a better user experience. This resolves a potential over-ordering scenario.
Original PR description
Versions -------- - 19.0+ Steps ----- 1. Enable click and collect 2. Add a product with tracked inventory 3. Set the quantity on hand 4. Uncheck "Sell when Out-of-stock" 5. Try to add to cart more…
Versions
--------
- 19.0+
Steps
-----
1. Enable click and collect
2. Add a product with tracked inventory
3. Set the quantity on hand
4. Uncheck "Sell when Out-of-stock"
5. Try to add to cart more than the quantity on hand on the product page
- note that you are only allowed to add up to the quantity on hand
6. Try to add to cart more than the quantity on hand from the shop page by hovering over the product and clicking the cart icon
- note that you can add to cart more than the quantity on hand
7. Try to go to the cart page and adjust the quantity of the product
- note that it is reset to the quantity on hand and you're prevented from exceeding it
Issue
-----
You shouldn't be able to add to cart more than the quantity on hand of a product when you have "Sell when Out-of-stock" disabled. Especially since you can't do that from the product or cart page, and adjusting the extra quantity from the cart page leads it to reset.
Cause
-----
When you enable click and collect, it disables the check for quantity when adding items to cart. This was originally done because otherwise you had no way of adding items to cart in case there was a quantity available for pickup from shop but not available for delivery. This has changed since the introduction of the widget on the product page that allows you to select a store to pickup from in that case.
Solution
--------
Remove the code that disables checking for quantity when adding to cart when click to collect is installed.
opw-5449451
Forward-Port-Of: odoo/odoo#242864This update resolves an issue where the 'typing' indicator on chat channels remained visible indefinitely. The fix ensures that timeout expiration is correctly triggered when a user starts typing, regardless of timestamp duplication, improving the chat experience for users.
Original PR description
Typing expiration was indirectly tied to typing timestamp updates. Typing timestamps are second-precision, so two consecutive typing events can carry the same timestamp value. In that case, the timestamp field may not be considered updated on the client. The expiration timeout is then not re-armed even though typing is set to true. When that happens, the typing indicator can remain visible indefinitely unless an explicit "stop typing" event is received. This change makes timeout registration depend on typing state updates directly. Expiration is always scheduled when typing becomes active, regardless of timestamp equality. [task-4922630](https://www.odoo.com/odoo/project/1519/tasks/4922630) Forward-Port-Of: odoo/odoo#249917 Forward-Port-Of: odoo/odoo#249796
This update resolves an issue where a payment QR code remained visible on the customer display after an order was completed. The fix clears data related to the QR code when an order is finalized, ensuring a cleaner user experience. This improves the overall customer flow and prevents unnecessary visual clutter.
Original PR description
Steps: --- - Configure online payment on the POS configuration. - Open a POS session and the customer display. - Add a product and an online payment line. - Validate the order and complete the payment via QR code. Issue: --- - The order is finalized, but the payment QR code remains visible on the customer display. - The QR popup must be closed manually every time. Cause: --- - The customer display popup lifecycle depends on `onlinePaymentData`. - This data was not cleared when the order was finalized. Fix: --- - Clear `onlinePaymentData` when the order is completed. task-5502344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250102 Forward-Port-Of: odoo/odoo#244991
This update resolves an issue where the order of columns within the add snippet dialog was incorrect when using languages with different text directions (RTL/LTR). The fix ensures that the column order aligns with the backend language, improving usability for users with various language settings. This ensures a consistent and intuitive user experience.
Original PR description
After the accessibility improvement in [9ae02d8], snippets previews within the add snippet dialog are tabable. It reveals an issue with the order of the columns depending on the interface language:…
After the accessibility improvement in [9ae02d8], snippets previews within the add snippet dialog are tabable. It reveals an issue with the order of the columns depending on the interface language: when the backend language and the frontend language are not read in the same direction (RTL / LTR), the frontend language is taken to display the previews (see [f9c77de]). This is the right approach to show the snippets themselves, but the order of the columns should be done according to the backend language, which is the one that gives the instructions for the overall UI. To reproduce: - Set the admin's language to arabic - Clear the cache and refresh your page - Edit and open the add snippet dialog - Navigate with Tab => The 1st focused snippet is in the wrong column compared with the rest of the UI. [9ae02d8]: https://github.com/odoo/odoo/commit/9ae02d80894d4043e49d8e2cad068f8018e6f113 [f9c77de]: https://github.com/odoo/odoo/commit/f9c77de84aa6ea705e5d3f129328fb2199103b9a task-5109547 Forward-Port-Of: odoo/odoo#228414
This update ensures inactive taxes are accurately shown in fiscal position mappings, resolving a previous display issue. Previously, inactive taxes weren't consistently visible in key views. The change adds necessary context to the fiscal position action to ensure correct tax representation.
Original PR description
Observed issue: inactive taxes are shown in "Replaces" `original_tax_ids` field if the form view of a tax is opened through "Configuration"->"Taxes", but not shown under "Replaces" in a fiscal position tree view, nor are they shown in the same "Replaces" field of the tax form view when opened from the fiscal position tree view. Cause: the fiscal position link calls `action_open_related_taxes` on partner (path `/account.tax/[id]`), while the "Configuration"->"Taxes" calls `action_tax_form` on tax (path `/taxes/[id]`), which has additional context element `'active_test': False` among others. Solution: adding the context to the fiscal position action produces the desired behavior, but it might break something else as it affects the whole view. task-5917667 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247787
This update ensures that when settling invoices quickly through the product screen (fast payment), the system now correctly creates a 'pay later' payment line alongside the fast payment line, balancing the transaction. This was previously missed during a recent update to support both payment screen and product screen validation flows.
Original PR description
Steps to reproduce ------------------ 1. Install `pos_settle_due` 2. Enable "One-Click Payment" from the configs, and make sure it has some valid payment methods (Cash, Card, etc). 3. Open PoS, and…
Steps to reproduce ------------------ 1. Install `pos_settle_due` 2. Enable "One-Click Payment" from the configs, and make sure it has some valid payment methods (Cash, Card, etc). 3. Open PoS, and click "Settle Invoices" for a client having a "Total Due" > 0 4. Select the invoice(s) 5. Fast settle the invoice by directly paying on the product screen, using one of the fast payment methods on the bottom. -> The order is payed, however, it only has the fast payment line, while it should also have an additional equivalent "pay later" line, with a negative amount, balancing the amount payed with the fast payment method. Why the issue ------------- If we settled this invoice from the payment page, this issue does not happen, i.e. an equivalent "pay later" payment line is created. That additional "pay later" line is created when calling the `validateOrder` method on the `payment_screen`, which in `pos_settle_due`, is overriden to also add the "pay later" payment lines under certain conditions. After introducing the "One-Click Payment" feature in #216523, we needed to be able to validate the order in two different places: 1. On the payment screen, that was already taken care of, by the method `validateOrder` mentioned just above, that is normal validation. 2. On the products screen, when using fast payment, that is fast validation. For that reason, the validation code has been moved from the payment screen to the class `OrderPaymentValidation` which will be used by the two flow: the normal validation and the fast validation. However, we have forgot to move the `pos_settle_due` specific validation code from payment_screen to the new `OrderPaymentValidation`, hence, the `pos_settle_due` validation that creates the "pay later" PL is only executed from the payment_screen, never from fast validation. The fix ------- Now, we move the `pos_settle_due` validation code from `payment_screen` to an override of `OrderPaymentValidation` so it's executed when for both normal and fast validation. Notes ----- - We keep the methods in `payment_screen` for backward compatibility, they will be removed in master. - We replace the usage of `props.isDepositOrder` in the `payment_screen` with `order.is_settling_account`, as they will have both the same value, but `order.is_settling_account` is available on the order, so it can be used for both normal and fast flows, while `props.isDepositOrder` was only available in the payment screen during normal valuation. On master, we can remove the prop `isDepositOrder` in favor of `order.is_settling_account === true`. opw-5488587 Forward-Port-Of: odoo/enterprise#105660
This update fixes an issue where the order of selection options in sign templates was being lost after saving. The change ensures that user-defined option sequences are consistently preserved, preventing confusion and ensuring data integrity. This improves the user experience when creating and managing sign templates.
Original PR description
Steps to reproduce: 1. Open a Sign template. 2. Drag a 'Selection' field onto the document. 3. In the popover, type options in a specific order (e.g., Delta, Alpha, Beta). 4. Click save. 5. Re-open or inspect the data 6. observe the order is scrambled based on Database ID. Cause: The Python method used `list(set())` which is an unordered collection, losing the user's input sequence. Furthermore, the final `search().ids` call returned records sorted by primary key (ID) rather than the provided list order. Solution: Replace `set()` with `dict.fromkeys()` to deduplicate while preserving input order. opw-5896373 Forward-Port-Of: odoo/enterprise#108380 Forward-Port-Of: odoo/enterprise#107175
This update corrects a validation issue with invoices generated using the facturae module for Spanish e-Facturae. Previously, the system was generating XML files with excessive decimal places (up to 8), leading to validation errors. This change ensures that all currency amounts, specifically for invoices in Euros, are rounded to two decimal places as required by Spanish regulations, resolving the validation problem.
Original PR description
Steps to reproduce: - Have facturae modules installed - Generate invoice with any amount - Send to Facturae Issue: Resulting XML has 8 digits after the decimal point on several fields, such as unit…
Steps to reproduce: - Have facturae modules installed - Generate invoice with any amount - Send to Facturae Issue: Resulting XML has 8 digits after the decimal point on several fields, such as unit price, gross amount, and total cost. When trying to validate such an XML, this results in validation error: "RCF06001: En facturas emitidas en euros, alguno de los importes de las líneas tiene más de dos decimales (regla 6a del anexo II de la Orden HAP/1650/2015)." According to regulation HAP/1650/2015 [1]: For invoices issued in euros, it will be validated that the total line amounts related to the total cost are numeric and rounded, according to the common rounding method, to two decimal places. This commit introduces dynamic decimal precision: 2 places for EUR and 8 places (the previous default) for other currencies. [1] https://www.boe.es/diario_boe/txt.php?id=BOE-A-2015-8844 Machine translated [BOE-A-2015-8844 (1).pdf](https://github.com/user-attachments/files/25345382/BOE-A-2015-8844.1.pdf) opw-5927356 Forward-Port-Of: odoo/odoo#249674 Forward-Port-Of: odoo/odoo#248882
This update fixes an issue where the names of Ecuadorian invoicing regimes didn't comply with government regulations. The changes ensure that all invoice data sent to the Ecuadorian tax authority (SRI) uses the correct, officially recognized regime names. This ensures compliance and accurate reporting.
Original PR description
[FIX] l10n_ec_edi: fiscal localizations name The name of the regimes for the Ecuadorian localization does not respect the government requirements Steps to reproduce: 1. Install l10n_ec_edi module 2. Go to Settings > Invoicing > Ecuadorian Localization 3. In Electronic Invoicing > Regime, the names of the regimes do not respect government requirements Solution: Change the name of the fiscal localizations to respect the requirements Add a computed field used to map the name of the regime to the technical name of the regime used in SRI documents We write them in Spanish because we always want the name of the regime to be in Spanish in the XML invoice sent to the government, even if the user didn't install any other language. opw-5221871 Forward-Port-Of: odoo/enterprise#105914
This update resolves an issue that prevented users from clicking the Work Entries button when overtime records lacked a 'Stop' time. The fix corrects a comparison error between a datetime object and a boolean value, ensuring the button functionality is consistently available. This prevents a frustrating error for users managing overtime times.
Original PR description
Clicking the Work Entries smart button raises a traceback when an overtime record has no Stop (time_stop). Steps to reproduce the error: - Install ``hr_work_entry_attendance`` module with demo data -…
Clicking the Work Entries smart button raises a traceback when an overtime record has no Stop (time_stop). Steps to reproduce the error: - Install ``hr_work_entry_attendance`` module with demo data - Activate developer mode - Create an Employee A > Settings > Set Default Ruleset in Overtime Ruleset In Payroll Tab, Work Entry Source: ``Attendances`` and set Contract - Create an overtime attendance > Save > Open the Overtime Details > Unset the ``Stop(time_stop)`` > Save - Open Employee A > Click on Work Entries smart button Traceback: ```py TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime' ``` https://github.com/odoo/enterprise/blob/56c3723a925f718ba39d11cde12933542ebcd7c1/hr_work_entry_attendance/models/hr_version.py#L49-L52 When ``stop(time_stop)`` is unset in the overtime, ``ot.time_stop`` is False, causing ``min()`` to compare a ``datetime`` with ``False``, which raises the above traceback. sentry-7169332615 Forward-Port-Of: odoo/enterprise#103764
This update clarifies a confusing error message related to delivery scheduling and lock dates. Previously, a validation error would point to the wrong stock picking record. Now, the error message identifies the specific stock picking record and only checks lock dates when the delivery date is changed, making it easier for users to resolve scheduling issues.
Original PR description
A recent improvement task (ID [5065601](https://www.odoo.com/odoo/project.task/5065601)) allows `stock.picking` to backdate deliveries, as long as the `scheduled_date` and `date_done` fields are both…
A recent improvement task (ID [5065601](https://www.odoo.com/odoo/project.task/5065601)) allows `stock.picking` to backdate deliveries, as long as the `scheduled_date` and `date_done` fields are both after the lock date. Related: PR #222169
When validating a `stock.picking` record, the constraint `_check_backdate_allowed()` can fail on a different `stock.picking` record. This is confusing for the end user and makes finding the erroneous `stock.picking` difficult.
## Steps to reproduce.
**setup**:
1. install stock, sale, purchase. Use the demo data.
2. Navigate to Inventory > Configuration > Warehouse and click into the Warehouse for the active company.
3. Select the Routes smart button, then select the Buy route. Ensure that the "Product" option is selected for the Buy route.
4. Navigate to Inventory > Product > Product.
5. Create a test product that is:
1. tracked by quantity (General Information tab)
2. Has a vendor listed (in the Purchases tab)
3. Uses the "buy" route (in the Inventory tab)
4. Has a reordering rule for the Buy route (reordering rules smart button)
6. Do not add any stock for this product.
**reproduction**:
1. Navigate to Sale > Orders.
2. Create and confirm a sale order for the configured product, such that more products will need to be created.
3. Navigate into the delivery order for the sale and set its scheduled date to be December 1st.
4. In Accounting > Accounting > lock dates, set all the lock dates to be December 3rd.
5. Navigate back to the sales order, then use the Purchase order smart button to view the purchase order.
7. Use the Deliveries smart button to view the purchase delivery.
8. Validate the delivery - > Validation error thrown
> You cannot modify the scheduled date of this operation because it falls within a locked fiscal period.
**Solution**: add the name of the stock.picking to the error message & only check the lock date when `date_done` is altered, not `scheduled_date`.
[opw-5428179](https://www.odoo.com/odoo/unassigned-tasks/5428179)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#247474This update resolves an error that occurred when employees had multiple leave types allocated. The fix ensures the holiday attest calculation accurately sums all available leave time, preventing a traceback during payroll processing. This improves the reliability of holiday pay calculations for employees with complex leave arrangements.
Original PR description
Bug : - allocate multiple leave types to an employee - lay off the employee -access the holiday attest wizard and try to compute holiday attest and you'll see a traceback Reason : - time_off_allocated and time_off_taken were expecting to find exactly one line of "Legal Time Off". Receiving multiple caused an Error. Fix : FIxing the logic by taking all the available lines and summing there values. task - 5461268 Forward-Port-Of: odoo/enterprise#107673
This update fixes an issue where selling kit products through Point of Sale (POS) resulted in incorrect stock valuation calculations. The fix ensures that the UoM of kit components is properly considered when calculating expenses and stock levels, leading to accurate inventory management. This improves the reliability of financial reporting within Odoo.
Original PR description
When selling a kit product in POS, if the component of the kit use a different UoM than the UoM defined on the product, the stock valuation lines are wrong. Steps to reproduce: ------------------- * Create a storable product A with a UoM "Dozen" and a cost price of 10€ * Create a kit product B with a BoM of 1 unit of product A * Sell 1 unit of product B in POS > Observation: The valuation lines have the wrong value Why the fix: ------------ The product qty was not considering the UoM when computing the expense and stock valuation lines. opw-5471923 Forward-Port-Of: odoo/odoo#248694
This update fixes a bug in the 19.0 version of Odoo's MRP module that prevented users from copying operations from other Bills of Materials. The 'Copy Existing Operations' button was accidentally removed during a UI update. This change restores the functionality, allowing users to easily duplicate operations when starting with a blank BoM, improving efficiency.
Original PR description
### Steps to reproduce the bug: - Install mrp - Go to manufacturing app - Go to products -> bills of materials - Create a new bill of material for a product - Go to the operations tab - No 'copy…
### Steps to reproduce the bug: - Install mrp - Go to manufacturing app - Go to products -> bills of materials - Create a new bill of material for a product - Go to the operations tab - No 'copy existing operations' button appears if at least one operation is already created ### The problem: In version 19.0, the "Copy Existing Operations" button is missing from the BoM operations tab when no operations have been defined yet for the current BoM. While this feature was fully functional in version 18.4, it became inaccessible in 19.0 to users due to a UI reorganization introduced in commit https://github.com/odoo/odoo/commit/80e6ed658fb43584bc2fad673ca40d9af6cf0ab6 that accidentally omitted the "Copy Existing Operations" button. Currently, users are forced to manually create at least one operation before they can see the option to copy from other BoMs. ### The reason to introduce the fix: The ability to copy operations is useful also when starting with an empty BoM if operations in other BoM's have been already created. Since this fix has already been implemented in version 19.1 via commit https://github.com/odoo/odoo/commit/02e837c959381523170c653da099328e9855a4e4, this PR backports that changes to 19.0 to restore feature parity and improve the user experience. opw-5906667 Forward-Port-Of: odoo/odoo#248225
This change reverses a recent update that was incorrectly removing accented characters from legal names used for Mexican VAT (EDI) processing. The SAT now allows all characters, so Odoo will now accept the user-entered, accented names as they are, giving users full control and preventing errors. This simplifies the process and ensures accurate data.
Original PR description
An accent sanitization feature was introduced in Odoo 18 [1]. It was done because it appeared the SAT replaced certain characters with their unaccented counterpart, but it's not the case. At least…
An accent sanitization feature was introduced in Odoo 18 [1]. It was done because it appeared the SAT replaced certain characters with their unaccented counterpart, but it's not the case. At least today, the SAT allows all characters (pointed out in [2]). This explains why in the past 6 months this feature has been slowly undone [3][4][5], character by character, after customers run into issues. The approach can not work, so we go back to the name with the accents the user puts on the partner. Users need to put the correct, legally registered name in Odoo. If it doesn't work then they can adapt it as needed. This way the user is in full control, and we don't block them. This reverts the whole accent sanitization saga: - Revert "[FIX] l10n_mx_edi - More accented characters accepted by SAT", this reverts commit 46cc41ddd258e80372478a746ea79d154a5931d9. - Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit dcbd8797667b5be88f48045e48da86ac42db362c. - Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 32b8333fd3f813ec3188394c2634129e3fbfe31d. - Revert "[FIX] l10n_mx_edi: Fix accents in legal name", this reverts commit 05ed1fb9059bd1459e38dc00b041cada6bf06ac4. This also removes the unused frozendict import to make "Check Style" happy. opw-5915515 [1] https://github.com/odoo/enterprise/pull/95207 [2] https://github.com/odoo/enterprise/pull/107960 [3] https://github.com/odoo/enterprise/pull/96043 [4] https://github.com/odoo/enterprise/pull/106557 [5] https://github.com/odoo/enterprise/pull/107677 Closes odoo/enterprise#107960 Forward-Port-Of: odoo/enterprise#108425 Forward-Port-Of: odoo/enterprise#108189
This update corrects a discrepancy in payslip calculations related to the private car allowance. The daily amount is now rounded to two decimal places, ensuring the displayed value precisely matches the 'Quantity × Amount' shown on payslips. This improves payroll accuracy and reporting.
Original PR description
Round the computed daily private-car salary rule amount to 2 decimals so the displayed per-day value matches Quantity × Amount on payslips. References task-5917569 Forward-Port-Of: odoo/enterprise#108160 Forward-Port-Of: odoo/enterprise#106753
This update resolves access restrictions preventing basic sales, stock, and purchase workflows for users with limited permissions. The changes ensure these users can correctly interact with key processes like creating invoices and purchase orders, improving usability and reducing potential disruptions.
Original PR description
*: account,sale,stock_delivery Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields…
*: account,sale,stock_delivery Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields you have read acccess to. This change highlight numerous access right issues in basic flows for users with minimal access. Here is a list of examples (each performed with every other access rights disabled): - With a `stock user`, open the delivery list or form view #### > Access error - With a `purchase user` create and confirm a PO > Upload Bill #### > the Bill will be created but an access error will prevent the draft bill from opening. - With a `sale user` create and confrim an SO > Create invoice #### > the invoice will be created but an access error will prevent the draft invoice from opening. ## Solutions: ### Use case: Open an invoice (`acount.move`) linked to one of your SO/PO with a basic `sale`/`purchase` user: 1) For basic `sale` and `purchase` users to be able to open the `account.move` Form on which they have read, update, create, delete access rights, it is necessary for the `payment_count` to be compute sudo since it is used in the view: https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/account/views/account_move_views.xml#L859 And these users do not have the read access of the `account.payment` model. Similarily the `_compute_asset_ids` needs to be compute sudo because it relies on the related `asset_ids` of `account.move.line`s or on values of these `account.asset`s for which the users shoud not have read access: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L27-L30 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L317-L323 and the `asset_ids`, `count_asset`, `asset_id_display_name` and `draft_asset_exists` are all used in the view. #### Note for master: IMO, the `asset_ids` field of the `account.move` model should probably be in a separate compute to not be computed in sudo and removed from the views as it is currently used only to determine if there is or not `asset_ids`. An information that is provided by the `count_asset`. E.G. here: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L10 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L35-L40 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L44-L52 2) For basic `purchase` users to open the invoice linked to one of their PO, it is necessary that the `sale_order_count` is computed in sudo as they do not have access to the related `sale_line_ids` field and the field is used in the `account.move` form: https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/models/account_move.py#L46-L49 https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/views/account_views.xml#L53 ### Use case: Open a `stock.picking` views as basic stock user: 3) The basic `stock` users have a read access on the `delivery.carrier` model and should also on the related `delivery.zip.prefix` and `delivery.price.rule` models. First as it make sense functionally but also as it currently blocks them on basic flows. For instance basic stock users can not open the `stock.picking` list or form view as the `carrier_id` is part of these view: https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/stock_delivery/views/delivery_view.xml#L125-L132 This is problematic as this field has a domain relying on the related `allowed_carrier_ids` field: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_delivery/models/stock_picking.py#L23-L24 As such, when the view is opened, the related field needs to be read. However, the `_compute_allowed_carrier_ids` fails if you do not have read access rights on the `delivery.zip.prefix` model: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L198 https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L70-L72 Similarily `delivery.price.rule` model should be readable for `stock` users in order to be able to get be able to rely on the `price_rule_ids` when necessary such as here: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L492-L496 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr opw-5461135 opw-5417749 Forward-Port-Of: odoo/odoo#247531
This update resolves access restrictions that were preventing basic sales, purchase, and stock users from fully utilizing key workflows. The changes ensure these users can correctly create and manage invoices, purchase orders, and stock deliveries, improving usability for users with limited permissions.
Original PR description
*: account_asset, sale_lazada Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields…
*: account_asset, sale_lazada Since [19.0](https://github.com/odoo/odoo/pull/217277#issue-3198442339), read access rights are checks on comodels when trying to read the value of a many2many fields you have read acccess to. This change highlight numerous access right issues in basic flows for users with minimal access. Here is a list of examples (each performed with every other access rights disabled): - With a `stock user`, open the delivery list or form view #### > Access error - With a `purchase user` create and confirm a PO > Upload Bill #### > the Bill will be created but an access error will prevent the draft bill from opening. - With a `sale user` create and confrim an SO > Create invoice #### > the invoice will be created but an access error will prevent the draft invoice from opening. ## Solutions: ### Use case: Open an invoice (`acount.move`) linked to one of your SO/PO with a basic `sale`/`purchase` user: 1) For basic `sale` and `purchase` users to be able to open the `account.move` Form on which they have read, update, create, delete access rights, it is necessary for the `payment_count` to be compute sudo since it is used in the view: https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/account/views/account_move_views.xml#L859 And these users do not have the read access of the `account.payment` model. Similarily the `_compute_asset_ids` needs to be compute sudo because it relies on the related `asset_ids` of `account.move.line`s or on values of these `account.asset`s for which the users shoud not have read access: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L27-L30 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/models/account_move.py#L317-L323 and the `asset_ids`, `count_asset`, `asset_id_display_name` and `draft_asset_exists` are all used in the view. #### Note for master: IMO, the `asset_ids` field of the `account.move` model should probably be in a separate compute to not be computed in sudo and removed from the views as it is currently used only to determine if there is or not `asset_ids`. An information that is provided by the `count_asset`. E.G. here: https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L10 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L35-L40 https://github.com/odoo/enterprise/blob/06cf3f2b6663c61f1fcc158678dfb1fa43ece4e1/account_asset/views/account_move_views.xml#L44-L52 2) For basic `purchase` users to open the invoice linked to one of their PO, it is necessary that the `sale_order_count` is computed in sudo as they do not have access to the related `sale_line_ids` field and the field is used in the `account.move` form: https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/models/account_move.py#L46-L49 https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/sale/views/account_views.xml#L53 ### Use case: Open a `stock.picking` views as basic stock user: 3) The basic `stock` users have a read access on the `delivery.carrier` model and should also on the related `delivery.zip.prefix` and `delivery.price.rule` models. First as it make sense functionally but also as it currently blocks them on basic flows. For instance basic stock users can not open the `stock.picking` list or form view as the `carrier_id` is part of these view: https://github.com/odoo/odoo/blob/4ea42f8b16a8619cced4255f5bba8de6427345b7/addons/stock_delivery/views/delivery_view.xml#L125-L132 This is problematic as this field has a domain relying on the related `allowed_carrier_ids` field: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/stock_delivery/models/stock_picking.py#L23-L24 As such, when the view is opened, the related field needs to be read. However, the `_compute_allowed_carrier_ids` fails if you do not have read access rights on the `delivery.zip.prefix` model: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L198 https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L70-L72 Similarily `delivery.price.rule` model should be readable for `stock` users in order to be able to get be able to rely on the `price_rule_ids` when necessary such as here: https://github.com/odoo/odoo/blob/93fa6d9fff63534cfa9251e21fc82797d8b83468/addons/delivery/models/delivery_carrier.py#L492-L496 opw-5461135 opw-5417749 Forward-Port-Of: odoo/enterprise#106694