Daily updates from Odoo
Navigate
Branch
Tuesday, October 21, 2025
204 changes
12 changes
Resolved issues and error corrections
This update allows files, such as images, to be processed before they are uploaded. This helps reduce oversized image storage and can keep the database leaner without changing the user's upload flow.
Original PR description
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#231899 Forward-Port-Of: odoo/odoo#226611
App icons created in Studio are now automatically resized before being saved. This prevents oversized images from increasing database size, cache usage, and request payloads, helping keep the system more efficient without changing the user workflow.
Original PR description
Before this commit, the IconCreator images were sent as is in their full size. Downstream it was problematic because apps' icons were bigger than necessary, bloating the different caches, the database, and the request. After this commit, icon are resized to a max of 64x64 pixels. Forward-Port-Of: odoo/enterprise#97626 Forward-Port-Of: odoo/enterprise#94480
Fixes a checkout issue where quickly navigating back and changing the delivery address could show an error instead of continuing smoothly. Customers are now safely redirected to the shop when the cart is no longer available, reducing failed checkout experiences and support incidents.
Original PR description
Currently, an error occurs when the user changing the delivery address in the website. **Steps to reproduce:** - Install the `website_sale` module and enable the `Demo` payment provider. - Go to `Website` > `Shop` > `Add a product to Cart` > `View cart` > `Checkout`. - Ensure there are at least two different delivery addresses > `Confirm` > `Pay now`. - Quickly press the browser’s `back button` twice. - Select a different `delivery address`. **Error:** `ValueError: Expected singleton: sale.order()` **Root Cause:** At [1], the code calls `order.ensure_one()`. When the cart (`sale.order`) is empty, leads to an `error`. **Fix:** This commit prevents a traceback on the frontend when a user attempts to change the delivery address and safely redirects them to the shop page. [1]: https://github.com/odoo/odoo/blob/88c9a45ee1ff8dde871865723c3387c059af8289/addons/delivery/models/delivery_carrier.py#L157 sentry-6869972801 Forward-Port-Of: odoo/odoo#226781
This fixes an issue in Italian Point of Sale where enabling the cash drawer could prevent the fiscal receipt from printing correctly during a sale. Businesses using Italian fiscal printers can now complete sales with the cash drawer option enabled and still receive the required printed receipt.
Original PR description
Pull request https://github.com/odoo/enterprise/pull/91412 attempted to fix an issue related to printing the receipt with the italian fiscal printer. That PR forgot to handle the cash drawer correctly. This Pr fixes that. It is essentially a backport of commit 32b5651. Steps to reproduce: 1. clean DB 2. setup an italian POS 3. configure the printer 4. in the POS settings, tick the box "cash drawer" 5. attmept to make a sale After this commit, the receipt is correctly printed. opw-4882480 Forward-Port-Of: odoo/enterprise#97379
Mobile self-order customers now see the correct order after placing a new order, instead of being shown a previous paid order. Receipts also remain accurate after refreshing the page, including the correct payment details, reducing confusion for customers and staff.
Original PR description
This PR contains 2 small fixes for mobile self order: - **[FIX] pos_self_order: wrong order on confirmation screen** Steps to reproduce: 1. Configure a Self Order POS to use QR menu + ordering 2. In…
This PR contains 2 small fixes for mobile self order:
- **[FIX] pos_self_order: wrong order on confirmation screen**
Steps to reproduce:
1. Configure a Self Order POS to use QR menu + ordering
2. In the mobile menu, make an order and confirm
3. The confirmation screen shows order S001, pay at the counter
4. In the POS, pay and validate the order
5. In the mobile menu, make another order and confirm
Expected behaviour:
- The confirmation screen shows order S002, pay at the counter
Actual behaviour:
- The confirmation screen shows order S001, already paid
The cause of this is that `selectedOrderUuid` is cleared whenever the
`getUserDataFromServer` method is called, even if the server doesn't
return an order to replace it with. The self order service then tries
to find the current order and takes the previously paid order instead of
the new order.
To fix this, we simply don't clear `selectedOrderUuid`. It will still be
overwritten if the server does return new order data.
- **[FIX] pos_self_order: incorrect receipt after refresh**
Steps to reproduce:
1. Configure a Self Order POS to use QR menu + ordering
2. Make an order in the mobile menu
3. Pay and validate the order in the POS using the 'Card' payment method
4. Go to 'My Orders' in the mobile menu, and download the receipt
5. Observe the correct 'Card' payment line is shown on the receipt
6. Refresh the page
7. Download the receipt again
Expected behaviour:
- The downloaded receipt is the same as the first one, with the 'Card'
payment line.
Actual behaviour:
- The downloaded receipt has no payment lines, so it just shows a
negative 'Change' line at the end.
The cause of this issue is that the payment lines and payment methods
used to render the receipt were not being persisted in the indexed DB.
The fix is simply to add these models to the data service options so
that they also get saved locally.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#232314
Forward-Port-Of: odoo/odoo#231910Payment registration now looks at the customer linked to the invoice instead of the company partner on the accounting line. This ensures saved payment methods are offered correctly when creating later invoices for the same customer, reducing failed or manual payment handling.
Original PR description
Currently, when user A from company AA records a payment method, a payment token is stored for that user. However, when an invoice is issued for that user, the payment token cannot be used because the payment registration form uses the partner AA instead of the user linked to the move, partner A. Step to reproduce: 1. Create a user A in company AA 2. Create an invoice for user A 3. Register a payment on the invoice and save the payment method (token) 4. Create another invoice for user A 5. Try to register a payment on the invoice: the payment token is not proposed This fix updates the logic to use the user linked to the move instead of the partner on the line, allowing proper selection of a payment token. opw-5036106 Forward-Port-Of: odoo/odoo#232134 Forward-Port-Of: odoo/odoo#230105
Invoices paid with a partial payment within tolerance will no longer be automatically closed as fully paid. This keeps the invoice marked as partially paid so users can decide how to handle the remaining balance.
Original PR description
Prevents the system from creating a write-off and marking an invoice as 'Fully Paid' when a partial payment (within tolerance) is reconciled from the invoice form. The invoice status will now correctly remain 'Partially Paid', giving the user control over the remaining balance. task-5114658 Forward-Port-Of: odoo/enterprise#95899
Point of Sale now correctly applies quantity-based pricelist rules when the same lot-tracked product is split across multiple lots. This ensures customers receive the intended price once the combined quantity reaches the discount threshold, improving pricing accuracy at checkout.
Original PR description
**PROBLEM** Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot…
**PROBLEM** Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot A, and 3 product from lot B, a rule defining the price for a minimum quantity of 5 will not trigger (it should). **STEP TO REPRODUCE** 1. install pos 2. create a lot tracked product 3. create a pricelist rule for the product, with a price based on min qty 4. from the pos, order the min qty but split it accross multiple lots 5. price will not takethe rule into account **CAUSE** Order line of lot tracked products are never merged. The quantity used to compute if a pricelist trigger is the quantity of each line individually. **FIX** For lot tracked product, to determine the price of a line, we parse find all corresponding lines and add their quantities together. Then we update all of their prices. To know if we should take into account a line, we verify if they would have been merged, if their product wasn't lot tracked. **REMARK** Ideally, their would be a way to merged order line of lot tracked product, while being able to edit the quantity taken from each lot directly from the pos. From now, order line doesn't work well with multiple lots, and it would require unstable change on the db. opw-4751920 Forward-Port-Of: odoo/odoo#232276 Forward-Port-Of: odoo/odoo#219110
This update improves the spacing of menu-related settings shown in debug mode for event website pages. The clearer layout makes it easier for administrators to match each label with its field when configuring event page menu tabs.
Original PR description
The PR fixes the display of the fields displayed when the debug mode is activated and used to show buttons in the menu of event website pages. Previously, it was difficult to determine what were the labels of the fields. To make it clearer, the spaces between the label-field couples have been increased. Task-4750239 Forward-Port-Of: odoo/odoo#214135
Changing the shape of a GIF image in the editor no longer causes an error. This improves reliability for users editing website or HTML content with animated images.
Original PR description
Steps to reproduce: =================== 1- Add an image of type GIF. 2- Try to change its shape. → Traceback occurs. Cause: ====== The `process` image function can return a callback function when GIF…
Steps to reproduce:
===================
1- Add an image of type GIF.
2- Try to change its shape.
→ Traceback occurs.
Cause:
======
The `process` image function can return a callback function when GIF transformation must be skipped:
https://github.com/odoo/odoo/blob/7f95cc6094b914c57b6e36ad072ebb2c9c3b324b/addons/html_editor/static/src/main/media/image_post_process_plugin.js#L78
It can also return an object `{ url, newDataset }`: https://github.com/odoo/odoo/blob/7f95cc6094b914c57b6e36ad072ebb2c9c3b324b/addons/html_editor/static/src/main/media/image_post_process_plugin.js#L224
Only the object case was handled:
https://github.com/odoo/odoo/blob/7f95cc6094b914c57b6e36ad072ebb2c9c3b324b/addons/html_editor/static/src/main/media/image_post_process_plugin.js#L231
As a result, when a function was returned, the image source was set to `null`, because `processed` was a function and didn't have a `url` or `newDataset`, causing a crash here:
https://github.com/odoo/odoo/blob/22c83301337e40699b11621053af627f5bfd505b/addons/html_builder/static/src/plugins/image/image_shape_option_plugin.js#L412
Solution:
=========
Ensure that only the `url` and `dataset` are returned, since the same
function is called elsewhere expecting those values.
opw-5137667
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThe Planning and Timesheet Analysis report now calculates planned and remaining hours using each employee's actual working schedule, rather than assuming a standard Monday-to-Friday week. This makes reports more accurate for employees with part-time or non-standard calendars.
Original PR description
To reproduce: ============= - set the company calendar to 40h/week (Mon to Fri) - create an employee with a 32h/week working schedule (doesn't work on Fri) - on planning app, create a shift for this employee for ex from 01/09 to 15/09 with 2h allocated - go to Planning / Timesheet Analysis report and check report for this employee on september -> planned hours and remaining hours are wrong Problem: ======== when querying the data for the desired period, we divide the allocated hours by the number of weekdays (Mon to Fri) in the period, but we should divide by the number of working days according to the employee's working schedule Solution: ========= we compute the number of working days based on the resource calendar of the employee and use this number to compute the planned hours and remaining hours opw-5008066 Forward-Port-Of: odoo/enterprise#95115
Documentation and clarification updates
The contributor agreement records were updated to include Acsone and Tobias Zehntner. This keeps Odoo's legal contributor documentation current and confirms contribution rights for future work.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232278
13 changes
Resolved issues and error corrections
Customers who navigate back during checkout and choose another delivery address are now handled safely instead of seeing an error page. If the cart is no longer available, the shopper is redirected back to the shop, reducing checkout disruption and support incidents.
Original PR description
Currently, an error occurs when the user changing the delivery address in the website. **Steps to reproduce:** - Install the `website_sale` module and enable the `Demo` payment provider. - Go to `Website` > `Shop` > `Add a product to Cart` > `View cart` > `Checkout`. - Ensure there are at least two different delivery addresses > `Confirm` > `Pay now`. - Quickly press the browser’s `back button` twice. - Select a different `delivery address`. **Error:** `ValueError: Expected singleton: sale.order()` **Root Cause:** At [1], the code calls `order.ensure_one()`. When the cart (`sale.order`) is empty, leads to an `error`. **Fix:** This commit prevents a traceback on the frontend when a user attempts to change the delivery address and safely redirects them to the shop page. [1]: https://github.com/odoo/odoo/blob/88c9a45ee1ff8dde871865723c3387c059af8289/addons/delivery/models/delivery_carrier.py#L157 sentry-6869972801 Forward-Port-Of: odoo/odoo#226781
Spanish Facturae invoice XML now uses the correct total tax amount when global tax rounding is enabled. This prevents mismatches between invoice totals and the electronic invoice file, reducing the risk of rejected or inaccurate e-invoices.
Original PR description
When `l10n_es_edi_facturae` is installed, creating an invoice with 25 identical lines (price_unit: 230.83, quantity: 1, tax: 21%) and global tax rounding enabled results in: - Untaxed amount: 5770.75 - Tax amount (globally rounded): 1211.86 However, the generated Facturae XML incorrectly reports `TotalTaxOutputs` as 1211.75, as if tax was rounded per line. This was caused by the `_l10n_es_edi_facturae_export_facturae` method which round lines individually before the summing them even if the rounding method is global. opw-5111038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix adjusts Swiss payroll employee views so payroll data can be handled correctly in environments with more than one company or country. It helps businesses using Odoo payroll in Switzerland avoid configuration or visibility issues when operating across multiple entities.
Original PR description
task-5159023 Forward-Port-Of: odoo/enterprise#97489 Forward-Port-Of: odoo/enterprise#96733
This fixes an issue where saved payment methods were not offered when registering payment for an invoice tied to an individual contact within a company. The payment form now uses the invoice's actual customer, helping users reuse stored payment details correctly.
Original PR description
Currently, when user A from company AA records a payment method, a payment token is stored for that user. However, when an invoice is issued for that user, the payment token cannot be used because the payment registration form uses the partner AA instead of the user linked to the move, partner A. Step to reproduce: 1. Create a user A in company AA 2. Create an invoice for user A 3. Register a payment on the invoice and save the payment method (token) 4. Create another invoice for user A 5. Try to register a payment on the invoice: the payment token is not proposed This fix updates the logic to use the user linked to the move instead of the partner on the line, allowing proper selection of a payment token. opw-5036106 Forward-Port-Of: odoo/odoo#232134 Forward-Port-Of: odoo/odoo#230105
Payroll now checks the correct document template separately for each payslip, even when no template is available in some cases. This helps prevent incorrect or missing payroll document generation when processing multiple payslips.
Original PR description
Since the function that will return the template can return None in some cases, we need to check for each payslip what is the template.
This fix improves the spacing between labels and fields in event website menu settings shown in debug mode. It makes it easier for administrators to understand which option belongs to which label when configuring event page menus.
Original PR description
The PR fixes the display of the fields displayed when the debug mode is activated and used to show buttons in the menu of event website pages. Previously, it was difficult to determine what were the labels of the fields. To make it clearer, the spaces between the label-field couples have been increased. Task-4750239 Forward-Port-Of: odoo/odoo#214135
This change removes a browser-specific setting from local IoT device requests in Point of Sale because it caused errors in older Chrome versions and was not needed for Odoo's secure connections. It helps keep POS hardware and customer display interactions working consistently without changing business workflows.
Original PR description
This reverts commit 1a934ae which added the `"targetAddressSpace": local` option to IoT fetch requests. This is because of two reasons: 1. It caused errors on older versions of Chrome that implemented the obsoleted 'Private Network Access' standard. 2. It was not actually required in the first place, it is only needed in situations where a HTTP resource is accessed from HTTPS using a domain that resolves to a local IP. In Odoo we only ever do this for HTTPS -> HTTPS requests, where it works automatically. 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#232289 Forward-Port-Of: odoo/odoo#232110
This update removes an unnecessary browser request setting used when connecting Odoo Point of Sale to local IoT hardware. It helps avoid connection errors in older Chrome versions while keeping existing secure local device communication working as expected.
Original PR description
This reverts commit 6d09dc6 which added the `"targetAddressSpace": local` option to IoT fetch requests. This is because of two reasons: 1. It caused errors on older versions of Chrome that implemented the obsoleted 'Private Network Access' standard. 2. It was not actually required in the first place, it is only needed in situations where a HTTP resource is accessed from HTTPS using a domain that resolves to a local IP. In Odoo we only ever do this for HTTPS -> HTTPS requests, where it works automatically. task-5157145 Forward-Port-Of: odoo/enterprise#97624 Forward-Port-Of: odoo/enterprise#97500
The Documents app now correctly responds when users turn debug mode on or off from the command palette. This keeps navigation links accurate and avoids confusion when switching modes without manually editing the URL.
Original PR description
Issue: In the documents app toggling debug mode through the command palette (ctrl-k) does not work. Manually editing the URL works as expected. Cause: A patch on `router.stateToUrl` for the documents app rebuilds the URL to create clean, shareable links. When doing so, it attempted to preserve the debug status by referencing the global `odoo.debug`. This global object did not reflect client-side state changes. The command palette correctly provides the intended future state to the router. The patch was ignoring this incoming state and using the outdated global value, causing the generated URL to be incorrect. Solution: Modify the patch to use the `state` argument provided to `stateToUrl`, which contains the correct, up-to-date information for the navigation. Task-5095056 Forward-Port-Of: odoo/enterprise#96275
The returns wizard now generates all applicable returns from the opening date chosen by the user, instead of limiting results to the current fiscal year. This helps businesses produce complete return periods when starting or reopening accounting from a specific date.
Original PR description
If the user generates the returns with the wizard of the opening date, he expects to generate all the returns from this date, and not just for the current fiscal year like it used to be. backport of a request of task 5030701
The Accounting journal dashboard cards now have a slightly taller minimum height. This makes cards without graphs better align with those that include graphs, creating a cleaner and less confusing dashboard layout.
Original PR description
The min height for the kanban journal dashboard in Accounting makes it looks currently like this is an unwanted behavior. This PR slightly increase it to match the cards having graphs on it. task-4792156 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
A new action is available on the accounting returns screen so users can create returns directly when needed. This makes the process easier and avoids relying only on automated or indirect creation flows.
Original PR description
Add a new button on the returns view to create new returns. task-4627315
Documentation and clarification updates
The contributor list has been updated to include Acsone and Tobias Zehntner after confirming the required contributor agreement. This keeps Odoo's contribution records current for legal and compliance purposes.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232278
3 changes
Resolved issues and error corrections
This fix improves how product image fetch jobs are scheduled by replacing a fragile duplicate-check mechanism with a safer cleanup before scheduling. It reduces unnecessary processing overhead and helps ensure image fetch timing works as intended, especially when multiple records are handled at once.
Original PR description
Remove `_check_image_cron_is_not_already_triggered` because: - It doesn't work in batch mode due to `self.cron_id.id`. - It increases the cost of creating a cron trigger because the reference lookup (`ref`) makes at least one extra query. (We want to keep cron trigger creation efficient since it is used everywhere.) - Because of this constraint, there is an extra commit in `_trigger_fetch_images_cron` that is inefficient and error-prone, serving no purpose. Keep the intended effect of the constraint by removing the existing cron trigger before the new one is created, ensuring the time offset is respected.
This fixes an issue where users could not turn debug mode on or off from the command palette while using the Documents app. The app now uses the latest navigation state when building links, so the debug setting updates correctly without requiring manual URL changes.
Original PR description
Issue: In the documents app toggling debug mode through the command palette (ctrl-k) does not work. Manually editing the URL works as expected. Cause: A patch on `router.stateToUrl` for the documents app rebuilds the URL to create clean, shareable links. When doing so, it attempted to preserve the debug status by referencing the global `odoo.debug`. This global object did not reflect client-side state changes. The command palette correctly provides the intended future state to the router. The patch was ignoring this incoming state and using the outdated global value, causing the generated URL to be incorrect. Solution: Modify the patch to use the `state` argument provided to `stateToUrl`, which contains the correct, up-to-date information for the navigation. Task-5095056 Forward-Port-Of: odoo/enterprise#96275
This fix ensures Italian point-of-sale receipts are printed correctly when the cash drawer option is enabled. It prevents sales from being disrupted for businesses using Italian fiscal printers with connected cash drawers.
Original PR description
Pull request https://github.com/odoo/enterprise/pull/91412 attempted to fix an issue related to printing the receipt with the italian fiscal printer. That PR forgot to handle the cash drawer correctly. This Pr fixes that. It is essentially a backport of commit 32b5651. Steps to reproduce: 1. clean DB 2. setup an italian POS 3. configure the printer 4. in the POS settings, tick the box "cash drawer" 5. attmept to make a sale After this commit, the receipt is correctly printed. opw-4882480 Forward-Port-Of: odoo/enterprise#97379
27 changes
New functionality added to Odoo
Users can now generate product images using AI directly from product workflows and AI chat. This helps businesses create or refine product visuals faster, including using reference images to guide the result.
Original PR description
task-5153576 See also: - https://github.com/odoo/odoo/pull/230661
Enhancements to existing features
Updates Luxembourg payroll settings to reflect the 2025 minimum social salary and related employee tax credits. This helps businesses calculate payroll in line with the latest official Luxembourg social security and tax parameters.
Original PR description
Sources: - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202501.pdf - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202505.pdf task-5176255 Forward-Port-Of: odoo/enterprise#97468
This update refines how manufacturing planning calculates monthly demand by using exact date ranges, improving accuracy for purchasing and production suggestions. It also streamlines field service product catalog navigation and internal data handling, making the back button behavior clearer and the catalog code easier to maintain.
Company-wide return deadline settings have been removed because deadlines can now be managed directly on each return type. This gives customers more precise control over filing timelines across accounting reports and country-specific returns.
Original PR description
The field deadline on the company is now removed as customers have now a way to override the deadline on the return type directly. task-5153900
The appraisal form now gives employee and manager feedback sections more usable space. This makes longer appraisal comments easier to read and reduces wasted space from the previous scrollbar styling.
Original PR description
Make the Employee/Manager feedback areas feel roomier and remove the visual inset on their scrollbars. This improves readability of long appraisals and avoids wasted space. task-5176134
Odoo Studio now lets users drag existing selection or stage-like fields onto a form status bar instead of creating only a new selection field. This makes stage setup more flexible and allows better ordering in grouped views, especially when using related stage records.
Original PR description
Before this commit, to add a StatusBar (stages) in a form view, one had to click on the form's editor hook. After some configuration it added a Selection field with some selection values setup by the user. The problem with selection values is that there are ordered lexicographically on the value in the column, that is the technical value of the selection value's tuple. Hence, in a grouped kanban (or list -- via a web_read_group) the groups could not have another order. After this commit, the StatusBar hook behaves as a droppable hook and one can drag and drop a selection field or a many2one, allowing for their respective configuration. If a many2one serves as the field underlying the statusbar, a button allows the user to add records, i.e. stages. task-4744988
This update adds country-specific EC Sales List and Intrastat reporting rules for Austria, Germany, the Netherlands, Italy, Poland, and Portugal. Businesses in these countries can better track required filing deadlines and periodicities directly in Odoo, supporting more accurate tax and trade compliance.
Original PR description
Following the implementation of the Tax returns feature in 18.3 which was focused on the general implementation and Belgium, we want to add the specification for other country and in this case Austria, Germany, The Netherlands, Italy, Poland, and Portugal. Adding EC sales list, Intrastat specific deadlines and periodicities. task-4776236
Studio now stores pipeline stages in a way that preserves their intended order, so kanban columns appear consistently and empty stages remain visible. This improves pipeline setup and editing, including statusbar display and option handling in the form editor.
Original PR description
**Before this PR:** In studio, the pipeline statusbar was modeled as a field selection which prevented the order of the stages to be used to order kanban columns correctly. **After this PR:** The pipeline statusbar is now modeled as a Many2one field pointing to a new model created when adding the statusbar to the form view. This allows the kanban view to be ordered correctly. The edition of the statusbar also works when the model is created with the pipeline option checked. Moreover, when a kanban column is empty, it is still displayed which prevent the user to be prompted for the creation of new stages. **This PR also introduces 2 fixes:** - All statusbar options are parsed when using the add operation. - The statusbar widget is now rendered correctly in the form editor. task-4744988
Argentina IVA Simple tax report exports are now handled directly in the main Argentine reporting module instead of a separate add-on. This simplifies module management while keeping the report export and related tests available for users who need Argentine VAT reporting.
Original PR description
In fe77a6b we merged a new module in stable to be able to support the export of IVA Simple Tax Reports for Argentina. This is no longer necessary in master, as such, the model data for activities have been merged into `l10n_ar` in community, and all of the tests and report exports have been moved to `l10n_ar_reports` in enterprise. task-5027104
The SEPA Direct Debit mandate form has been simplified to show only the most relevant information to everyday users. Date handling, bank account guidance, and scheme explanations are clearer, helping staff complete mandates with less confusion.
Original PR description
- Show identifier only in debug mode. - Use Date Range for start and end date with 'Indefinite' as placeholder. - Placeholder for partner bank 'Provided by customer'. - Make SDD scheme optoins clearer and adding useful help. task-5159986
Users can now copy alias email addresses directly from relevant configuration screens. This makes it faster and less error-prone to share or reuse incoming email aliases for helpdesk, PLM, and quality workflows.
Original PR description
This PR made the following changes: - Add the alias_email field to the view, using the `CopyClipboardButton` widget to enable copying the alias email to the clipboard. - Added the custom CSS using the `copy_alias_email` class to hide the copy icon provided by the `CopyClipboardButton`. - Also, make sure that alias_name, alias_domain_id, and the copy button appear on the same line. - Also removed some classes from the field and div, and used row col instead of them to align fields properly in a single line. Task-4812573
Uruguayan electronic invoices can now correctly identify and report VAT rates outside the standard exempt, minimum, and basic categories. This improves compliance by adding the required reduced-rate totals and line indicators in the XML, plus a dedicated tax grid for 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#97640
Forward-Port-Of: odoo/enterprise#91392Resolved issues and error corrections
Icons created in Studio are now reduced to a maximum of 64 by 64 pixels before being saved. This keeps app icons lightweight, reducing storage, cache size, and request overhead without changing how users create icons.
Original PR description
Before this commit, the IconCreator images were sent as is in their full size. Downstream it was problematic because apps' icons were bigger than necessary, bloating the different caches, the database, and the request. After this commit, icon are resized to a max of 64x64 pixels. Forward-Port-Of: odoo/enterprise#97626 Forward-Port-Of: odoo/enterprise#94480
The spreadsheet sale management field sync now handles undo and redo actions without crashing. This improves reliability for users editing linked sales spreadsheet data and reviewing version history.
Original PR description
Fix an issue where field sync would crash when used with UNDO/REDO. Task: 4854879 Forward-Port-Of: odoo/enterprise#97424 Forward-Port-Of: odoo/enterprise#92883
This fix adds the missing payroll group setting to several Swiss payroll employee fields. It helps ensure those payroll details are correctly organized and displayed, reducing configuration or validation issues during payroll processing.
Original PR description
The payroll group was missing on some payroll fields. Related runbot issue: https://runbot.odoo.com/odoo/runbot.build.error/233445 task-5179821 Forward-Port-Of: odoo/enterprise#97611
Updated an HR Payroll automated test so it remains reliable with newer Chrome browser behavior. This helps keep payroll development checks stable and avoids false test failures unrelated to product functionality.
Original PR description
Since either 140 or 141[^0] Chrome uses compact serialization rules for text-decoration, as a result of w3c/csswg-drafts#12486. This was merged [on August 12th][CL-6824265] and Chrome 139 was cut on August 5 so couldn't have had this change. The new serialization rule means values which can be ommitted from a shorthand (default or fallback) should be, so the default `text-decoration-line` and a `text-decoration-color` matching the `color` won't be serialized in `text-decoration` anymore. Instead of matching the shorthand, match the actual stored properties. [^0]: 140 was not deployed on chrome next so it may or may not have been broken then [CL-6824265]: https://chromium-review.googlesource.com/c/chromium/src/+/6824265 Forward-Port-Of: odoo/enterprise#97667
Ecuadorian XML vendor bill imports now read discount amounts and apply the matching discount percentage in Odoo. This prevents imported bills from overstating line amounts when supplier XML files include discounts.
Original PR description
In the l10n_ec_edi localization, XML files that include a <descuento> (discount) tag do not apply the discount when imported into Odoo. - Create an invoice with a discount and export the XML. - Re-import the XML as a vendor bill — the discount is missing. This commit fixes the issue by computing and importing the discount percentage from the <descuento> tag. opw-5137439 Forward-Port-Of: odoo/enterprise#96712
Refreshing appointment availability for a selected staff member no longer triggers an error when checking capacity. This helps customers and staff continue booking appointments smoothly without interruption.
Original PR description
This commit fixes an issue where the refresh with appointment based on staff user was raising a traceback as it also tried to compute the max capacity possible. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5118860 Forward-Port-Of: odoo/enterprise#97634 Forward-Port-Of: odoo/enterprise#95862
This fix prevents automated receipt scanning from replacing an expense name that a user has already edited after upload. It also makes the OCR status banner appear immediately after adding an attachment, so users get clearer feedback without refreshing the page.
Original PR description
This commit https://github.com/odoo/odoo/commit/ca1f644a3c15f17482f56a2ece2a57f0f03098ff introduced the "untitled expense" title for expense when being uploaded. The user can then change manually the name. However, if the OCR is called after, it overrides the name previously set by the user. Therefore, if the name of an expense starts with "Untitled Expense", the OCR should not override the name. In addition, when uploading an expense on the form view, the OCR banner used to be not visible until the page was refreshed. This banner is now displayed directly after uploading the attachment. task-4684825
The Planning / Timesheet Analysis report now calculates planned and remaining hours using each employee's actual working schedule instead of assuming a standard Monday-to-Friday week. This makes reporting accurate for part-time employees or staff with non-standard days, helping managers rely on the report for capacity and workload decisions.
Original PR description
To reproduce: ============= - set the company calendar to 40h/week (Mon to Fri) - create an employee with a 32h/week working schedule (doesn't work on Fri) - on planning app, create a shift for this employee for ex from 01/09 to 15/09 with 2h allocated - go to Planning / Timesheet Analysis report and check report for this employee on september -> planned hours and remaining hours are wrong Problem: ======== when querying the data for the desired period, we divide the allocated hours by the number of weekdays (Mon to Fri) in the period, but we should divide by the number of working days according to the employee's working schedule Solution: ========= we compute the number of working days based on the resource calendar of the employee and use this number to compute the planned hours and remaining hours opw-5008066 Forward-Port-Of: odoo/enterprise#95115
This fixes automated test behavior by skipping an Early Payment Discount scenario when the full accounting app is not installed. It prevents false test failures in batch payment checks, helping keep validation results reliable without changing business functionality.
Original PR description
Some new tests would test for the application of Early Payment Discounts in the bank reconciliation widget, but without the accountant module installed, that doesn't make much sense as a payment with move is automatically created for those cases, rendering the test useless. runbot error 233509
This update prevents batch payment tests from failing when the Accountant module is not installed. It improves test reliability across different system setups without changing business features or user workflows.
Original PR description
Issue: some tests may fail when "accountant" module is not installed. Solution: Handle the case when "accountant" module is not installed separately as it is done in previous versions. runbot-231231,231238
The Documents app now correctly updates debug mode when users use the command palette shortcut. This avoids confusion where the URL did not reflect the requested mode unless edited manually.
Original PR description
Issue: In the documents app toggling debug mode through the command palette (ctrl-k) does not work. Manually editing the URL works as expected. Cause: A patch on `router.stateToUrl` for the documents app rebuilds the URL to create clean, shareable links. When doing so, it attempted to preserve the debug status by referencing the global `odoo.debug`. This global object did not reflect client-side state changes. The command palette correctly provides the intended future state to the router. The patch was ignoring this incoming state and using the outdated global value, causing the generated URL to be incorrect. Solution: Modify the patch to use the `state` argument provided to `stateToUrl`, which contains the correct, up-to-date information for the navigation. Task-5095056 Forward-Port-Of: odoo/enterprise#96275
This update adjusts demo employee signatures so names use a cleaner layout by default. It avoids extra spacing that previously appeared in signatures, reducing manual cleanup for users setting up or reviewing these records.
Original PR description
Adapt signatures for Laurie Poiret and Maggie Davidson so that they are wrapped in a `<div>` instead of a `<p>`, because lxml `document_fromstring` would wrap text content in a `p` during record creation. Ideally all user data records should do that for their signature field. This commit only updates the main ones. `p` in a signature is not desired because it has a native margin-bottom, and the user has to change it to a `div` in order not to have it. Making `div` the default container for signatures simplifies that tedious process. task-5149570 Forward-Port-Of: odoo/enterprise#97229
Fixes an issue where a bank payment that only covered part of an invoice could incorrectly mark the full invoice as paid. Payments are now applied only up to the transaction amount, preventing incorrect suspense balances and improving accounting accuracy.
Original PR description
Steps: - Have a payment term making 3 installments (33.33%, 33.33% and 33.34%) - Create and confirm an invoice for $200 with the previously created payment term - Create a bank transaction for $90…
Steps: - Have a payment term making 3 installments (33.33%, 33.33% and 33.34%) - Create and confirm an invoice for $200 with the previously created payment term - Create a bank transaction for $90 -------- Option 1 -------- - Reconcile the statement line with the three invoice lines from the reconcile button on the stmt line itself -------- Option 2 -------- - From the invoice, add the stmt line from the outstanding payments widget -> The invoice is marked as fully paid and the bank entry looks like this: | account | debit | credit | | ------- | ----- | ------ | | Bank account | 90.00 | 0.00 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 66.68 | | Suspense account | 110.00 | 0.00 | It should look like this: | account | debit | credit | | ------- | ----- | ------ | | Bank account | 90.00 | 0.00 | | Receivable account | 0.00 | 66.66 | | Receivable account | 0.00 | 23.34 | This is because we're calculating the partial amount only when looping over the last move line, which result with no partial amount since the transaction amount is already exceeded, therefore we end up adding all the line and balancing it with the suspense account line, which is wrong. With this commit, we add some conditions to check wether the amount is exceeded or will be exceeded, and we calculate the partial amount accordingly. opw-5076498 Forward-Port-Of: odoo/enterprise#97632 Forward-Port-Of: odoo/enterprise#96847
Code cleanup and technical improvements
VoIP and WhatsApp now rely on a shared stored user reference instead of separate user lookups. This keeps the underlying communication features aligned with the main platform and reduces maintenance risk without changing the visible user experience.
Original PR description
Enterprise counter-part. task-5173021 https://github.com/odoo/odoo/pull/232173
This update applies automated linting cleanup across the VoIP interface and related tests. It helps keep the codebase consistent and easier to maintain without changing day-to-day user workflows.
31 changes
Enhancements to existing features
Payment terminals will no longer be automatically registered for event handling because they already manage their own events. This reduces unnecessary background handling and helps keep IoT payment terminal behavior clearer and more reliable.
Original PR description
As for printers that can send event whenever they want, payment terminals handle event themselves. We then removed auto event registering for payment terminals. odoo/enterprise#97617 Forward-Port-Of: odoo/odoo#232282
Point of Sale payment terminals connected through IoT can now use newer connection methods in addition to the existing fallback. This improves communication flexibility and can help make terminal interactions more reliable across different network setups.
Original PR description
As for any other actions sent from the db to the IoT Box, we updated payments terminals logic to use the `iot_http` service in order to allow them using webrtc and websocket in addition to longpolling. Backport of odoo/enterprise#92896 (`iot_http` service refactoring only, to allow listening without sending action) Backport of odoo/enterprise#96634 odoo/odoo#232282 Forward-Port-Of: odoo/enterprise#97617
The website editor now detects when a browser or device cannot support WebGL and disables image filters instead of showing an error. This keeps editing stable for users on affected Linux Chrome versions or systems without usable graphics support, while clearly indicating why image filters are unavailable.
Original PR description
On recent versions of Chrome for Linux (v140+), the old SwiftShader software fallback for WebGL has been removed. As a result, new window.WebGLImageFilter() now throws if no GPU context is available, typically when WebGL is disabled or unsupported. Since the application cannot enable WebGL from JavaScript, this commit improves the user experience by detecting the absence of a WebGL context early and disabling image filters in edit mode. Instead of raising a traceback, the editor now skips the filter feature and can optionally display a friendly message explaining that WebGL is required to use image filters. This avoids runtime errors and ensures a more robust behavior on platforms where WebGL is unavailable. task-5117584 Forward-Port-Of: odoo/odoo#232009 Forward-Port-Of: odoo/odoo#229705
Manufacturing planning now calculates monthly product demand using the exact date range being analyzed instead of a broad preset label. This makes forecasts slightly more precise and consistent with the stock movements included, while related field service catalog code was cleaned up for better maintainability.
Original PR description
Changes the context keys used in the compute of product.product monthly demand from a string "suggest_based_on" to 2 datetime objects, the start and end date from which to consider moves. see odoo/odoo#225721 Some values from the test are changed (also some relevant changes in this previous commmit odoo/odoo#0a022c0777). The discrepencies are due to change of factor logic from if based_on == "three_months": factor = 3 to factor = (limit_date - start_date).days / (365.25 / 12) or 1 --> For example turning a based on 3 months monthly demand with 30 products sold 2 months ago will change from BEFORE: 30 / 3 = 10 NOW: 30 / (92 / (365.25 / 12)) = 9.92 Using start_date = now() - relativedelta(months=3) means (limit_date - start_date).days can range from 89-92 days depending on the month. But this makes sense as the daterange used to select moves that go in the monthly demand calc will be based on the same number of days. task#4783508
Documentation courses can now receive reviews, just like training courses, helping organizations collect feedback on a wider range of learning content. Comments are turned off by default for documentation courses to better match their less interactive nature, and course type guidance is clearer with a new tooltip.
Original PR description
Only "training" course were allowed to be reviewed. We extend it here to all type of course (i.e. also "documentation" course). As documentation courses are less "participative", we disable comment by default for those courses. We also add a tooltip for course type field. Task-4568069
Updates Uruguay localization to recognize reduced VAT rates beyond the standard exempt, minimum, and basic categories. This helps businesses produce compliant electronic invoice XML and tax reports for eligible card or electronic-money sales.
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#232132
Forward-Port-Of: odoo/odoo#221073Uruguayan electronic invoices can now correctly handle VAT rates outside the standard exempt, minimum, and basic rates. This improves tax reporting accuracy by including reduced-rate VAT in the official XML invoice totals and making the related tax grid available for configuration.
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#97521
Forward-Port-Of: odoo/enterprise#91392Resolved issues and error corrections
App icons created in Web Studio are now automatically resized before being saved. This prevents oversized images from taking unnecessary space in caches and the database, helping keep requests lighter and performance more consistent.
Original PR description
Before this commit, the IconCreator images were sent as is in their full size. Downstream it was problematic because apps' icons were bigger than necessary, bloating the different caches, the database, and the request. After this commit, icon are resized to a max of 64x64 pixels. Forward-Port-Of: odoo/enterprise#97626 Forward-Port-Of: odoo/enterprise#94480
This update lets Odoo process files before they are uploaded, including resizing image files when needed. This helps keep uploaded Studio icons and similar images from unnecessarily increasing database size.
Original PR description
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#231899 Forward-Port-Of: odoo/odoo#226611
This fixes missing payroll group settings on certain Swiss payroll employee fields. It helps ensure payroll information is shown and managed consistently for the correct employee payroll group, reducing configuration errors.
Original PR description
The payroll group was missing on some payroll fields. Related runbot issue: https://runbot.odoo.com/odoo/runbot.build.error/233445 task-5179821 Forward-Port-Of: odoo/enterprise#97611
Tax return creation now correctly recognizes fiscal years that do not start in January. This prevents incorrect “wrong dates” warnings when users create annual returns aligned with their company’s configured fiscal year.
Original PR description
When the company fiscal year is not the first of the year (Aug 1 → Jul 31), creating a tax return for the fiscal year (2024-08-01 → 2025-07-31) wrongly triggers the wizard’s “wrong dates” warning.…
When the company fiscal year is not the first of the year (Aug 1 → Jul 31), creating a tax return for the fiscal year (2024-08-01 → 2025-07-31) wrongly triggers the wizard’s “wrong dates” warning. The wizard validates the range by slicing it into periods via `_get_period_boundaries()`, which anchors the first period using `_get_start_date_elements()`. If we dont have `deadline_start_date` that anchor falls back to a fixed Jan 1 (calendar year) instead of the company’s fiscal-year start. Consequently, the first computed period becomes 2024-01-01, so the check sees a mismatch and flags the warning even though the user’s dates are perfectly aligned with the fiscal year. The fix is to use the company’s fiscal-year start as the anchor for period slicing instead of silently defaulting to Jan 1. `_get_start_date_elements()` still prefers the explicit `deadline_start_date` (unchanged behavior for calendar-anchored VAT returns), and otherwise derives the day/month from `company.compute_fiscalyear_dates(today)['date_from']`. Steps to reproduce: Accounting: Settings and set Fiscal Year End to July 31 Reporting: tax reports and set it to Year and the year to 2024 Top left there is the Return, click on it and set: - Opening Date: 08/01/2025 - Fiscal Year End: 31 July - VAT Periodicity: Annually Creat a new tax return and chose any type and set: - start date 08/01/2024 - end date 07/31/2025 opw-4990676 Forward-Port-Of: odoo/enterprise#94325
Partial payments made from the invoice payment widget will no longer trigger an automatic write-off just because the remaining amount is within tolerance. Invoices now stay marked as partially paid until the remaining balance is intentionally handled, helping users keep more accurate payment status and control.
Original PR description
Prevents the system from creating a write-off and marking an invoice as 'Fully Paid' when a partial payment (within tolerance) is reconciled from the invoice form. The invoice status will now correctly remain 'Partially Paid', giving the user control over the remaining balance. task-5114658 Forward-Port-Of: odoo/enterprise#95899
Mobile self-order customers now see the correct order after placing a new order, instead of being shown a previous paid order. Receipts downloaded after refreshing the page also keep their payment details, preventing confusing missing payment or negative change lines.
Original PR description
This PR contains 2 small fixes for mobile self order: - **[FIX] pos_self_order: wrong order on confirmation screen** Steps to reproduce: 1. Configure a Self Order POS to use QR menu + ordering 2. In…
This PR contains 2 small fixes for mobile self order:
- **[FIX] pos_self_order: wrong order on confirmation screen**
Steps to reproduce:
1. Configure a Self Order POS to use QR menu + ordering
2. In the mobile menu, make an order and confirm
3. The confirmation screen shows order S001, pay at the counter
4. In the POS, pay and validate the order
5. In the mobile menu, make another order and confirm
Expected behaviour:
- The confirmation screen shows order S002, pay at the counter
Actual behaviour:
- The confirmation screen shows order S001, already paid
The cause of this is that `selectedOrderUuid` is cleared whenever the
`getUserDataFromServer` method is called, even if the server doesn't
return an order to replace it with. The self order service then tries
to find the current order and takes the previously paid order instead of
the new order.
To fix this, we simply don't clear `selectedOrderUuid`. It will still be
overwritten if the server does return new order data.
- **[FIX] pos_self_order: incorrect receipt after refresh**
Steps to reproduce:
1. Configure a Self Order POS to use QR menu + ordering
2. Make an order in the mobile menu
3. Pay and validate the order in the POS using the 'Card' payment method
4. Go to 'My Orders' in the mobile menu, and download the receipt
5. Observe the correct 'Card' payment line is shown on the receipt
6. Refresh the page
7. Download the receipt again
Expected behaviour:
- The downloaded receipt is the same as the first one, with the 'Card'
payment line.
Actual behaviour:
- The downloaded receipt has no payment lines, so it just shows a
negative 'Change' line at the end.
The cause of this issue is that the payment lines and payment methods
used to render the receipt were not being persisted in the indexed DB.
The fix is simply to add these models to the data service options so
that they also get saved locally.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#232314
Forward-Port-Of: odoo/odoo#231910Fixed an issue where saved payment methods were not offered when registering payment on a later invoice for the same user. The payment process now uses the invoice's linked customer rather than the company contact, helping payments be completed without manual workarounds.
Original PR description
Currently, when user A from company AA records a payment method, a payment token is stored for that user. However, when an invoice is issued for that user, the payment token cannot be used because the payment registration form uses the partner AA instead of the user linked to the move, partner A. Step to reproduce: 1. Create a user A in company AA 2. Create an invoice for user A 3. Register a payment on the invoice and save the payment method (token) 4. Create another invoice for user A 5. Try to register a payment on the invoice: the payment token is not proposed This fix updates the logic to use the user linked to the move instead of the partner on the line, allowing proper selection of a payment token. opw-5036106 Forward-Port-Of: odoo/odoo#232134 Forward-Port-Of: odoo/odoo#230105
Opening the Helpdesk ticket list when there are no tickets now works correctly instead of crashing. This improves stability for teams starting with an empty ticket queue or after clearing all tickets.
Original PR description
When accessing the Helpdesk ticket list view with zero tickets, the view previously crashed due to improper handling of folded sample data. This commit ensures that sample data folding does not trigger errors when the view is empty, improving overall stability. Steps to reproduce: 1. Navigate to Helpdesk > Teams > Tickets. 2. Ensure there are no tickets. 3. Switch to list view. Task-4971510 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226253
Point of Sale now applies minimum-quantity pricelist rules based on the total quantity of the same lot-tracked product, even when items are split across multiple lots. This ensures customers receive the correct price or discount at checkout and avoids undercharging or overcharging caused by separate lot lines.
Original PR description
**PROBLEM** Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot…
**PROBLEM** Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot A, and 3 product from lot B, a rule defining the price for a minimum quantity of 5 will not trigger (it should). **STEP TO REPRODUCE** 1. install pos 2. create a lot tracked product 3. create a pricelist rule for the product, with a price based on min qty 4. from the pos, order the min qty but split it accross multiple lots 5. price will not takethe rule into account **CAUSE** Order line of lot tracked products are never merged. The quantity used to compute if a pricelist trigger is the quantity of each line individually. **FIX** For lot tracked product, to determine the price of a line, we parse find all corresponding lines and add their quantities together. Then we update all of their prices. To know if we should take into account a line, we verify if they would have been merged, if their product wasn't lot tracked. **REMARK** Ideally, their would be a way to merged order line of lot tracked product, while being able to edit the quantity taken from each lot directly from the pos. From now, order line doesn't work well with multiple lots, and it would require unstable change on the db. opw-4751920 Forward-Port-Of: odoo/odoo#232276 Forward-Port-Of: odoo/odoo#219110
This update fixes multiple small issues affecting website content, Indian e-Waybill printing, payments, mail cleanup, SMS validation, and IoT certificate handling. It improves day-to-day reliability by preventing printing failures, stale activity records, unnecessary certificate requests, and regressions in website sitemap language behavior.
Original PR description
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
New user signatures now place the user's name in a layout block that avoids unwanted extra spacing. This prevents line breaks in the editor from duplicating paragraph spacing, making default signatures look cleaner for new, demo, and admin users; existing user signatures are not changed automatically.
Original PR description
Prior to this commit, the default signature for users was their name wrapped in a `p`. This is not what we want, because a `HTMLParagraphElement` natively has a margin-bottom, and when a user creates a newline from a paragraph in the HTML Editor, the paragraph is cloned. After this commit: the user name is wrapped in a `div` instead. This does not update existing users signatures. To switch to a `div`, they will have to select the desired lines, and change their type from "Paragraph" to "Normal". Demo and admin users are updated too, because lxml `document_fromstring` would wrap text content in a `p` during record creation. task-5149570
Demo user signatures for Laurie Poiret and Maggie Davidson now use a layout that avoids unwanted extra spacing. This reduces manual cleanup when using or adapting these sample records.
Original PR description
Adapt signatures for Laurie Poiret and Maggie Davidson so that they are wrapped in a `<div>` instead of a `<p>`, because lxml `document_fromstring` would wrap text content in a `p` during record creation. Ideally all user data records should do that for their signature field. This commit only updates the main ones. `p` in a signature is not desired because it has a native margin-bottom, and the user has to change it to a `div` in order not to have it. Making `div` the default container for signatures simplifies that tedious process. task-5149570
This fixes an issue where Swiss payroll pay run generation could fail or be blocked when users worked across multiple companies. It helps payroll teams generate pay runs reliably in multi-company setups without unnecessary access problems.
Original PR description
Forward-Port-Of: odoo/enterprise#97503
This fixes an eLearning display issue where highlighted text in course articles appeared correctly in normal view but disappeared in fullscreen mode. Learners now see the same formatted content in both viewing experiences, improving consistency and readability.
Original PR description
**Steps to reproduce:** - Go to eLearning course on the website - Edit an article - Add the highlighting effect on the text - Save the changes - The text is properly displayed in normal article - Go to the fullscreen version - The highlighting is not present in this version **Issue:** This is an ordering issue caused by the dynamic rendering of fullscreen slides. When in normal mode, the content is initialized and then the `TextHighlight` widget is started. But the rendering of the slides in fullscreen mode is delayed and occurs after the widget is applied. **Fix:** Recreate and restart the widget on `_renderSlide` in the `slides_course_fullscreen_player`` opw-4978798 related: https://github.com/odoo/odoo/commit/f64c9f27f1a9106bc009ad2f696845f2c5c58066 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232209 Forward-Port-Of: odoo/odoo#225150
Spacing was improved for event website menu options shown in debug mode, making labels and fields easier to match. This reduces confusion for administrators configuring event pages and event types.
Original PR description
The PR fixes the display of the fields displayed when the debug mode is activated and used to show buttons in the menu of event website pages. Previously, it was difficult to determine what were the labels of the fields. To make it clearer, the spaces between the label-field couples have been increased. Task-4750239 Forward-Port-Of: odoo/odoo#214135
Fixed an issue that could cause an error when refreshing appointment availability for bookings assigned to a staff member. This improves reliability for users managing appointment slots and prevents interruptions during scheduling.
Original PR description
This commit fixes an issue where the refresh with appointment based on staff user was raising a traceback as it also tried to compute the max capacity possible. Related commit 3cca7e47ab58f8a7d4e9196dbf60f7068348216b task-5118860 Forward-Port-Of: odoo/enterprise#97634 Forward-Port-Of: odoo/enterprise#95862
A previously disabled automated test for website editor animation options has been re-enabled after its timing issue was resolved. This helps ensure hover-based animation settings remain reliable without changing the user-facing website experience.
Original PR description
In commit 22c4ecff46d34a37549dfa3feda8cfe12cf00407, the test was disabled because it had non-deterministic failures It was failing because the preview (that was made by the hover before the click) took sometimes long enough that `waitForEndOfOperation` was executed before preview finished, so it only waited for the end of the preview, not the end of the commit made by the click. Thus the `waitDomUpdated` that followed did not wait for the update caused by the commit (thus had nothing to wait for). And the assertions failed as the sidebar was not updated yet. In order to wait enough, the helper `waitSidebarUpdated` has been introduced in commit 143c40bdb7eac35126d51ac85fb89e37ecb75f13. In this commit, we just un-skip the test (which was updated to use that helper) task-4367641 Forward-Port-Of: odoo/odoo#226814
Vendor bill XML imports for Ecuador now correctly include discounts when a discount value is present in the file. This prevents understated discounts and helps keep imported supplier bills aligned with the original invoice totals.
Original PR description
In the l10n_ec_edi localization, XML files that include a <descuento> (discount) tag do not apply the discount when imported into Odoo. - Create an invoice with a discount and export the XML. - Re-import the XML as a vendor bill — the discount is missing. This commit fixes the issue by computing and importing the discount percentage from the <descuento> tag. opw-5137439 Forward-Port-Of: odoo/enterprise#96712
This fixes a test setup issue where a website form tour could stall because the editor component was not loaded in the test bundle. The change makes the test helper check that the editor is available before applying its setup, improving reliability of automated validation without changing user-facing behavior.
Original PR description
Steps to reproduce
==================
Run the test test_contactus_form_email_stay_dynamic
The ready "odoo.isTourReady('...')" code was always falsy
Cause of the issue
==================
website_form_editor.js import @html_editor/../tests/tours/helpers/editor
it itself import @html_editor/editor
Since the editor is not part of the bundle when loading the tour, nothing is loaded
Solution
========
As it not that easy to include the editor in the web.assets_tests bundle,
we check if the editor module is present before patching it.
When actually running the tour, it will be present.
runbot-231561
Forward-Port-Of: odoo/odoo#230595This update fixes inconsistencies in employee payroll fields and makes payroll API tests independent from demo data. It helps improve build reliability and reduces the risk of payroll-related validation issues in Australian localization workflows.
Original PR description
- Remove test dependency on demo data - Fix inconsistency on employee fields runbot-231643 runbot-230983
Picking operation reports now show products grouped in the expected location order, such as stock shelves or warehouse areas. This makes printed or viewed operation details easier for warehouse teams to follow and reduces confusion during receipts, deliveries, and other stock movements.
Original PR description
Steps to reproduce: - Create an operation (Receipt, Delivery, etc..) - Add move lines with different locations (WH/Stock, WH/Stock/Shelf 1, etc..) Issue: Products are not sorted based on picking operation's location. Iterations on the picking operations were on the move_line directly. In 18.2, it was changed to iterate on the move itself, but the sorting was disregarded therefore it was added again with some modifications to cope with the new iterations. The change was made on this PR: See https://github.com/odoo/odoo/pull/152280 Task: 4570203 (Unreleated but addressed on this task) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Planning and Timesheet Analysis report now calculates planned and remaining hours using each employee's own working schedule rather than assuming a standard Monday-to-Friday week. This gives managers more reliable capacity and workload figures for employees with part-time or non-standard calendars.
Original PR description
To reproduce: ============= - set the company calendar to 40h/week (Mon to Fri) - create an employee with a 32h/week working schedule (doesn't work on Fri) - on planning app, create a shift for this employee for ex from 01/09 to 15/09 with 2h allocated - go to Planning / Timesheet Analysis report and check report for this employee on september -> planned hours and remaining hours are wrong Problem: ======== when querying the data for the desired period, we divide the allocated hours by the number of weekdays (Mon to Fri) in the period, but we should divide by the number of working days according to the employee's working schedule Solution: ========= we compute the number of working days based on the resource calendar of the employee and use this number to compute the planned hours and remaining hours opw-5008066 Forward-Port-Of: odoo/enterprise#95115
This fixes a Belgian SEPA payment file issue where a required payment reference field could be left empty. The change helps banks process generated payment files correctly and reduces failed or rejected payment batches.
Original PR description
The XML of the spea file in format pain.001.001.03 in l10n_be has a missing EndToEndId tag. - Configure the bank to use the pain.001.001.03 sepa xml format. - Generate a payment using sepa. Create a batch for this payment and validate. - The resulting xml has an empty EndToEndId tag. Commit fa08eac141956141bc12c1d5619bd57f487c36e9 responsible - investigate opw-5150525
Documentation and clarification updates
Acsone, represented by Tobias Zehntner, has been added to the contributor agreement records. This confirms the legal paperwork needed for contributions is in place and keeps the project’s contributor list up to date.
Original PR description
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232278
13 changes
Enhancements to existing features
Luxembourg payroll parameters have been updated to reflect 2025 changes to the minimum social salary and employee tax credits. This helps ensure payroll calculations stay aligned with the latest official Luxembourg social security and tax requirements.
Original PR description
Sources: - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202501.pdf - https://igss.gouvernement.lu/dam-assets/publications/param%C3%A8tres-sociaux/2025/par-soc-202505.pdf - https://impotsdirects.public.lu/fr/az/c/CIP/cip2025.html - https://impotsdirects.public.lu/fr/az/c/credit-impot-salaries/cis2025.html task-5176255 Forward-Port-Of: odoo/enterprise#97608
This update lets account report expressions be copied along with account reports. It makes duplicating and adapting financial reports easier, reducing manual setup work and helping maintain consistency.
Original PR description
This commit is a backport of [this commit](https://github.com/odoo/odoo/commit/9c0baadc4bb58a75d17ef6963a5acd5cf6c34036) initially targetting saas-18.1 which enables the copy of account report expressions. --- task-4728887 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Trial Balance report has been updated with improvements from a newer version and aligned across several country-specific accounting reports. This gives finance teams a more consistent and improved reporting experience in Odoo 18.0, especially for consolidation-related work.
Original PR description
*: account_intrastat, account_reports, l10n_be_reports, l10n_co_reports, l10n_ee_reports, l10n_es_reports, l10n_lu_reports, l10n_mx_reports, l10n_ro_reports --- This commit is a backport of both the following commits whose targets are to refactor the Trial Balance report. https://github.com/odoo/enterprise/commit/a7e1ec20e07efc39bca44d3ae613a54770175273 https://github.com/odoo/enterprise/commit/a6508b0b91a34921668ddc039e2b006746b78351 18.0 is a major version for consolidation and the improved trial balance should accompany it. --- task-4728887
Resolved issues and error corrections
Third-party checks are now classified correctly when the same check has both received and paid-out activity. This prevents checks from incorrectly appearing as still on hand, improving the accuracy of check tracking and payment follow-up.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting`, `l10n_ar`, and `l10n_latam_check`. 2. Create a third-party check journal: * Add payment methods: *New Third Party Checks* (inbound) and…
**Steps to reproduce:** 1. Install the modules: `accounting`, `l10n_ar`, and `l10n_latam_check`. 2. Create a third-party check journal: * Add payment methods: *New Third Party Checks* (inbound) and *Existing Third Party Checks* (outbound). * Configure outstanding accounts for both methods. 3. Create a vendor payment: * Use the third-party check journal. * Select the *Existing Third Party Checks* method. * Leave the check list empty. * Keep the payment in *Draft*. 4. Create a customer payment: * Use the same journal and select the *New Third Party Checks* method. * Add a new check under the *Checks* tab. * Post the payment. 5. Return to the draft vendor payment created in step 3: * Add the newly created check to it (via *Add a line*). * Post the payment. 6. Go to **Customers → Third Party Checks**. **Observed behavior:** - The check still shows a `current_journal_id` even though it has both inbound and outbound operations. - As a result, the check incorrectly appears in the 'On Hand' filter. **Root cause:** - `_get_last_operation` was sorting operations by `date`. - In some scenarios or flows where multiple operations share the same `date`, the wrong operation could be selected as the "last one", leading `_compute_current_journal` to assign a journal incorrectly. **Solution:** - Sort operations by `write_date` to always pick the true last operation. - This ensures `_compute_current_journal` correctly clears `current_journal_id` whenever both inbound and outbound operations exist. opw-5012903
The Chinese ASBE balance sheet report now includes the correct lines and account so assets and liabilities balance properly. This improves the reliability of financial reporting and the related automated checks.
Original PR description
Fixes the balance_sheet_balanced test for asbe where the wrong line was set as liability. Also fixes the report itself that was ignoring one line, and missing one account. task-5175789
This update makes the Latin American check payment search view point explicitly to the correct internal view. It reduces the chance of configuration conflicts when other modules contain similarly named views, helping ensure consistent behavior.
Original PR description
Description of the Issue/Feature this PR Addresses: To eliminate the risk of XML ID collisions. Using an unqualified external ID in a ref attribute can cause Odoo to load a view from an unintended module if the XML IDs are duplicated. Current Behavior Before PR: The search view uses an unqualified XML ID in the ref attribute, which relies on global resolution and can resolve to the wrong view. Desired Behavior After PR is Merged: The ref attribute uses the fully qualified external ID `l10n_latam_check.view_account_payment_search.` This ensures deterministic view loading by explicitly linking the reference to the correct view within the l10n_latam_check module. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Budget line reports now show the correct committed amount when a bill is split across multiple analytic plans. This prevents duplicated totals in budget reporting, helping teams rely on accurate budget figures.
Original PR description
Steps to reproduce: - Create analytic plan A and B - Create new budget with 2 lines: 1. Plan A: Analytic account A, Budget: Any 2. Plan B: Analytic account B, Budget: Any - Create bill with line having: - Unit price: 100 - Analytic distribution: planA -> account A, planB -> account B - Open the Budget Issue: While the committed amount in each budget line is correct (100), when opening the line budget report, the committed amount is doubled (200 instead of 100). This occurs because the system matches the whole budget instead of the specific budget line. opw-5039677
This fixes an issue where users without Point of Sale or Inventory access could not delete contacts because the system checked related sales data they were not allowed to view. Contact deletion now avoids that unnecessary access error, helping regular users manage contacts according to their actual permissions.
Original PR description
Versions affected 18 (and any where the fw port has been deployed) A user with no point of sale or inventory permissions wouldn't be able to delete contacts anymore since commit 082b7d3 Steps to reproduce: - In runbot, strip demo user permissions so he doesn't have inventory or point of sale access. - Go to a contact and try to delete it. - An **Access Error** error raises, as that user doesn't have `pos.order` permissions and the new unlink check is trying to check if the partner has related orders. (anyway, maybe the right approach would be to set an `ondelete='restrict'` in the `partner_id` field of `pos.order`) cc @moduon MT-12281 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes and improves Odoo's internal Hoot testing tools and related web test infrastructure. It helps developers identify failed tests and server errors more clearly, reducing the risk of undetected issues while keeping changes limited to the testing ecosystem.
Original PR description
## Pull Request HOOT 38 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Odoo now recognizes Shopee orders that have been delivered but are still waiting for the buyer to confirm receipt. This prevents those delivery orders from being incorrectly shown as errors, giving teams a more accurate view of fulfillment status.
Original PR description
When the delivery order is delivered but not yet confirmed by the buyer, an error state is set in the delivery order. 'TO_CONFIRM_RECEIVE' should be included in the delivery status. It refers that the package is delivered but not confirmed by the buyer. It should not be regarded as an error state in Odoo. task_id: 4965896
The test framework now detects processes that are still running after a test finishes and logs them during server shutdown. This helps prevent automated test runs from hanging and improves reliability for release validation.
Original PR description
In some case a process could remain aive at the end of a tests In addition to possible race condition, this can also cause a program to remain stuck at the end of the tests. This commit proposes to - catch all remaining processes at the end of a base case. - log a message if a process is found at the shutdown of the server. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#231942
This fixes an issue where automated subscription payment processing could repeatedly create new invoices and payment transactions after a validation payment. Subscriptions now correctly recognize validation transactions as already processed, preventing duplicate invoices and unnecessary payment retries.
Original PR description
**Steps to reproduce** - Enable the Stripe payment provider in test mode. - Create a subscription for a portal user. - With that portal user, automate the payment via the portal. - Run "Sale…
**Steps to reproduce** - Enable the Stripe payment provider in test mode. - Create a subscription for a portal user. - With that portal user, automate the payment via the portal. - Run "Sale Subscription: generate recurring invoices and payments" cron. - OK: 1 invoice generated. 1 new transaction in "Pending" state. - Run "Payment: Post-process transactions" cron. - Issue: a new invoice is generated. The previous one is cancelled. A new payment transaction has been created. The next cron calls will repeat the issue, leading to multiple invoices and transactions being generated. **Cause** - `_post_process` is called on the validation transaction in `done` state. But as the `_post_process` override in sale applies a filtering https://github.com/odoo/odoo/blob/a1ce545f73266c0cf7ca876a1b8cde44b064a56b/addons/sale/models/payment_transaction.py#L44-L45 only `pending` transactions are marked as post-processed by the method in `payment`. - once the first invoice for the subscription is created, a new transaction is created for the actual payment and the `pending_transaction` flag is set on the subscription. - when the "Payment: Post-process transactions" cron runs after that, the already post-processed validation transaction is processed again, calling https://github.com/odoo/enterprise/blob/580d406e07a60a34f258eebb65cfd6c33c2ea3ca/sale_subscription/models/payment_transaction.py#L154-L155 - this resets the `pending_transaction` flag on the subscription, leading to the creation of a new invoice and a new transaction opw-4962416
This update fixes several operational issues in accounting, inventory barcode scanning, quality checks, payroll, planning, and inter-company sales. It also refreshes translation files and adds missing translation coverage, helping users avoid errors and ensuring regional compliance updates are available.
1 change
Resolved issues and error corrections
A spelling mistake in Odoo Studio’s field selection was corrected from “Multine” to “Multiline.” This makes the interface clearer for users when adding or configuring fields.
Original PR description
This commit fixes a typo in one of the newFields name: 'Multine' -> 'Multiline'