Daily updates from Odoo
Friday, October 17, 2025
59 changes
8 changes
Enhancements to existing features
Refreshing webhooks from the settings now clears the existing product links from the point of sale before sending a fresh menu to UrbanPiper. This helps ensure the external ordering platform receives an up-to-date menu and avoids stale product mappings.
Original PR description
Following this commit: - On refreshing webhooks from settings, products will be unlinked from pos. - Fresh menu will be updated to Urbanpiper platform task-5163764 Forward-Port-Of: odoo/enterprise#97000
Payroll users can now see and manage contract offers directly from the employee form without needing recruitment permissions. This gives payroll officers the access they need for offer and contract work while keeping responsibilities aligned with their role.
Original PR description
Previously, the Offers smart button on the employee form was only available to recruitment users. This limited visibility for payroll officers who also need access to contract offers. This commit Changes the button visibility to hr_payroll.group_hr_payroll_user in hr_employee_views.xml. Adds missing access rights in ir.model.access.csv for hr.group_hr_user (inherited by payroll users). Updates the module manifest to include the new security CSV. The goal is to ensure payroll users can access and manage offers directly without requiring recruitment rights. task-5085078
Users can now choose which IoT printer is used for shipping labels instead of the system automatically using the first available matching printer. This helps warehouses route labels to the correct printer for each operation type and avoids confusing errors when no printer is linked.
Original PR description
Printing shipping labels is performed from the backend, once the shipping info are received in the chatter. The printing command is sent to the frontend via the user bus, then though longpolling to the iot box. This commit adds the possibility to select a printer instead of choosing automatically the first (with the right report associated) on the list. As the change is made on a stable version, we are using system parameters to store the selected printer without adding a new field. We associate a printer with the picking type, in order for to be able to have different printers by default on different picking types. backport of odoo/enterprise#86818 Task: 4792491 Forward-Port-Of: odoo/enterprise#97269 Forward-Port-Of: odoo/enterprise#95794
Changing inventory valuation settings on very large product categories is now much faster. This reduces delays and timeouts for businesses managing many product variants, making stock accounting configuration changes more reliable.
Original PR description
Changing a product.category's valuation from manual to real-time or real-time to manual does mainly two things. The first one is emptying the current stock and valuation. The second is to replenish…
Changing a product.category's valuation from manual to real-time or real-time to manual does mainly two things. The first one is emptying the current stock and valuation. The second is to replenish the stock according to the new valuation. This process can be heavy when the number of product.products related to the active product.category is big. This can happen when product.attributes are set to "Creation: Instantly" for instance. This commit aims at improving the overall speed of this change in some cases. A first optimization is to use `product_tmpl_id` to retrieve the `product_variant_ids`. When there are a lot of products, it's faster to explicitely use the delegated field `product_tmpl_id`. This avoids lots of calls to `__getitem`/`__setitem__` in `_compute_related`. The downside of doing this is that subsequent calls to `self.product_variant_ids` are gonna raise a CacheMiss. So we have to explicitely use `product_tmpl_id.product_variant_ids` every time. We argue that it's not really an issue here as retrieving the variant_ids from a product.product itself is not that frequent in the codebase. A second optimization is to avoid calling `product.qty_available` in `_compute_value_svl` in case `avg_cost = 0`. With an avg_cost of 0, the total_value is always going to be 0. So there's no point in calling the heavy compute method `_compute_quantities` to retrieve `qty_available` here. #### speedup In a database with 228 000 product.products linked to the same product.category, the time to switch the category valuation from manual to real-time: +15min (timeout) -> 18s --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231206
This update adds test coverage for Indian electronic invoicing when exports are made without a Letter of Undertaking and prices already include tax. It helps ensure the taxable base is reported consistently with the invoice total, reducing the risk of incorrect compliance data.
Original PR description
Add test for export without LUT and price included tax, but base should be equal to invoice total. Forward-Port-Of: odoo/odoo#231943 Forward-Port-Of: odoo/odoo#231614
Bank journals now highlight invalid statements more clearly and avoid showing misleading statement or balance information. This helps accounting teams spot issues sooner, keep imported statement files attached, and prevent accidental deletion of transactions linked to valid statements.
Original PR description
This commit brings more clarity on invalid statements. The reflected changes are : - Hiding Last Statement if its date is <= Lock Date - "Invalid Statement(s)" alert on the journal dashboard - Red balance amount and warning in the BankRecW when it contains invalid statements (clicking on the warning applies the filter) - Possibility to choose a statement when creating a transaction - Invalid statement warning in the statement creation form - Displays all warnings in the statement form view - When a file generate a statement, it is kept in its attachments - Prevent deletion of transactions if they belong to a valid statement - Empty statement are not taken into account for the dashboard Last Statement and the BankRecW balance task-4413473 Forward-Port-Of: odoo/odoo#222447
Bank statement screens now make invalid statements easier to spot and act on, including dashboard alerts, warning indicators, and clearer balance highlighting. The update also protects valid statement transactions from deletion and keeps imported statement files attached for better traceability.
Original PR description
* accountant|bank_statement_import This commit brings more clarity on invalid statements. The reflected changes are : - Hiding Last Statement if its date is <= Lock Date - "Invalid Statement(s)" alert on the journal dashboard - Red balance amount and warning in the BankRecW when it contains invalid statements (clicking on the warning applies the filter) - Possibility to choose a statement when creating a transaction - Invalid statement warning in the statement creation form - Displays all warnings in the statement form view - When a file generate a statement, it is kept in its attachments - Prevent deletion of transactions if they belong to a valid statement - Empty statement are not taken into account for the dashboard Last Statement and the BankRecW balance task-4413473 Forward-Port-Of: odoo/enterprise#92078
This update adjusts tax rounding behavior for Mexican electronic invoicing so totals align more reliably with localization requirements. It helps reduce discrepancies in invoices and tax reporting when amounts are rounded.
Original PR description
Forward-Port-Of: odoo/enterprise#97220 Forward-Port-Of: odoo/enterprise#96809
10 changes
Enhancements to existing features
This update adjusts tax rounding so Mexican electronic invoices calculate totals more consistently with current requirements. It also aligns related point-of-sale tax handling, reducing discrepancies in invoice and receipt amounts.
Original PR description
Forward-Port-Of: odoo/enterprise#96809
Refreshing UrbanPiper webhooks from settings now detaches products from the point of sale before sending an updated menu to UrbanPiper. This helps ensure UrbanPiper receives a clean, current menu after a refresh, reducing mismatches between Odoo POS and the delivery platform.
Original PR description
Following this commit: - On refreshing webhooks from settings, products will be unlinked from pos. - Fresh menu will be updated to Urbanpiper platform task-5163764 Forward-Port-Of: odoo/enterprise#97000
Bank journals now make invalid or outdated statements easier to spot and manage, including dashboard alerts, reconciliation warnings, and clearer statement form messages. This helps accounting teams avoid using unreliable statement data and protects valid statement transactions from accidental deletion.
Original PR description
This commit brings more clarity on invalid statements. The reflected changes are : - Hiding Last Statement if its date is <= Lock Date - "Invalid Statement(s)" alert on the journal dashboard - Red balance amount and warning in the BankRecW when it contains invalid statements (clicking on the warning applies the filter) - Possibility to choose a statement when creating a transaction - Invalid statement warning in the statement creation form - Displays all warnings in the statement form view - When a file generate a statement, it is kept in its attachments - Prevent deletion of transactions if they belong to a valid statement - Empty statement are not taken into account for the dashboard Last Statement and the BankRecW balance task-4413473
Accounting users now get clearer warnings when bank statements are invalid, including dashboard alerts, reconciliation warnings, and form-level messages. This helps teams spot statement issues earlier, avoid using locked or empty statements in balances, and protect transactions linked to valid statements from accidental deletion.
Original PR description
* accountant|bank_statement_import This commit brings more clarity on invalid statements. The reflected changes are : - Hiding Last Statement if its date is <= Lock Date - "Invalid Statement(s)" alert on the journal dashboard - Red balance amount and warning in the BankRecW when it contains invalid statements (clicking on the warning applies the filter) - Possibility to choose a statement when creating a transaction - Invalid statement warning in the statement creation form - Displays all warnings in the statement form view - When a file generate a statement, it is kept in its attachments - Prevent deletion of transactions if they belong to a valid statement - Empty statement are not taken into account for the dashboard Last Statement and the BankRecW balance task-4413473
Switching inventory valuation settings on very large product categories is now much faster. This reduces delays and timeouts for businesses managing many product variants, improving operational efficiency during accounting and inventory configuration changes.
Original PR description
Changing a product.category's valuation from manual to real-time or real-time to manual does mainly two things. The first one is emptying the current stock and valuation. The second is to replenish…
Changing a product.category's valuation from manual to real-time or real-time to manual does mainly two things. The first one is emptying the current stock and valuation. The second is to replenish the stock according to the new valuation. This process can be heavy when the number of product.products related to the active product.category is big. This can happen when product.attributes are set to "Creation: Instantly" for instance. This commit aims at improving the overall speed of this change in some cases. A first optimization is to use `product_tmpl_id` to retrieve the `product_variant_ids`. When there are a lot of products, it's faster to explicitely use the delegated field `product_tmpl_id`. This avoids lots of calls to `__getitem`/`__setitem__` in `_compute_related`. The downside of doing this is that subsequent calls to `self.product_variant_ids` are gonna raise a CacheMiss. So we have to explicitely use `product_tmpl_id.product_variant_ids` every time. We argue that it's not really an issue here as retrieving the variant_ids from a product.product itself is not that frequent in the codebase. A second optimization is to avoid calling `product.qty_available` in `_compute_value_svl` in case `avg_cost = 0`. With an avg_cost of 0, the total_value is always going to be 0. So there's no point in calling the heavy compute method `_compute_quantities` to retrieve `qty_available` here. #### speedup In a database with 228 000 product.products linked to the same product.category, the time to switch the category valuation from manual to real-time: +15min (timeout) -> 18s --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231206
Updates Uruguay localization so businesses can configure and report reduced VAT rates that differ from the standard exempt, minimum, and basic rates. This helps comply with local e-invoicing and tax reporting requirements for cases such as reduced VAT on card or electronic money payments.
Original PR description
To fully comply with regulatory requirements, we need to support an additional category called "Reduced Tax Rate" when a product line has a Reduced VAT rate (e.g., 20%) for sales of goods and…
To fully comply with regulatory requirements, we need to support an additional category called "Reduced Tax Rate" when a product line has a Reduced VAT rate (e.g., 20%) for sales of goods and services to final consumers when payment is made by debit card or electronic money instrument (and other specific reductions in similar cases).
1. Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate".
2. Modifying XML Output:
* In the <Totales> section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the <MntIVAOtra> tag.
* Example: xml <MntIVAOtra>140</MntIVAOtra> (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the <IndFact> tag to 4: xml <IndFact>4</IndFact>
*Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate".
3. Tax Grid for Configuration:
*Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes.
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.
Task latam side: 1330
Task Adhoc side: 52999
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#221073Uruguayan electronic invoices can now correctly identify and report VAT rates outside the standard exempt, minimum, and basic rates. This improves compliance by ensuring reduced-rate VAT is shown in the required invoice XML fields and available for tax configuration and reporting.
Original PR description
1) Detecting "Reduced Tax Rate": * Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced…
1) Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate".
2) Modifying XML Output:
* In the `<Totales>` section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the `<MntIVAOtra>` tag.
* Example: ```xml <MntIVAOtra>140</MntIVAOtra> ``` (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the `<IndFact>` tag to `4`: ```xml <IndFact>4</IndFact> ```
* Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate".
3) Tax Grid for Configuration:
* Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes.
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.
Task latam side: 1330
Task Adhoc side: 52999
Forward-Port-Of: odoo/enterprise#91392Adds automated test coverage for Indian electronic invoicing when exports are made without a Letter of Undertaking and prices include tax. This helps ensure invoice totals and taxable base amounts remain consistent, reducing the risk of incorrect compliance reporting.
Original PR description
Add test for export without LUT and price included tax, but base should be equal to invoice total. Forward-Port-Of: odoo/odoo#231943 Forward-Port-Of: odoo/odoo#231614
CODA bank statement imports now include clearer payment references for POS and SEPA transactions when that information is available. This helps matching payments to invoices automatically, reducing manual reconciliation work for accounting teams.
Original PR description
When importing a coda file, we deduce the payment ref depending on what is put in the coda. In the case of pos and sepa, we could add the reference in the payment ref to ease the process of auto reconcile. task-5065438
Spanish localization now separates Canary Islands purchase taxes for goods and services, allowing more accurate fiscal mapping. It also adds DUA tax data for Canary Islands operations, helping businesses apply the right tax treatment in local accounting flows.
Original PR description
We have splitted purchase taxes in goods and services because there are different mappings according to the scope. It has a similar functionality with spanish mainland taxes @jco-odoo There are doubts with the fiscal position `fp_nacional_canary_ns` as it is applied automatically to spanish non canarian partners but it should be similar to non-EU partners IMO. However, I think that the opinion fo some canary people would be nice to clarify it @Christian-RB --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228667
3 changes
Enhancements to existing features
Refreshing UrbanPiper webhooks from the settings now also disconnects products from the point of sale before publishing a fresh menu. This helps ensure UrbanPiper receives an up-to-date menu and reduces mismatches between Odoo and the delivery platform.
Original PR description
Following this commit: - On refreshing webhooks from settings, products will be unlinked from pos. - Fresh menu will be updated to Urbanpiper platform task-5163764 Forward-Port-Of: odoo/enterprise#97000
Uruguay electronic invoicing now recognizes VAT rates outside the standard exempt, minimum, and basic rates as reduced VAT. This ensures invoice XML totals, line classifications, and tax reporting grids correctly reflect these reduced-rate taxes for compliance.
Original PR description
1) Detecting "Reduced Tax Rate": * Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced…
1) Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate".
2) Modifying XML Output:
* In the `<Totales>` section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the `<MntIVAOtra>` tag.
* Example: ```xml <MntIVAOtra>140</MntIVAOtra> ``` (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the `<IndFact>` tag to `4`: ```xml <IndFact>4</IndFact> ```
* Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate".
3) Tax Grid for Configuration:
* Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes.
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.
Task latam side: 1330
Task Adhoc side: 52999
Forward-Port-Of: odoo/enterprise#91392The POS booking screen no longer automatically opens the on-screen keyboard on tablets and phones. This makes the booking flow smoother for restaurant and appointment users on touch devices.
Original PR description
Task: [#5016943](https://www.odoo.com/odoo/project/1737/tasks/5016943) --- On tablets and phones, the search bar was autofocus when opening the booking screen in the POS frontend. This was causing the keyboard to open automatically, which was not a good user experience. Now the search bar is not autofocus on touch devices for the booking screen by creating a new controller to manage this. Forward-Port-Of: odoo/enterprise#96873
17 changes
Enhancements to existing features
Salary offers now open the employee record when the selected contract template is actually tied to an employee, instead of showing the contract template view. This makes navigation clearer for HR users and helps them reach the relevant employee information faster.
Original PR description
If the selected contract template on the salary offer is an employee record, then we souldn't open the contract template view, but instead open the employee view with the correct record selected. task-5082709
The German tax report has been reorganized after removing a previously used balance column. This keeps the report logic aligned with the new layout and helps ensure tax report results remain reliable for German localization users.
Original PR description
After removing the balance column, we need to refactor the code that depends on it task-5046641
Odoo Discuss channels and groups now record the user who created them as the owner, making ownership visible in the member list. Member permissions are tightened so users can only directly access their own membership details, improving privacy and control around channel data.
Original PR description
1. Add a new field to store the owner of a channel/group. The owner is the user who created the channel/group. Owner should have a special icon in the member list. 2. Modify the access rights of channel members: channel member can only read/write current user data ACL : is_self can do everything, others denied and use sudo whenever reading for others, or for writing Task-4107790
Point of Sale alert popups have been refreshed with a clearer design and more consistent, user-friendly wording. This helps cashiers and staff better understand warnings or required actions during sales, payments, printing, and localized fiscal workflows.
Original PR description
Task: [#5153312](https://www.odoo.com/odoo/project/1737/tasks/5153312) --- Created a new `PosAlertDialog` component that extends the existing `AlertDialog` with an updated design. Also revised alert messages across all POS modules to make them more user-friendly and consistent.
The helpdesk stage form now uses clearer wording for the time before a ticket is considered rotting. This makes the setting easier for users to understand by showing the value directly as a number of days.
Original PR description
**Specifications:** Change the label of `rotting_threshold_days` field and show days as a unit of measure in the form view. **After this PR:** 'Days to rot' -> 'Rotting in __ days' Task-5149031
ESG screens and reports now use shorter field labels by removing repeated unit text where users already know the context. Several views were also reviewed and tooltips were added to make ESG data entry and reporting easier to understand.
Original PR description
This commit mostly removes the units displayed on field labels to have condensed labels since the unit is known by the ESG users. It also reviews some views and adds some tooltips. task-5138748
The barcode app interface has been refined to look cleaner and more consistent on mobile devices. The changes improve readability and prevent visual glitches such as content showing through, oversized shadows, cramped buttons, and off-center text.
Original PR description
This PR fixes a few design issues: - Adds a background to prevent underlying content from showing through - Deletes prominent box-shadows - Prevents the chatter buttons from shrinking - Centers the…
This PR fixes a few design issues: - Adds a background to prevent underlying content from showing through - Deletes prominent box-shadows - Prevents the chatter buttons from shrinking - Centers the text on mobile task-5113549 PR-commu: https://github.com/odoo/odoo/pull/229542 | Before | After | |--------|--------| | <img width="407" height="577" alt="footer-bg-avant" src="https://github.com/user-attachments/assets/74c25c20-a119-4448-bbb5-0c5ee13eff57" /> | <img width="402" height="559" alt="footer-bg-after" src="https://github.com/user-attachments/assets/17533695-314c-4be7-b9b0-c290ff9fe144" /> | | <img width="409" height="581" alt="shadow-before" src="https://github.com/user-attachments/assets/b29b802a-68c3-4fc2-a327-8e62b2d9e2cd" /> | <img width="411" height="561" alt="shadow-after" src="https://github.com/user-attachments/assets/47add086-25b5-4612-969b-5bd60390e4f8" /> | | <img width="401" height="579" alt="log-note-buttons-before" src="https://github.com/user-attachments/assets/839ac7c8-18af-4270-a8c0-960c63cf68d5" /> | <img width="405" height="560" alt="log-note-buttons-after" src="https://github.com/user-attachments/assets/06577c82-2093-4ea8-b715-838ec9d0b623" /> | | <img width="402" height="574" alt="text-before" src="https://github.com/user-attachments/assets/70cabab3-b925-4a2a-8e2c-3936e4957e5a" /> | <img width="407" height="559" alt="text-after" src="https://github.com/user-attachments/assets/f172763c-5f93-47f8-8a68-9f0e991f38cd" /> |
Modules can now explicitly state when they use paid in-app services, instead of being labeled paid just because they depend on the IAP infrastructure. This helps avoid incorrectly marking free localization and integration modules as containing paid services.
Original PR description
Currently, we have a `has_iap` field on the `IrModuleModule` model which is used to display whether the module contains In-App Purchases, i.e. a paid service provided through IAP. However, this field is computed based on whether the module has an (indirect) dependency to the `iap` module. This is a bit too simplistic as relying on the `iap` module does not mean that the service is paid and consumes IAP credits. For instance, we have many EDIs modules now that rely on IAP, but that are totally free (e.g.: Malaysia POS, Spain POS, Switzerland Payroll, ...) To tackle this, we introduce a new field in the manifest: `iap_paid_service`. If set to True, we explicitely mark the module as a module that uses IAP credits, and therefore contains In-App Purchases. task-5048119
The Tasks button on Helpdesk tickets now uses the same checkmark icon as other task-related views. This makes the interface more consistent and easier for users to recognize when planning interventions.
Original PR description
Before this commit: --- The 'Tasks' stat button displayed in the Helpdesk Ticket form view (visible when planning an intervention) used a different icon than other task-related views, leading to inconsistency in the user interface. After this commit: --- The 'Tasks' stat button now uses the fa-check icon for consistency with the other views where similar buttons are used, providing a more coherent and clear visual appearance. task-5138828
Default working schedules for companies in India now use a 10:00 to 19:00 workday instead of 08:00 to 17:00. This better matches local business norms and reduces manual setup for Indian payroll configurations.
Original PR description
Currently, employee working hours in Indian companies are not aligned with local standards. The system default time range is, 08:00-17:00. This commit updates the configuration so that for companies located in India, the default working schedule reflects Indian working hours — 10:00 to 19:00. Task ID: 5158751
An information icon with guidance has been added next to the payslip period field. This helps payroll users enter the full and correct period, reducing confusion and potential data entry mistakes.
Original PR description
Added help text next next to payslip period so that the user enters the correct complete period Task-4996387
Work entries now show a file-text icon when a description is present, making details easier to spot in planning views. Automatically generated work entries are no longer pre-filled with descriptions, reducing unnecessary text and keeping records cleaner.
Original PR description
This PR aims to: - Add a file-text icon on pills with a description (with padding adjustments for file/lock icons) - Prevent generated work entries from being pre-filled with a description task-5026021
The point of sale integration for UrbanPiper now prepares order data directly from the order record instead of depending on a separate store service. This keeps the setup cleaner and makes the logic easier to reuse and maintain, with no expected change for day-to-day users.
Original PR description
**In this commit:** Move the `getOrderData` method to the `pos.order` model. This change allows the data preparation logic to be accessed directly via the model, avoiding reliance on the `pos_store` service. Task: 4827509 Related: https://github.com/odoo/odoo/pull/212748
UAE payroll now excludes unpaid leave and unpaid sick leave days when calculating end-of-service amounts and related provisions. End-of-service payslips also show the total unpaid leave days, giving payroll teams clearer and more accurate information.
Original PR description
This commit excludes the Out Of Contract Unpaid Leaves and Unpaid Sick Leave days from the EoS and EoS Provision Salary Rule Calculations. We also show the total number of unpaid leave days on the EoS payslip. task-4886104 Forward-Port-Of: odoo/enterprise#97063 Forward-Port-Of: odoo/enterprise#95465
Refreshing webhooks from settings now disconnects existing products from the point of sale before sending a fresh menu to UrbanPiper. This helps ensure the external ordering platform receives an up-to-date menu and reduces mismatches between Odoo and UrbanPiper.
Original PR description
Following this commit: - On refreshing webhooks from settings, products will be unlinked from pos. - Fresh menu will be updated to Urbanpiper platform task-5163764 Forward-Port-Of: odoo/enterprise#97000
POS users can now change whether a product is available for food delivery directly from the product information popup. This helps restaurants react faster to stock or kitchen constraints without leaving the POS workflow.
Original PR description
Before this commit: ------------------------- There was no way to change the food availability status of a product from the POS terminal. After this commit: ------------------------- Added an option in the POS UI product info popup to toggle the availability of products for configurations that support food delivery handling. Task: 4951476 Forward-Port-Of: odoo/enterprise#91681
Bank statement imports now choose the quickest reconciliation method based on file size. Small imports are reconciled immediately, while larger imports continue to run in the background to avoid slowing down the user.
Original PR description
When doing an import, to avoid taking too much time we decided to trigger the cron directly but for small files it's not really efficient. When the file has less than 80 statement lines we do the auto reconcile otherwise we trigger the cron. task-5162686 Forward-Port-Of: odoo/enterprise#97004
14 changes
Enhancements to existing features
Small bank statement imports are now reconciled immediately, while larger imports are still processed in the background to avoid delays. This improves responsiveness for everyday small imports without slowing down heavier accounting workloads.
Original PR description
When doing an import, to avoid taking too much time we decided to trigger the cron directly but for small files it's not really efficient. When the file has less than 80 statement lines we do the auto reconcile otherwise we trigger the cron. task-5162686
Payroll users can now view and manage contract offers directly from the employee form without needing recruitment permissions. This improves day-to-day payroll workflows by giving the right teams access to offer information where they need it.
Original PR description
Previously, the "Offers" smart button on the employee form was only available to recruitment users. This limited visibility for payroll officers who also need access to contract offers. This commit: - Changes the button visibility to `hr_payroll.group_hr_payroll_user` in `hr_employee_views.xml`. - Adds missing access rights in `ir.model.access.csv` for `hr.group_hr_user` (inherited by payroll users). - Updates the module manifest to include the new security CSV. The goal is to ensure payroll users can access and manage offers directly without requiring recruitment rights. task-5085078
The German tax report has been reorganized to better match the official ELSTER VAT return structure. This makes the report easier for German businesses and advisors to review and align with expected filing categories.
Original PR description
Rework the structure of the German Tax Report according to the very well detailed structure https://sevdesk.de/ratgeber/buchhaltung-finanzen/ustva/formular-elster/ task-5046641 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The German tax report has been reworked after removing a balance column, ensuring the report logic continues to match the new layout. This helps maintain accurate German tax reporting and reduces the risk of reporting issues after the layout change.
Original PR description
After removing the balance column, we need to refactor the code that depends on it task-5046641
The Hong Kong payroll Manulife MPF report is easier to use, with a button to populate employees and safeguards that preserve manual changes. It also corrects how new employee contribution data is split across months, improving report accuracy and reducing manual rework.
Original PR description
Improve the report UX, replacing the compute that didn't really work by a button to populate the employee list, avoid overriding changes done on generated lines, and avoiding to block the feature if some settings are not set to instead display fields for these to relevant users. Also fixes an issue with how the data is recorded for new employees, which would sum the first few months in a single line instead of spreading the data correctly. Precomputation is added to the lines in the report to ensure that the lines appear when the form is opened and do not require to play with the date for it. task-5091533
Refreshing webhooks from the settings now disconnects existing POS product links and sends a fresh menu update to UrbanPiper. This helps ensure the external delivery platform receives the latest product/menu setup after a webhook refresh.
Original PR description
Following this commit: - On refreshing webhooks from settings, products will be unlinked from pos. - Fresh menu will be updated to Urbanpiper platform task-5163764 Forward-Port-Of: odoo/enterprise#97000
Italian electronic invoices are now processed one at a time when sent through the external exchange service, reducing timeout issues when large batches are submitted. This helps prevent scheduled invoice processing from getting stuck and improves reliability for customers sending many invoices at once.
Original PR description
Some clients reported that when they send a full batch size=20 invoices at once, they get a timeout response and the cron job get's stuck. Processing invoices one by one instead of a full batch. IAP-apps PR: https://github.com/odoo/iap-apps/pull/1230 Task [link](https://www.odoo.com/odoo/project.task/5045529) task-5045529 Forward-Port-Of: odoo/odoo#231742 Forward-Port-Of: odoo/odoo#230146
This update prepares Point of Sale IoT connections for upcoming Chrome local network access rules. It helps ensure Odoo can continue communicating with local IoT devices, such as connected hardware, when accessed from secure browser sessions.
Original PR description
Enterprise PR: https://github.com/odoo/enterprise/pull/96850 Local Network Access restrictions will start shipping by default in Chrome 142. As part of this change, local requests will be allowed to use HTTP in an HTTPS context (gated by a browser permission prompt). This will work automatically when the IP is provided directly, however in the case of IoT we often use the odoo-iot DNS domain to resolve the IP. In this case, you must specify the option `targetAddressSpace: "local"` in the `fetch` request. This commit simply adds this change where appropriate. task-5157145 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231644 Forward-Port-Of: odoo/odoo#231014
This update prepares Odoo’s Point of Sale IoT connections for upcoming Chrome browser restrictions on local network access. It helps ensure local IoT devices can still be reached reliably when using the odoo-iot address, reducing the risk of disruption for stores using connected hardware.
Original PR description
Community PR: https://github.com/odoo/odoo/pull/231014 Local Network Access restrictions will start shipping by default in Chrome 142. As part of this change, local requests will be allowed to use HTTP in an HTTPS context (gated by a browser permission prompt). This will work automatically when the IP is provided directly, however in the case of IoT we often use the odoo-iot DNS domain to resolve the IP. In this case, you must specify the option `targetAddressSpace: "local"` in the `fetch` request. This PR simply adds this change where appropriate. As part of this we have also backported the change from jquery -> fetch. task-5157145 Forward-Port-Of: odoo/enterprise#97224 Forward-Port-Of: odoo/enterprise#96850
The home page search box is now marked so Bitwarden ignores it instead of treating it like a login or fillable field. This reduces distracting password manager prompts and makes the home screen search experience smoother for users.
Original PR description
For some reason, BitWarden picks up the textbox on the home page as fillable: <img width="853" height="219" alt="image" src="https://github.com/user-attachments/assets/4a3ef615-999a-4744-9274-a407b911df3a" />
Sending messages from Odoo to an IoT Box now happens without holding up the user's current action. This should make related workflows feel more responsive when connected devices are involved.
Original PR description
In order to avoid blocking code execution when sending websocket messages to the IoT Box from the client, we stopped waiting for the `send_message` call to complete. Forward-Port-Of: odoo/enterprise#97267
Warehouse teams can now choose which IoT printer is used for shipping labels instead of the system automatically picking the first suitable printer. This helps businesses route labels to the right printer by operation type and avoids confusing errors when a printer is not configured.
Original PR description
Printing shipping labels is performed from the backend, once the shipping info are received in the chatter. The printing command is sent to the frontend via the user bus, then though longpolling to the iot box. This commit adds the possibility to select a printer instead of choosing automatically the first (with the right report associated) on the list. As the change is made on a stable version, we are using system parameters to store the selected printer without adding a new field. We associate a printer with the picking type, in order for to be able to have different printers by default on different picking types. backport of odoo/enterprise#86818 Task: 4792491 Forward-Port-Of: odoo/enterprise#97396 Forward-Port-Of: odoo/enterprise#95794
Point of Sale settings now include a test button for Epson receipt printers, helping staff confirm printer setup before using it in daily operations. The test prints a sample receipt or shows a clear error, such as no paper or printer unreachable, and printing now has a 15-second timeout to avoid long waits.
Original PR description
This PR adds a test button to all the views in point of sale where the epos printer can be configured (pos config / res config and preparation printer) When clicked a test receipt is printed on the epos printer or else an error is shown like "no paper" / "failed to reach printer" etc. Finally it adds a timeout of 15s to Epos printing which isn't there now Task-5153542
Project action buttons now remain available for users who have not yet set up their own top bar preferences. When a user's configuration is missing, Odoo reuses the project manager's configuration so teams see the expected project actions without extra setup.
Original PR description
If the current user doesn't have a top bar configuration yet for a given project, we fallback on the top bar configuration of the project manager to show the actions. task-5072899 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
5 changes
Enhancements to existing features
Follow-up and customer statement reports now have a simplified header, centered title, and partner bank account details shown near the Tax ID. This makes the reports easier for customers to read and gives them key payment information in a clearer place.
Original PR description
This commit updates the layout for follow-up and customer statement reports. Changes made: --- **Follow-up & Customer Statement Reports:** - remove journal and filter details from header. - centered the title of the report. - Added the partner bank account display below the Tax ID. --- task-4823880
Swedish batch payments can now include both IBAN and BBAN, Bankgiro, or Plusgiro accounts in the same batch. When mixed account types are used, the system generates a ZIP file with separate XML payment files, reducing manual work and preventing blocked payment batches.
Original PR description
This commit add a new behaviour for batch payments in Sweden. Before this commit: batch payment with mixed payment for iban and bban/bankgiro/plusgiro wasn't allowed After this commit: now if the user create a batch payment with both type of account, we create a zip file with 2 xml files, one for iban and one for bban/bankgiro/plusgiro. Linked:https://github.com/odoo/odoo/pull/230104 [task-5107240](https://www.odoo.com/odoo/project/967/tasks/5107240)
Delivery order references no longer include the customer reference from the sales order. This prevents the customer reference from appearing twice on delivery slips and keeps order tracking clearer and more reliable when customer references change.
Original PR description
The origin field reliably tracks related orders, but including the customer reference caused issues: - The delivery slip displayed the customer reference twice. - Updating the customer reference in a sale order did not update the origin, making it unreliable for tracking. This change removes the customer reference from the origin, while keeping it structured for related orders. opw-5134111
This update adds the full set of 5% IGIC tax options and related fiscal positions for Spanish Canary Islands localization. It also corrects existing 5% tax records that were using an incorrect 3% rate or tax group, helping businesses apply the right tax treatment in accounting documents.
Original PR description
- Fix also some errors on the 5% taxes, where a 3 percent was applied or the group was not the right onw @jco-odoo --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update makes automated Chrome shutdown during testing more reliable when rare browser communication errors occur. It helps prevent stuck test builds and leftover browser processes, improving build infrastructure stability without changing user-facing features.
Original PR description
In some instances, Chrome can apparently fail CDTP calls with "Execution context was destroyed". According to the internet this mostly happens because of navigation events, here it's not clear if…
In some instances, Chrome can apparently fail CDTP calls with "Execution context was destroyed". According to the internet this mostly happens because of navigation events, here it's not clear if this is in response to `stop`-ing the page, or a pre-existing navigation directive interfereing with the stop-ing of the browser. I tried reproducing locally under the assumption that the `Page.stopLoading` might be the cause but got nowhere[^1]. This issue seems extremely infrequent, and in most cases is but a minor annoyance, an error appears on the corresponding build, and that's it. However if the error occurs during `ChromeBrowser.stop` then the browser is not terminated, which on runbot prevents the docker image from shutting down properly, and leaves zombie builds. Therefore make `ChromeBrowser.stop` more resilient to errors in the initial section so that we do terminate the browser even if the "graceful CDTP shutdown" fails. While at it, add a fallback to kill the browser if it does not terminate gracefully. https://runbot.odoo.com/odoo/error/233442 [^1]: and the error only happening in 18.0 and later when `Page.stopLoading` was present long before that makes it likely the proximal cause is in the code being run, especially as all the errors sampled from the builds list are related to pos and the failure are immediately preceded by ongoing HTTP requests Forward-Port-Of: odoo/odoo#232060
2 changes
Enhancements to existing features
Estonia VAT XML exports now process report data in batches instead of recalculating each line separately. This prevents timeouts on large reporting periods and helps businesses submit VAT reports reliably even with high transaction volumes.
Original PR description
Behavior before: When exporting the VAT report to XML, each newly added line triggered a fresh _compute_expression_totals_for_each_column_group call. With large volumes of journal items, this…
Behavior before: When exporting the VAT report to XML, each newly added line triggered a fresh _compute_expression_totals_for_each_column_group call. With large volumes of journal items, this resulted in excessive repeated queries and, for big datasets, timeout errors. Behavior after: Introduced _custom_unfold_all_batch_data_generator, which batches the computation of expression totals for all lines. Now, journal items are resolved in bulk and mapped back to their respective moves, significantly reducing redundant queries. The VAT XML export completes successfully, even on months with very large datasets. Root cause: The Estonia VAT report was missing a batch unfold method (_custom_unfold_all_batch_data_generator). Without it, the system executed totals computation for each line individually instead of in batch, causing major performance degradation. Benchmark: | Period size (journal items) | Before patch | After patch | |----------------------------------------|----------------------|--------------------| | ~15k | 7s | 5s | | ~200k+ | Timeout error| 21s | opw-5046077
This update makes automated test browser shutdown more resilient when Chrome reports rare shutdown errors. It helps prevent stalled build environments and leftover browser processes, improving reliability for the development and testing pipeline.
Original PR description
In some instances, Chrome can apparently fail CDTP calls with "Execution context was destroyed". According to the internet this mostly happens because of navigation events, here it's not clear if…
In some instances, Chrome can apparently fail CDTP calls with "Execution context was destroyed". According to the internet this mostly happens because of navigation events, here it's not clear if this is in response to `stop`-ing the page, or a pre-existing navigation directive interfereing with the stop-ing of the browser. I tried reproducing locally under the assumption that the `Page.stopLoading` might be the cause but got nowhere[^1]. This issue seems extremely infrequent, and in most cases is but a minor annoyance, an error appears on the corresponding build, and that's it. However if the error occurs during `ChromeBrowser.stop` then the browser is not terminated, which on runbot prevents the docker image from shutting down properly, and leaves zombie builds. Therefore make `ChromeBrowser.stop` more resilient to errors in the initial section so that we do terminate the browser even if the "graceful CDTP shutdown" fails. While at it, add a fallback to kill the browser if it does not terminate gracefully. https://runbot.odoo.com/odoo/error/233442 [^1]: and the error only happening in 18.0 and later when `Page.stopLoading` was present long before that makes it likely the proximal cause is in the code being run, especially as all the errors sampled from the builds list are related to pos and the failure are immediately preceded by ongoing HTTP requests