Daily updates from Odoo
Friday, February 6, 2026
64 changes · saas-19.1
Enhancements to existing features
This update introduces the ability to temporarily hide products in the Point of Sale system, preventing them from being added to orders. Products marked as 'snoozed' appear grayed out but remain available for selection. This feature provides flexibility in managing product availability during busy periods.
Original PR description
The PR will add an extra availability section on the product info popup which shows whether a product is currently available. From that section the product can then be 'snoozed', which will make it unavailable for a specified period of time. (1, 2, 4 hours, or for the entire session). When the product is unavailable there's a countdown timer on the popup showing when the product will be available again. Products which are 'snoozed' still show up on the product screen, but grayed out. The effect is purely cosmetic, as they can still be added to new orders. Task-[5170696](https://www.odoo.com/odoo/project/1737/tasks/5170696) Previous discussion-[#232625](https://github.com/odoo/odoo/pull/232625) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This update resolves an issue where dynamic product snippets would cause horizontal scrolling when the content width was set to 'max'. The fix repositions the navigation buttons to ensure they remain within the visible area, improving the user experience on larger devices.
Original PR description
Steps to reproduce: 1. Drag and drop the dynamic products snippet. 2. Select it and change the content width to **max**. Issue: When the content width is set to **max**, an unnecessary horizontal scroll appears. Reason: The issue occurs because the `previous` and `next` navigation buttons were not properly positioned. Fix: For devices larger than "mobile", the `previous` and `next` buttons are re-positioned, horizontally inward by "**50%**" of their own width with the help of `transform` property. This keeps the controls within the visible area and prevents horizontal scrolling. task-5090468 Before: <img width="1915" height="966" alt="image" src="https://github.com/user-attachments/assets/0c20d0b6-32cc-477b-8403-55bb0d372d8d" /> After: <img width="1920" height="963" alt="image" src="https://github.com/user-attachments/assets/4194b0f1-f3ad-4818-aa6f-2fda4561d2c7" /> Forward-Port-Of: odoo/odoo#237876
This update resolves an issue where processing refunds for returned POS orders with shipped original orders would cause an error. The fix ensures that picking values are generated correctly, regardless of whether the original order was shipped, allowing for seamless refund processing. This improves the reliability of the POS refund functionality.
Original PR description
Currently, an error occurs when processing the payment of a return POS order whose original order has already been shipped. **Steps to Reproduce:** 1. Install the stock and pos modules with demo…
Currently, an error occurs when processing the payment of a return POS order whose original order has already been shipped. **Steps to Reproduce:** 1. Install the stock and pos modules with demo data. 2. In config, activate the "**Allow Ship Later**" for _Furniture Shop_. 3. Open register and create an order with a Ship Later date. 4. Inventory > Delivery Orders > Validate the picking generated for that order. 5. Open original POS order (form), click "**Return Products**". 6. Open the returned order, click "**Payment**" and make the payment. **Error:** `ValueError - Expected singleton: pos.order(2, 1)` **Cause:** At [1], `reference_ids.pos_order_ids` is a many2many relation, but the logic assumes it contains only a single order. As a result, accessing `order.session_id.id` or `order.id` raises a singleton error when multiple related orders are present. **Fix:** This commit ensures that picking values are generated using a single pos order reference by selecting the relevant one from the multiple pos orders. [1] - https://github.com/odoo/odoo/blob/569b2e27699a76f9bac210e61b47f8a5708c814b/addons/point_of_sale/models/stock_picking.py#L157-L160 sentry- 7071798497 Forward-Port-Of: odoo/odoo#238467
This update resolves a problem in Kiosk Mode where the 'Buy an RFID Device' link incorrectly directed users to a French Amazon site that didn't ship to the United States. The link has been corrected to use the US Amazon site and a compatible merchant, ensuring users can now successfully purchase the necessary device.
Original PR description
Steps to reproduce: ----------------------------------- 1. Install the Attendance module with demo data 2. Go to Kiosk Mode > click on the link to 'Buy an RFID Device' 3. On the opened Amazon page, change the delivery country to United States Observation: ----------------------------------- The Amazon product page becomes blank after switching the delivery country to the United States Issue: ----------------------------------- The link redirects to the French Amazon website (`amazon.fr`) with a merchant that does not ship RFID devices to the United States Solution: ----------------------------------- Update the link to use `amazon.com` instead of `amazon.fr`. Change the merchant ID to one with broader delivery availability, including the United States. opw-5479568 Forward-Port-Of: odoo/odoo#246041
This update optimizes how the system searches for a user's preferred project within timesheets. Previously, the search was performed unnecessarily every time a related record was accessed. This change ensures the preferred project is only identified when required, improving performance and reducing potential delays.
Original PR description
Before this commit, each time the default_get method is called for `account.analytic.line` model, the favorite project is computed even if we don't expect to search the default value for `project_id` field. This commit makes sure we will only compute the default project when it is really needed.
This update resolves an issue where the SE blackbox wasn't sending the correct POS ID. The fix ensures accurate data transmission, which is crucial for reliable reporting and integration with our cash management systems. This change improves the stability and accuracy of data sent to the SE blackbox.
Original PR description
When using a v1 CleanCash blackbox, the command being sent to the blackbox was mistakenly sending a POS ID of " ". It just so happened this worked correctly when testing with our blackbox because it had " " registered as a POS ID. The POS ID is now sent correctly. task-5077448 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug where adding a second file to the Activity composer didn't work correctly. The fix ensures that subsequent file uploads are properly processed, preventing the selection from being lost and allowing users to add multiple attachments. This improves the usability of the Activity composer.
Original PR description
…omposer Problem: In the "Activity" tab of the composer, adding a second file does not work. The first file is added correctly, but subsequent uploads are ignored. Cause: The selection is lost during…
…omposer Problem: In the "Activity" tab of the composer, adding a second file does not work. The first file is added correctly, but subsequent uploads are ignored. Cause: The selection is lost during file selection because the component is re-rendered, which recreates the DOM nodes. This re-render only happens in `HtmlMailField` because it processes the value through `convert_inline`. Even when `lastValue` and `value` are logically the same in `useRecordObserver`, they differ in markup: - `lastValue` contains self-closing `v:image` and `v:fill` tags. - `value` contains open/closing versions of those tags because they are not excluded from the self-closing to open/closing conversion. This mismatch triggers a re-render, causing the selection to be lost and preventing the second file from being inserted. Solution: Exclude `v:image` and `v:fill` from the self-closing to open/closing tag conversion so that `lastValue` and `value` remain equivalent. This prevents the unnecessary re-render and preserves the selection. Steps to reproduce: - Click on "Activity" in the chatter to open the dialog. - Click in the "Log a note..." field. - Use the upload button to add a file. - Press Enter. - Use the upload button again to add another file. - Observe that the second file is not added. task-5490722 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#245721
This update fixes an issue where loyalty programs were incorrectly displaying currency information in shops that don't support multiple currencies. The fix prevents loading programs with incompatible currencies, ensuring accurate pricing and a better user experience. This resolves a potential confusion point for customers.
Original PR description
Currently, the pos does not support multi-currencies. However, nothing was making sure the programs loaded in a shop were compatible in terms of currencies. Steps to reproduce: ------------------- * Create a coupon loyalty program, coupons * Change currency to euro * Create coupons * Copy obe of the code * Open USD Shop * Apply coupon, cancel order, apply coupon again > The popup does not show the correct currency Why the fix: ------------ As the pos is not ready for multi-currency we should not even load programs with different currencies. opw-5220834 Forward-Port-Of: odoo/odoo#238491
This update fixes an issue where invoices created in one company could incorrectly use accounts from a different company. The change adds a validation check to ensure that invoice line accounts always belong to the invoice's company, preventing accounting inconsistencies and improving data accuracy.
Original PR description
### Issue: When an invoice is created for a company and then its company and journal are changed to another company valid combination, the accounts on the invoice lines are not updated automatically This leads to inconsistencies where move lines use accounts that do not belong to the move’s company ### Cause: A validation check ensuring that move line accounts belong to `move.company_id` or parents was missing in `_post()` for account moves ### Steps to reproduce: - Create Company A and Company B - Create an invoice on Company A with one line having an account in Company A - Change the invoice company to Company B and set a journal belonging to Company B - Save and confirm the invoice opw-5167958 Forward-Port-Of: odoo/odoo#243243
This update resolves an issue where the 'Create Page' button wasn't appearing when adding a new menu item. The change ensures that the system checks the menu URL again after edits, synchronizing the page existence status and providing the correct suggestion. This improves the user experience when building the website.
Original PR description
Since commit 45e15673a70cf770d8e343a0a3b805eccdbed0d1, the information about whether a page of a menu exists is fetched asynchronously. Thus, when the dialog to change the url is closed to save the change, the value whether the page exists may not be in sync with the url. This commit checks the url again after the edit dialog is closed to correctly suggest to create a page. Steps to reproduce: - Open website builder - Click on the header - Click on "Edit Menu" - Click "Add new menu" - Type a title for which there is no existing corresponding page and _quickly_ click "Continue" - Bug: The button to suggest to create a page does not appears task-5474734 Forward-Port-Of: odoo/odoo#242583
This update enhances the orderpoint wizard in the stock module, making it easier for users to manage replenishment quantities. Specifically, the wizard now allows users to save desired minimum and maximum quantities, and displays deadlines in red if they've passed. This improves usability and ensures accurate orderpoint tracking.
Original PR description
- if deadline_date is in the past, display it in red - allow the user to save a new min and/or max qty when closing the wizard - make sure the table rows stay in order when saving task 5410931 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#240096
This update resolves an issue preventing sales users from creating orders with products having custom value attributes. The fix adjusts security permissions to ensure sale users retain access needed to populate these attributes, addressing a previous restriction that limited functionality. This ensures all users can properly create and manage sale orders.
Original PR description
### Issue: Due to this issue, sale group cannot create a sale order with a product with custom value attribute. #### Steps to reproduce: 1- Create a product using admin with a custom value attribute. 2- Using demo user with sale access group, create a so. 3- Add the created product, and fill the custom value. The sale order cannot be saved due to access error. ### Cause: This is due to #197286. However that shouldn't have been applied to `product.attribute.custom` as that shouldn't be only accessed by people who can manage product like the rest of deleted accesses, but also it's needed by sale groups creating SOs. opw-5498719 Forward-Port-Of: odoo/odoo#247276
This update corrects a technical issue with the URL used to connect to the Polish Electronic Data Interchange (KSeF) system. The change ensures that Odoo can properly transmit and receive data required for Polish tax reporting, maintaining compliance. This fix is crucial for businesses using the Odoo accounting module in Poland.
Original PR description
The production URL for the Polish EDI (KSeF) was incorrect. This commit updates the endpoint to the current valid URL to ensure proper connectivity. 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#247424
This update fixes a problem where users couldn't select payment method journals if the company wasn't a parent or child of the current POS company. Now, the system prevents users from choosing these invalid journals, ensuring payment methods load correctly and preventing errors in the Point of Sale configuration.
Original PR description
Before this commit: =========== - Selecting a journal for a payment method belonging to a company that was neither a parent nor a child of the current company caused payment methods to fail loading for the POS session, resulting in no payment methods being available for the configuration. After this commit: =========== - Users are now prevented from selecting journals belonging to companies that are neither parent nor child of the current company. task-5158448 Forward-Port-Of: odoo/odoo#241519
This pull request updates the core spreadsheet component (o_spreadsheet) to the latest version, addressing several bugs and improving stability. The changes include fixes for crashes, incorrect calculations, and UI issues, ensuring a smoother user experience when working with spreadsheets within Odoo.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/67a692f068 [REL] 19.1.6 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/67a692f068 [REL] 19.1.6 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/8f34d5715d [FIX] dom_helpers: wait for document ready [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/ce4efeedb2 [FIX] Cell: do not rely on key presence in commands [Task: 5499921](https://www.odoo.com/odoo/2328/tasks/5499921) https://github.com/odoo/o-spreadsheet/commit/23bd59864c [FIX] regexextract : invalid regex throw error [Task: 5892417](https://www.odoo.com/odoo/2328/tasks/5892417) https://github.com/odoo/o-spreadsheet/commit/1f06628b29 [FIX] find_and_replace_store: crash after sheet deletion [Task: 5453311](https://www.odoo.com/odoo/2328/tasks/5453311) https://github.com/odoo/o-spreadsheet/commit/5cc8a0c065 [FIX] evaluation: do not overwrite current sheet [Task: 5868007](https://www.odoo.com/odoo/2328/tasks/5868007) https://github.com/odoo/o-spreadsheet/commit/fd532281cd [FIX] menu: can open empty menu popover [Task: 5863077](https://www.odoo.com/odoo/2328/tasks/5863077) https://github.com/odoo/o-spreadsheet/commit/379894f6bd [FIX] *: fix faulty css zoom detection [Task: 5453400](https://www.odoo.com/odoo/2328/tasks/5453400) https://github.com/odoo/o-spreadsheet/commit/bb484e3428 [FIX] XLSXImport: Fix crash on incomplete xlsx file with external reference [Task: 5499753](https://www.odoo.com/odoo/2328/tasks/5499753) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update fixes an issue where vendor bill labels on payable lines were empty when a payment reference wasn't provided. Now, the payable line automatically displays the bill reference, and updating the payment reference correctly updates the label. This ensures more accurate and informative reporting on vendor payments.
Original PR description
Before PR: - On vendor bills and refunds, if the Payment Reference is empty, a placeholder saying `Use Bill Reference` is shown. But the Bill reference is still not written on the Payable line, making the label empty. - When Payment Reference is set, updating the Payment Reference does not update the payable line label. After PR: - The payable line label is now populated with the Bill Reference when the Payment Reference is empty. - Now, when Payment Reference is set, updating the Payment Reference updates the payable line label. - Modified the test cases which were failing due to an empty label. Related PR (Enterprise) : https://github.com/odoo/enterprise/pull/91535 Task : 4982864 Forward-Port-Of: odoo/odoo#247345 Forward-Port-Of: odoo/odoo#221491
This update fixes an error in the calculation of VAT payable or refundable on Welsh tax returns. The previous formula incorrectly subtracted input VAT from output VAT. The change updates the formula to accurately reflect the correct calculation – output VAT minus input VAT – ensuring accurate reporting for Welsh businesses.
Original PR description
**Steps to produce:** - Install the l10n_cy and accountant modules - Switch to `CY Company`. - Go to accounting > reports > Tax return. **Issue:** - The formula for VAT payable or refundable (difference between box 4 and 3) is incorrect. - box 3 refers to `Total output VAT` and box 4 refers to `Input VAT`. - Current formula: `cy_4.balance - cy_3.balance` **Fix:** - Formula for VAT payable or refundable should be output VAT - input VAT. - Update the formula to: `cy_3.balance - cy_4.balance` <img width="769" height="86" alt="image" src="https://github.com/user-attachments/assets/923a92f9-fc57-465a-9592-771730ee6870" /> opw-5751369 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247309 Forward-Port-Of: odoo/odoo#246273
This update allows users to reset Vendor Bills issued by ANAF (the Romanian tax authority) to a draft state, even if they are currently in an ‘EDI’ processing status. This change is necessary due to a recent update consolidating the e-invoice functionality into the broader ‘l10n_ro_edi’ module. It ensures proper handling of e-invoices and simplifies the process for users.
Original PR description
Adjusting the visibility check for "Reset to draft" button to allow Vendor Bills received from ANAF to be reset even when they have a EDI state. Will require to be shifted to `l10n_ro_edi` in 18.0+ as the efactura module is merged into it. task-5892651 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247266 Forward-Port-Of: odoo/odoo#246697
This update resolves a problem that occurred when renaming inherited custom fields in Odoo. To ensure correct operation, the system now removes the associated inherited fields from the database before renaming. This prevents data inconsistencies and ensures a smoother user experience.
Original PR description
When renaming a custom field that is inherited, first remove the generated inherited fields from the database. task-5172546 backport of #240603 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247344
This update resolves an issue where search requests using 'limit=False' were incorrectly interpreted as applying a limit of zero, resulting in empty search results. The change ensures that 'limit=False' is treated as 'no limit', maintaining the expected behavior for users. This ensures search results are accurate and consistent.
Original PR description
Some callers use `limit=False` to mean "no limit" (e.g. from RPC, where `None` is not available). Since `bool` is a subclass of `int`, `False` was treated as `0` and ended up applying `LIMIT 0`, returning an empty result set. This PR updates `_search` to treat `limit=False` as "no limit" while preserving the valid semantics of `limit=0`. Note: `limit=True` is left unchanged for backward compatibility and continues to behave as `LIMIT 1`. Fixes #228555 merge=merge -- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/odoo#247304
This update fixes an error in the Spanish VAT (EDI) invoice generation process. Previously, negative invoice amounts (like discounts) caused incorrect tax calculations. This change ensures accurate VAT and withholding tax calculations, even when negative amounts are used, improving invoice accuracy and compliance.
Original PR description
Issue: When using negative amounts, for example to explicitly show a discount, the tax calculation is incorrect due to the application of the `abs` function. Furthermore, the way to find out if a tax…
Issue:
When using negative amounts, for example to explicitly show a discount, the tax calculation is incorrect due to the application of the `abs` function. Furthermore, the way to find out if a tax is of the withholding type is based on the sign of the value, which can lead to error in these cases.
Cause:
A previous change (#237235) added the `abs` function so the `TotalTaxesWithheld` would be always with positive value. But this also affects the calculation of taxes `TotalTaxOutputs` in some cases, such as if the invoice line has negative values.
Steps to reproduce:
- Install `l10n_es_edi_facturae`
- With the ES company, create an invoice with some standard lines and one line with negative amounts, as an explicit discount
- Confirm the invoice and send (facturae)
- Open the XML attached in the chatter
- Observe that the taxes amounts (VAT and WITHHOLDING) are erroneous
A correct invoice should be for example:
```
Product Price Taxes Amount
---------------------------------------------
PRODUCT-A 1000 21%VAT 15%WHI 1000
Discount -100 21%VAT 15%WHI -100
---------------------------------------------
Untaxed amount 900
Withholding 15% -135
VAT 21% 189
-----------------------
TOTAL 954
```
This PR replaces #240808
---
I confirm I have signed the [CLA](https://github.com/odoo/odoo/pull/157955) and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#244428This update fixes an issue where task titles and descriptions generated from sales orders were incorrectly formatted. Now, task titles accurately reflect the sales order line description, and descriptions include all relevant details, regardless of whether the sales order line had a single or multi-line description. This ensures consistent and accurate task information.
Original PR description
Steps to reproduce: - - Create a sales order with a service product that generates a task. - Add a multi-line description to the sales order line. - Confirm the order to generate the task. - View the generated task’s title, description. Issue: - - Task titles were generated in the format sales order name + first line of the product description, and the description contained only the remaining lines. Fix: - - If the sales order line has a single-line description, it is used as the task title. - If the sales order line has a multi-line description or no description, the product name is used as the task title, and the sales order line description is used as the task’s description. Commits 588c3be420a542d8594b26ecc200ca68e35d15fc, c3877b2acd74f1f798d0046b168418300f9e27ca, and 18edce4d859935bd1425144e4c835acabc5f68f4 previously attempted to fix this issue. task-4903208 Forward-Port-Of: odoo/odoo#217035
This update resolves a bug where employees were not being fully removed from 'Basic' and 'Minimal' rights groups within the POS settings. The fix ensures that all employees are correctly removed when group memberships are updated, maintaining accurate user permissions. This prevents inconsistencies in employee access levels.
Original PR description
Steps to reproduce ------------------ 1. Enable "Log in with Employees" 2. Add employee "A" to the "Basic rights" group. 3. Add employee "B" to the "Minimal rights" group. 4. Make sure to remove all…
Steps to reproduce ------------------ 1. Enable "Log in with Employees" 2. Add employee "A" to the "Basic rights" group. 3. Add employee "B" to the "Minimal rights" group. 4. Make sure to remove all other employees from these 2 groups!! 5. Now save and go back to the main settings page, remove employee "A" from "Basic rights" group, such that this group is now empty. 6. Save the changes. Observation -> Employee "A" is still in the group "Basic rights"!! Why the issue ------------- When deleting records from an `x2many` field in pos, from the main settings page, we do not pass the associated `unlink` commands in the arguments of `web_save` when clicking "Save", we just pass an empty commands list `[]`, because the backend, specifically the method `_preprocess_x2many_vals_from_settings_view` will take care of unlinking all the records before applying the new commands. So passing an empty commands list when updating an `x2many` field will be equivalent to saying "Unlink all records for that field, then apply no commands", i.e. just unlink all records for that field. However, after https://github.com/odoo/odoo/commit/1f45b035354bb9040be3aba3a79392e603e870b4, we now filter out updates having an empty commands list, and thus now trying to unlink all records of a `x2many` does not work, since an empty command list will be dropped from the updates, before reaching `_preprocess_x2many_vals_from_settings_view`. The fix ------- We add stricter filtering logic, to keep valid command lists, even when they are empty. opw-5725879 Forward-Port-Of: odoo/odoo#245261
This update resolves a performance issue within the spreadsheet dashboard by ensuring the underlying model is correctly marked as 'raw.' This prevents unnecessary reactivity, significantly improving dashboard loading times. The change addresses a design flaw that made it difficult for developers to manage reactivity correctly.
Original PR description
Since we split o-spreadsheet in two: - core engine, independent from owl and DOM - UI The `Model` doesn't mark itself as raw for owl's reactivity. It must be done manually at every call site where it's needed. Here the entire `DashboardLoader` is made reactive, including its properties. We cannot let the model be reactive as it would hurt performance very badly. From a DX POV, the current situation is a bad design because the developer doesn't know the model needs to be marked as raw, and even if the developer knows it, it's very easy to overlook (as we did and this commit proves) It would be probably better with a private constructor and factory methods with clear names. Task-5916564 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where creating invoices for purchase orders with subcontracted tracked products previously caused errors. The change ensures proper handling of multiple finished product lines, addressing problems related to tracked products, backorder flows, and potential upgrade scripts. This ensures accurate invoicing for these transactions.
Original PR description
Before this commit, creating an invoice for a purchase order with a subcontracted tracked product triggered a singleton error. This commit fixes the issue by properly handling multiple finished move lines for the same product, which occurs with tracked products, some back order flows, and possibly upgrade scripts. OPW-5712931 Forward-Port-Of: odoo/odoo#245880
A bug in the custom color picker was causing the color slider to reset unexpectedly when selecting white. This fix prevents unnecessary UI updates, ensuring the color picker functions correctly and reliably for users. The change improves the overall user experience and prevents visual inconsistencies.
Original PR description
**Current behavior before PR:** In editor's custom gradient picker, if `#FFFFFF` is picked from the very top of picker area, the color slider is reset to color `red`. This happens because when moving picker pointer to the top of area, `selectedColor` prop is updated to `#FFFFFF`, which calls `onWillUpdateProps` callback. As result, `convertRgbToHsl` sets hue value 0 for `#FFFFFF`, setting color slider to red. **Desired behavior after PR is merged:** This commit ensures that in `onWillUpdateProps` callback, `setSelectedColor` should not get called if `newSelectedColor` is the same as `this.colorComponents.cssColor` to prevent updating UI twice while picking the color. task-5170041 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246988 Forward-Port-Of: odoo/odoo#236644
This update fixes an issue where pasting content into the website editor, particularly within iframes, would unexpectedly remove elements. The change adjusts how the editor handles inline elements, preventing the removal of unremovable content during the pasting process. This ensures a more reliable and predictable experience for website builders.
Original PR description
*: website Before this commit: when a editable container is wrapped inside a non-contenteditable, which could happen inside an iframe, pasting on a selection including an unremovable element will remove the element. This is because the config parameter `allowInlineAtRoot` is false by default, the editable container of Contact us button is considered as the edition boundary, and then `wrapInlinesInBlocks` is called on it at insert, which removes invisible nodes in the wrapping process. After this commit: we now use predicates to decide areInlinesAllowedAtRoot We add a predicate specifically for the container of Contact Us button, to allow inline element in the root. The `wrapInlinesInBlocks` won't be called on the container on paste anymore. task-5109662 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246987 Forward-Port-Of: odoo/odoo#241836
This update fixes an issue where POS order confirmation emails displayed order amounts without currency symbols or proper formatting. The change uses a standard Odoo formatting function to ensure emails consistently show amounts in the correct currency and locale for each user, improving clarity and professionalism.
Original PR description
**Problem:** POS self-order confirmation emails (delivery and takeout) display the order amount without the currency symbol and proper formatting. **Steps to reproduce:** 1. Create a POS self-order…
**Problem:** POS self-order confirmation emails (delivery and takeout) display the order amount without the currency symbol and proper formatting. **Steps to reproduce:** 1. Create a POS self-order with delivery or takeout 2. Preview or send the confirmation email 3. Observe the amount displays without currency symbol or formatting **Current behavior:** Email shows amount as a plain number (e.g., "2.0") without currency symbol or locale-specific formatting. **Expected behavior:** Email should display amount with currency symbol and proper formatting based on user's locale (e.g., "2,00€", "$2.00", etc.). **Cause of the issue:** The email templates used direct field output `t-out="object.amount_total"` which renders only the numeric value without any formatting. This bypasses Odoo's standard currency formatting that handles both the symbol and locale-specific decimal/thousand separators. **Fix:** Use the `format_amount()` helper function which properly formats monetary values with currency symbols and locale-appropriate separators. The function takes the amount and currency as parameters and returns the fully formatted string respecting the user's language settings. opw-5485801 Forward-Port-Of: odoo/odoo#244042
This update resolves an issue where the Point of Sale (POS) system would become unusable after archiving a journal associated with a payment method. The change prevents archiving a journal while it's linked to a POS payment method, ensuring smooth POS operation. This improves stability and prevents disruptions during sales transactions.
Original PR description
Currently, in pos, we only prevent archiving `account.journal` records when a payment in an active pos session is linked to that specific journal. This can lead to issues if a journal is archived while being linked to a `pos.payment.method`. In this commit we prevent that from happening, by only allowing the archival of `account.journal` records when they are not linked to `pos.payment.method`. Steps to reproduce: - in payment method configuration set the journal bank on your card payment method - Link this payment method to your POS - Archive the bank journal in the backend - Open POS - Make a sale - Close register - You're stuck because the POS cannot input the journal item into the archived journal Task 5896123 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247015
This update resolves an issue where duplicating a warehouse with a Point of Sale (POS) operation type resulted in only one instance being created. The fix ensures that both the original and duplicated warehouses correctly inherit and duplicate the POS operation type, improving data consistency and functionality.
Original PR description
## Short functional explanation of the error When duplicating a warehouse, if it has an PoS operation type, this operation type will not be duplicated. On the other hand, all other operation types…
## Short functional explanation of the error When duplicating a warehouse, if it has an PoS operation type, this operation type will not be duplicated. On the other hand, all other operation types will be duplicated. ## Reproduction Steps 1. Make sure PoS and inventory are well installed. 2. Go to inventory. 3. Click on configuration, then warehouse. 4. Select a warehouse, click on action, then duplicate. 5. Click on configuration, then on Operation Types. ### Expected behavior We should be able to see 2 instances of PoS operation type: one for the original company, and one for the copy. ### Unexpected behavior There's only one instance of PoS operation type, which is related to the original company. ## Origin of the issue PoS operation type is a model inherited from stock.warehouse, and no copy method was defined. Therefore, upon duplication, the copy method of the original stock.warehouse was called, leading to issues with the field created in the inherited version. __ opw-4991271 Forward-Port-Of: odoo/odoo#227635 Forward-Port-Of: odoo/odoo#222694
This update corrects an issue where the Product Configurator dialog's border radius was unintentionally changing due to button styling. The fix ensures a consistent and professional look across all industries, resolving a visual inconsistency that impacted customer experience. This change improves the overall design and usability of the product configurator.
Original PR description
`Description of the issue this PR addresses:` The Product Configurator dialog border radius was unintentionally affected by button styling. The dialog inherited its border radius from the…
`Description of the issue this PR addresses:`
The Product Configurator dialog border radius was unintentionally affected by button styling. The dialog inherited its border radius from the $btn-border-radius variable, which is intended only for buttons and is customized in the design template.
`Current behavior before PR:`
- The Product Configurator dialog uses --modal-border-radius: #{$btn-border-radius};.
- $btn-border-radius is customized to make buttons fully rounded.
- Due to this linkage, the dialog border radius changes unintentionally.
- The issue is reproducible across multiple industries such as electronic_store, outdoor_activities, and team_sports_club.
`Desired behavior after PR is merged:`
- The Product Configurator dialog no longer depends on $btn-border-radius.
- Dialog border radius remains consistent and independent of button styling.
- Button border radius customization does not affect modal dialogs.
- Styling remains consistent across all affected industries.
Task ID: 5913300This update resolves issues preventing correct QR code generation on POS invoices, particularly when ZATCA invoice processing encounters problems. The fix ensures invoices and receipts display the appropriate QR code format, improving compliance and usability for users. It addresses both incorrect QR codes on reprinted invoices and the display of phase 2 QR codes when e-invoicing is disabled.
Original PR description
Ensure proper handling of QR code generation and POS EDI behavior by fixing multiple issues across invoice reprints and journal onboarding. QR codes now correctly appear on reprinted invoices when…
Ensure proper handling of QR code generation and POS EDI behavior by fixing multiple issues across invoice reprints and journal onboarding. QR codes now correctly appear on reprinted invoices when journal problems occur during order confirmation. POS correctly falls back to the Phase 1 flow when the journal is not onboarded and electronic invoicing is not enabled. Additionally, POS receipts now display the proper Phase 1 QR code whenever the EDI module is installed. Problem 1: If ZATCA does not properly receive the invoice generated from a POS order (wrong onboarding, wrong details on company, etc.) the invoice printed from POS will not contain the QR code, even after successfully resubmitting the invoice to ZATCA, load the order and reprint the invoice to see this Testing the fix: Change the VAT number on the company to be faulty, create a POS order, Fix the VAT number and resubmit the invoice, load the POS order and reprint invoice, it will now show the QR code. Problem 2: When disabling the E-invoicing for a phase 2 journal, the POS receipt will still try to print the phase 2 QR code but the system will flag it as 'not legal' leaving the POS receipt empty, when it should instead print the phase 1 QR code Testing the fix: On the journal, disable the E-invoicing, and create a POS order, it will now show the phase 1 QR code on the receipt task-5032474 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#246932 Forward-Port-Of: odoo/odoo#234945
This update fixes a visual issue in the Expenses app where the layout would become distorted when there were no expenses to process. The fix ensures a consistent and stable workspace for the 'Upload or Drop Your Receipt' helper, preventing misalignment and overlapping elements. This improves the overall user experience.
Original PR description
Steps to reproduce: 1. Open the Expenses app and navigate to 'Expenses to Process'. 2. Ensure no expenses are present so that the 'Upload or Drop Your Receipt' helper appears. 3. Remove filters. 4.…
Steps to reproduce: 1. Open the Expenses app and navigate to 'Expenses to Process'. 2. Ensure no expenses are present so that the 'Upload or Drop Your Receipt' helper appears. 3. Remove filters. 4. The layout becomes 'disturbed'—the upload overlay misaligns and overlaps the dashboard. Issue: The issue occurred because the SCSS selector was incorrectly targeting the combination of .hr_expense and .o_list_view. In the Odoo DOM structure, the hr_expense class is added to the Renderer via XML, while o_list_view is assigned to the main Controller. Because the selector never matched an actual element, the min-height: 100% rule remained inactive. Without a stable minimum height, the Renderer container collapses when empty. This prevents the 'Pink Overlay' from having a stable anchor point, leading to layout shifts and visual interference with the Search Panel and Dashboard headers. Solution: Update the SCSS selector to target &.o_list_renderer and &.o_kanban_renderer. This ensures the rule correctly matches the element carrying the hr_expense class. By forcing a min-height: 100% !important on the renderer itself, the container remains stable regardless of the data count. This provides a consistent workspace for the 'No Content' helper to render without disrupting the surrounding flexbox layout. opw-5452618 Forward-Port-Of: odoo/odoo#247366
This update corrects a technical issue where some track visitors were missing essential information, causing errors when users accessed event tracks. The fix adds checks to ensure valid visitor IDs are used, preventing these errors and improving the stability of the event tracking feature. This ensures a smoother experience for users browsing event tracks.
Original PR description
[1] added asserts preventing the use of falsy ids when browsing. To compute "wishlist_visitor_ids" we did not take into account that some "track visitors" don't have a visitor set. Leading to a traceback when opening some tracks. [1]: 4290724a4c8c57fba4f4d3d688d38f65dadcc38f task-5911184
This update fixes a recent issue where creating new projects from templates was blocked when project stages were enabled in the kanban view. The change ensures users can now seamlessly create projects from templates, regardless of whether project stages are active, improving workflow efficiency.
Original PR description
In a previous commit, the feature allowing to create a new project from project templates was mistakenly removed in kanban view, when project stages were enabled. This commit resolves the issue, so to still be able to create a project from templates with project stages enabled. task-5877215
This update enhances the Glory cash machine integration within the POS system, streamlining the user interface and fixing several technical issues. Key improvements include clearer cash display, reduced UI clutter, and optimized communication with the Glory machine for better performance.
Original PR description
- Cash machine UI in the POS has been cleaned up - Reset button and Download logs button have been moved to the backend. - Warnings about low cash now take up less space. - The cash inserted amount…
- Cash machine UI in the POS has been cleaned up
- Reset button and Download logs button have been moved to the
backend.
- Warnings about low cash now take up less space.
- The cash inserted amount is now shown inside the payment line status
box.
- Shortcut to the Glory admin page has been added to the payment method
form.
- Error detail text is now shown when provided by the cash machine.
- Bugfixes
- There should no longer be multiple disconnected popups appear if the
tab is left inactive for a while.
- The session/occupy settings of the connected Glory machine are now
respected, this reduces the number of requests sent when they are
not enabled.
- Some tests have been added for the Glory service.
In order to add Glory functionality in the backend, the Glory service was split into two components. The `glory_service.js` file handles all the communication with the Glory machine, but it doesn't handle the POS integration at all. The POS side is now handled by `payment_glory.js`. This means that in the backend we can still use `glory_service.js` to interact with the machine without being in the POS.
task-5891688
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#246986This update resolves a discrepancy in how the 'Line Extension Amount' is calculated within the account_edi_ubl_cii module. The change ensures accurate untaxed and total amounts in invoices, addressing a potential inconsistency related to global tax rounding. This improves invoice accuracy and compliance.
Original PR description
…-10] According to [BR-CO-10], LineExtensionAmount should be: <quantity> * <price_unit_wo_tax> + charges - allowances It was implemented as: <quantity> * <price_unit_wo_tax> + charges - allowances + <delta_total_excluded> <delta_total_excluded> is needed because it's the additional delta distributed by the global rounding of taxes accross the lines. If you don't add it, you will change the untaxed and total amount of your document. Instead, this commit adds 2 new values in the base_lines's tax_details: gross_total_excluded & discount_amount being the rounded versions of raw_gross_total_excluded & raw_discount but taking care of maintaining a global consistency regarding the global rounding. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#247423 Forward-Port-Of: odoo/odoo#246382
This update fixes a visual problem where call cards overlapped when a video stream was active in a chat window. The change ensures that call cards now maintain a standard 16:9 aspect ratio when a video is present, improving the user experience during video calls. This resolves a previous display issue.
Original PR description
Before this commit, when in a call in a chat window and someone in call stream video, the cards were overlapping. This happens because [1] removed the `w-100` on `<video>` which let them have bigger width than imposed by `arrangeTiles`. This change was motivated because the card has aspect ratio of 1 in chat window and this was too small. However the correct fix was to impose the 16:9 ratio on cards when there's at least 1 video stream, which is what this commit does. Task-5917628 [1]: https://github.com/odoo/odoo/pull/241924 Before / After <img width="387" height="607" alt="Screenshot 2026-02-06 at 16 58 51" src="https://github.com/user-attachments/assets/39569572-4eea-4d58-a383-27f9c69e4bb5" /> <img width="386" height="600" alt="Screenshot 2026-02-06 at 16 58 29" src="https://github.com/user-attachments/assets/f9b60e9a-6980-4708-b475-14f9d5a77a36" />
This update fixes a technical issue that prevented the live chat composer from correctly displaying its open state. The change updates a selector used in testing, ensuring the live chat functionality works as expected for users. This resolves a reported error and improves the overall user experience.
Original PR description
Purpose of this commit, To update the selector for asserting the presence of the livechat chat window in open state. runbot error - https://runbot.odoo.com/odoo/error/232912
This update fixes a minor issue where the channel name wasn't displayed in invitation dialogs when inviting members to Discuss channels. Now, the channel name is correctly shown, improving the clarity and usability of the invitation process. This ensures users have the necessary context when extending discussions.
Original PR description
Before this PR, when a user opened any Discuss channel and invited people from the member list, the channel name was missing in the invitation dialog. This commit fixes the issue by correctly displaying the thread name in the invitation dialog. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where delivery valuations weren't accurately reflecting the existing stock levels (FIFO method) during order fulfillment. The change ensures that the quantity already delivered is properly accounted for, leading to more precise cost of goods calculations. This improves the accuracy of financial reporting.
Original PR description
Steps to reproduce: - Have a product valued in fifo - Create 3 PO for it, each for 1 qty of price 10, 20 and 30. - Confirm these PO & validate their receipts - Create 2 SO for this product, each for 1 qty - Confirm these SO & validate their deliveries together Issue: The value associated to the delivery moves (and so the cogs generated from them) is 10 for both. When calling `_action_done()` on the moves, we'll set the value of each move before moving them. To get the correct value from the fifo stack, we rely on the `qty_available` at the time. However, since we're going to set the value of multiple moves before validating them, the `qty_available` won't be updated between each call. opw-5359484 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238680
This update resolves an issue where tests within the Sale Stock module were previously disabled. The team has re-enabled these tests, ensuring the continued stability and reliability of the Sale Stock functionality. This change improves the quality and trustworthiness of the Odoo system.
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#246522
This update resolves an issue where incorrect data related to vendor refunds was being imported through the account_edi_ubl_cii module. The fix prevents this import, ensuring accurate financial reporting and compliance. This change improves data integrity and avoids potential errors in accounting processes.
Original PR description
opw-5870516 opw-5898302 opw-5917394 opw-5892671 Forward-Port-Of: odoo/odoo#247619
This update resolves a problem where time off requests weren't being correctly processed, specifically when reporting to the next month. The issue stemmed from a rounding error that created a tiny, incorrect work entry. This fix ensures accurate time off calculations and reporting, preventing potential payroll discrepancies.
Original PR description
STEP TO REPRODUCE: ------------------ 1- Set to an employee a schedule of 7h36 hours per day 2- Create a payslip for him on february and pay it 3- Create a time off from 28th debruary to 4th of march 4- Approve it and click on the button "Report to Next Month" You will have an issue but you should be able to do it REASON: ------- A rounding issue caused the creation of work entry of 1*10^-15 hours
This update prevents the daily automatic execution of a reporting cron job, which was causing unnecessary database activity. By changing the cron interval to 9999 months, the reporting process now runs only when triggered, improving system stability and performance. This resolves a potential issue impacting Odoo's responsiveness.
Original PR description
The cron interval is updated from 1 day to 9999 months to effectively Disable automatic execution. The workflow is fully real-time and trigger-based, and running this cron Daily would unnecessarily wake up registries and databases. task-5885482 Forward-Port-Of: odoo/enterprise#106264
This update resolves an issue where products with a zero price were being sent to UrbanPiper during menu synchronization, causing problems for their system. The change now excludes these zero-price products from the sync process, ensuring smoother integration with UrbanPiper and preventing potential errors.
Original PR description
Before this commit: --- - During menu sync, charge products with a price of zero were sent to UrbanPiper which caused issues on the UrbanPiper side. After this commit: --- - Exclude charge products with a zero price from the menu sync. task-5867272 Forward-Port-Of: odoo/enterprise#106491 Forward-Port-Of: odoo/enterprise#105861
This update resolves a bug where time off requests weren't being correctly processed, leading to inaccurate payroll calculations. Specifically, a rounding error was creating a tiny work entry, causing a reporting issue when 'Reporting to Next Month' was used. The fix ensures accurate time off deferral and payroll processing.
Original PR description
STEP TO REPRODUCE: ------------------ 1- Set to an employee a schedule of 7h36 hours per day 2- Create a payslip for him on february and pay it 3- Create a time off from 28th debruary to 4th of march 4- Approve it and click on the button "Report to Next Month" You will have an issue but you should be able to do it REASON: ------- A rounding issue caused the creation of work entry of 1*10^-15 hours Forward-Port-Of: odoo/enterprise#106473
This update fixes an issue where Odoo didn't correctly reconcile bank transactions with credit notes. Now, when a credit note is applied to an invoice and the bank transaction is marked 'fully paid', the system accurately reflects the remaining balance ($800 in this case) during bank reconciliation. This ensures accurate financial reporting.
Original PR description
1. Create an invoice for $1,000 2. Create a credit note of $200 and apply it to the invoice. The invoice is marked 'partially paid.' The remaining due is $800. 3. Create a bank transaction of $700, reconcile with the invoice. 4. Edit the counterpart line, and click "fully paid". >>> Odoo does not consider the credit note and uses the full amount of $1,000 instead of the remaining due of $800 to reconcile. With the refactor of the bank rec, the way the amount is show is computed from econciled_lines_excluding_exchange_diff_ids in apply_amount.js which only takes into account the direct invoice and not the credit notes (in _compute_reconciled_lines_excluding_exchange_diff_ids it take the matched debit and matched credit so only the partial between the transaction and the move) opw-5485663 Forward-Port-Of: odoo/enterprise#105197
This update fixes an issue in the French P&L report where accounts 65 were incorrectly categorized. The accounts have been moved to the 'Other Expenses' line, ensuring accurate financial reporting and compliance with French accounting standards. This improves the clarity and reliability of the financial data.
Original PR description
On the french P&L, accounts 65 are refferenced in the line 'Other purchases and external charges' but this is not where those accounts need to be, they need to be part of the line 'Other Expenses' task-5446018 Forward-Port-Of: odoo/enterprise#106465 Forward-Port-Of: odoo/enterprise#103357
This change resolves an issue that prevented subscription cancellations for internal users (like 'Mitchel Admin'). The fix uses 'sudo' to allow necessary updates to the partner record during cancellation, preventing access errors. This ensures subscription cancellations function correctly regardless of the user's role.
Original PR description
*: sale_subscription_partnership To reproduce: ============= 1/ be sure Marc Demo has only sales admin righ 2/ as admin create a subscription with customer = Mitchel Admin (or other internal user) and confirm it (only confirm, do not invoice) 3/ as demo, cancel the SO => Acccess error on res.user Problem: ======== When cancelling a subscription we want to write some fields on the partner related to the SO. If the partner is an internal user, and the current user has no access to write on res.users, we get an access error. Solution: ========= Use sudo when writing on the partner when cancelling a subscription. opw-5857627 Forward-Port-Of: odoo/enterprise#106393 Forward-Port-Of: odoo/enterprise#105901
This update fixes a problem that prevented the 'hr_expense_stripe' module from installing correctly in certain countries where Stripe payment processing isn't supported. The fix removes a redundant check, allowing the module to function properly in locations without Stripe integration. This ensures a smoother installation experience for all users.
Original PR description
[FIX] hr_expense_stripe: error when installing loca not supported Step to reproduce the bug: - install 'hr_expense_stripe' - try to install a localization where Stripe is not available (e. g. Romania) - The error raise This is due to an @api.constrains that can be removed no-task Forward-Port-Of: odoo/enterprise#106351
This update resolves an issue where closed tickets with high priority were incorrectly displayed in the Odoo Mail Plugin. The fix filters out tickets in 'folded' stages, ensuring users only see active, open tickets related to a contact. This improves the user experience and prevents outdated information from being shown.
Original PR description
**Steps to reproduce:** - Install Mail_plugin - Setup the outlook mail plugin in Outlook - Once connected, click on a mail from a contact on the database - Click on the Odoo Inbox Addin. action - Under the contact 5 related tickets are showed - Create 5 tickets with priority and put them in folded stage (closed) - Create new normal tickets - User can't see new tickets in the plugin **Issue:** The search is done on priority and then id ordering, this means that tickets in folded stages (closed) which have a high priority are always showed first. Tickets in a folded stage are considered as closed, so they should not appear anymore in the contact data to avoid displaying them indefintely. **Fix:** Adapted search domain and removed fold attribute in the answer. opw-5075477 Forward-Port-Of: odoo/enterprise#100883
This update resolves an issue where the POS ID wasn't correctly transmitted to the blackbox, impacting the generation of receipts. A secondary change restricts blackbox device selection within the POS configuration, enhancing data security and accuracy. This ensures proper receipt generation and improved data integrity.
Original PR description
When using a v1 CleanCash blackbox, the command being sent to the blackbox was mistakenly sending a POS ID of " ". It just so happened this worked correctly when testing with our blackbox because it had " " registered as a POS ID. The POS ID is now sent correctly. Another small fix was made to only allow selecting blackbox devices in the Fiscal Data Module field in the POS config settings. task-5077448 Forward-Port-Of: odoo/enterprise#106431
This update fixes a minor issue where the system repeatedly asked users to select an employee when adding goals to an appraisal. The change ensures the system correctly identifies the employee from the appraisal, streamlining the goal creation process and improving user efficiency. This prevents unnecessary steps and reduces potential user frustration.
Original PR description
When adding goals from an employee appraisal, Appraisal of an employee > Goals > Open Library > Select Goals > Continue On the next screen, you need to select the employee, but you come from an employee appraisal! The employee was already known but the flow still asked to re-select an employee again. - The root cause was the employee context was passed as a list while goal creation expects a single employee. - This fix adapts the context so goals are directly created for the current appraisal employee. task-[5420664](https://www.odoo.com/odoo/project/1251/tasks/5420664) Forward-Port-Of: odoo/enterprise#102751
This update resolves a problem where test cases for Indian GST reports were failing due to a recent change in how payment references are handled. The test cases have been updated to correctly reflect the new label format, ensuring accurate reporting of Indian GST data. This change was prompted by a previous community fix.
Original PR description
Before: - Test cases in Indian GST reports were failing because they expected payable line labels like `installment #1`, but after the community fix (Task: 4982864), payable lines are now populated with the bill reference when Payment Reference is empty, resulting in labels like `TEST/0001 installment #1`. After: - Modified test cases to expect the new label format that includes the bill reference. Related PR (Community) : https://github.com/odoo/odoo/pull/221491 Task: 4982864 Forward-Port-Of: odoo/enterprise#106573 Forward-Port-Of: odoo/enterprise#91535
This update resolves an issue related to the accurate transmission of coordination deductions for Swiss payroll (l10n_ch_hr_payroll). The fix ensures that deductions are calculated and reported correctly, aligning with Swiss tax regulations. This improves the reliability of payroll reporting for our Swiss clients.
Original PR description
Forward-Port-Of: odoo/enterprise#106615
This update fixes a potential issue where the system wasn't correctly processing weight readings from the scale, particularly when using a 'read_once' action. The change ensures that all weight readings, regardless of the action used, are properly recognized and handled, improving the reliability of scale data collection. This ensures accurate inventory tracking.
Original PR description
This commit adjusts the callback when a new weight is received from the scale to also handle the case where it is the response to the `read_once` action. In this case, the `status` key is `success`. backport of: odoo/enterprise#105324 Forward-Port-Of: odoo/enterprise#106691
This update resolves an issue where changes made to spreadsheets were lost after deleting archived revisions. Now, when you delete all archived revisions and reload the spreadsheet, your latest edits are preserved, ensuring data integrity and a smoother workflow.
Original PR description
Steps to reproduce - create a spreadsheet - do a few changes - leave the spreadsheet (to snapshot) - reopen the spreadsheet - do a few more changes - from another tab, go to Settings/Technical/Revisions - delete all archived revisions - reload the spreadsheet => the last changes are lost and new changes are no longer saved. Forward-Port-Of: odoo/enterprise#99357
This update fixes a minor issue where payment links were sometimes displayed even when the subscription was expired and related products had been removed. Now, the 'Pay Now' link only appears if the advance payment section is visible, ensuring a cleaner and more accurate user experience for subscription renewals.
Original PR description
When the subscription is expired and has to be paid, only use an anchor for `Pay Now` if the advance payment section is displayed (it could be hidden for ex. if any of the product has been archived) Forward-Port-Of: odoo/enterprise#105879 Forward-Port-Of: odoo/enterprise#105480
This update fixes an issue where the selected card in the appointment scheduling interface would lose its outline when navigating between months. The fix ensures the selected card remains clearly highlighted, improving usability and preventing confusion. A styling adjustment was also made to ensure consistent outline appearance across the interface.
Original PR description
Starting from version 19.1, the user / resource manual selection for appointments has been moved to a grid of cards when picking the user / resource first in the front-end. However, when using chevrons to navigate between month, the selected card looses its outline, making it hard to understand which one is selected. This is because we removed the first 'active' class without checking what is was linked to. Fix: only remove the one on the day element, as it is meant to be (as the day should not be selected anymore when changing month) Also add an '!important' on the outline class, as a strange behavior from existing styling was messing with it depending on its focus and focus-visible properties. To reproduce: select a user. Then click anywhere on the page. The card outline was first thin, then thicker. Now, the behavior is consistent across cards and btns on that page. Task-5870725
This update fixes an issue where draft and cancelled accounting entries were incorrectly included in tax return calculations, leading to inaccurate tax return amounts. Now, tax returns accurately reflect the values in related reports by excluding entries in draft or cancelled states, ensuring data integrity.
Original PR description
Behavior before: When generating tax returns, accounting entries linked to tax group accounts were included in the calculation even if they were in draft or cancelled state. As a result, tax returns…
Behavior before: When generating tax returns, accounting entries linked to tax group accounts were included in the calculation even if they were in draft or cancelled state. As a result, tax returns displayed incorrect amounts. Behavior after: Tax return amounts now correctly match the values shown in the corresponding reports. Entries in draft or cancelled state are excluded, eliminating discrepancies in tax return calculations. Root cause: The domain used in the _add_line method did not filter entries based on their parent_state. This caused all related accounting entries—regardless of their posting status—to be included in the calculation. Steps to reproduce: 1. Create accounting entries using an account that is part of a tax group. 2. Set the entries to draft or cancelled state. 3. Generate a tax return for the current period. 4. Observe that amounts from draft or cancelled entries are included in the tax return. OPW: 5417293 Forward-Port-Of: odoo/enterprise#106101
This update resolves an issue where changing a commission plan's frequency (e.g., from quarterly to monthly) didn't properly remove outdated periods, leading to incorrect commission calculations. The fix ensures that old periods are removed when the target frequency is updated, streamlining commission reporting and preventing double-counting.
Original PR description
## Issue When changing the *Target Frequency* of a commission plan, previously created periods are not removed. ## Steps to reproduce 1. Install *Sale Commission* (`sale_commission`) 2. Create a…
## Issue
When changing the *Target Frequency* of a commission plan, previously created periods are not removed.
## Steps to reproduce
1. Install *Sale Commission* (`sale_commission`)
2. Create a *Commission Plan*. The default *Target Frequency* (`periodicity`) should be *Quarterly*. In the *Periods* tab, 4 periods (`targets`) are present.
3. Change the *Target Frequency* to *Monthly*
4. **New monthly periods are added, but the quarter periods are not removed**
This behavior leads to a second issue:
5. Following the previous steps, set the current user as a Salesperson the *Sales People* tab
6. Approve the Commission Plan
7. Create an invoice
- Any customer
- Add a product with a price of $100
- Confirm the invoice
8. Go to Sales > Commissions > My Commissions
9. **The invoice impacted multiple commission targets, because the current period is covered multiple times (by the monthly and the quarterly frequencies)**
## Cause
This issue was introduced by https://github.com/odoo/enterprise/commit/e7693f3c61044f689da87218235cd985e26f75d5. The commit aimed to preserve periods when updating the *Effective Period* of a commission plan. In fact, in some cases, it is unnecessary to delete all periods because some of them belong to both the previous and the updated effective period.
https://github.com/odoo/enterprise/blob/2dd98eed0559b6217ef8467f1d56c171d546b85b/sale_commission/model/commission_plan.py#L106-L108
When updating the *Target Frequency* of a commission plan, the *Effective Period* is unaffected, making the `target_changes` list empty. This leads to none of the periods being deleted, eventhough they don't respect the new periodicity.
## Fix
The condition to add periods to the `target_changes` list needs to updated, as it needs to also take in account the periodicity of the commission plan. The `expected_target_duration` needs to be a range, as it depends on the (variable) length of the months that are concerned. These ranges were chosen by looking at the sizes of each period. A margin of one day is added for the "year" case to handle leap years.
<img width="687" height="367" alt="5877405" src="https://github.com/user-attachments/assets/065b0d21-0860-4435-9f9b-55feef789da6" />
## Test
The test `test_commission_target_constraint` was using the fact that the periods were not deleted when updating the periodicity to test against the creation of overlaps between periods. As this is no longer possible, the test was updated.
opw-5877405
Forward-Port-Of: odoo/enterprise#105813This update resolves a technical issue that caused a SQL error when creating invoices with non-deductible tax values in Studio. The fix ensures the system handles unsaved invoice lines correctly, preventing the error and improving data integrity. This change primarily impacts the accounting module.
Original PR description
**Steps to reproduce:** * Install **account_asset** and **l10n_be**. * Enable **developer mode**. * Using **Studio**, add the field **non_deductible_tax_value** to invoice lines. * Create a new invoice. * Select a partner and add a product with **21% VAT** applied. * Do not save the invoice before adding the line. **Observed behavior:** * A **SQL syntax error** occurs: `WHERE tdq.base_line_id IN ()`. * The error is triggered when accessing the non-deductible tax value on unsaved records. **Cause:** * `_compute_non_deductible_tax_value()` executes SQL query with `tuple(self.ids)`. * For unsaved records, `self.ids` is empty, creating invalid SQL `IN ()` syntax. * This path is only reached for **non-deductible taxes**. **Fix:** * Skip the SQL query when no record IDs are available. * Return a default value for unsaved records. opw-5896716 Forward-Port-Of: odoo/enterprise#106655 Forward-Port-Of: odoo/enterprise#106470
Documentation and clarification updates
This pull request updates the Adhoc Corporate Legal Agreement (CLA) membership list. This ensures our development team adheres to Odoo's legal guidelines and licensing requirements. The change was made to formally add new contributors, reflecting recent onboarding processes.
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#247183