Monday, April 13, 2026
25 changes · saas-19.1
Resolved issues and error corrections
This update resolves an issue where Odoo displayed a misleading 'This message has been removed' notification in the chatter when an approval request was canceled before a purchase order was created. The fix ensures that chatter messages are only logged when there's actual information to display, improving the user experience and clarity.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install `approvals_purchase` module with demo 2. Approvals > New Request in Borrow Items 3. Create request with any product 4. Click on the Submit button 5. Click on the Cancel button Observation: ------------------------------------ In chatter there's a message stating: 'This message has been removed' Issue: ------------------------------------ When you cancel an approval request that has no purchase orders created yet, the `_log_po_cancellation_to_chatter` method is called with an empty `cancellation_log_msg` string, which causes Odoo to display 'This message has been removed' in the chatter. Solution: ------------------------------------ Only log to chatter if there's actually a message to log opw-6063998 Forward-Port-Of: odoo/enterprise#112454
This update enhances the logging of Stripe payment rejections for expense reports. Now, the MCC code is recorded alongside the MCC name, providing more detailed information for troubleshooting and resolving payment issues. This improves our ability to understand and address problems with expense payments.
Original PR description
Before this commit: - Only the MCC name was logged when Stripe refused an MCC. After this commit: - The MCC code is now logged along with the MCC name for better clarity and debugging. task-6084569 Forward-Port-Of: odoo/enterprise#112599
This update ensures that CSV files are now correctly recognized as viewable within Odoo's list views, mirroring the behavior in the Kanban view. Previously, CSV files were only accessible through the Kanban view, creating a discrepancy in functionality. This change enhances user experience and simplifies file access.
Original PR description
Current behavior before PR: - CSV files were viewable from the Kanban view, and opened the spreadsheet conversion dialog - In list view, CSV files were not considered viewable - Same issue for trashed CSV files in list view Desired behavior after PR is merged: - Consider CSV files as viewable in list view - Align behavior with the Kanban view Task: 6052134 Forward-Port-Of: odoo/enterprise#113453 Forward-Port-Of: odoo/enterprise#112869
This update resolves a warning message that appeared when employee contracts partially overlapped with payslip periods. The fix ensures that contracts with even a single overlapping day are now processed correctly without triggering the warning. This improves the user experience and prevents unnecessary alerts.
Original PR description
[FIX] hr_payroll: fix payslip warning bug Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make…
[FIX] hr_payroll: fix payslip warning bug
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#109791This update resolves an issue where the 'Results Brought Forward' line on the Luxembourg balance sheet displayed incorrect values. The fix adjusts how the system calculates this line, ensuring it accurately reflects the year-end affectation process for Luxembourg companies. This improves the reliability of financial reporting.
Original PR description
… sheet Steps to reproduce: - Use a Luxembourg company - Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412) - Open the Luxembourg balance sheet (full or abbreviated)…
… sheet
Steps to reproduce:
- Use a Luxembourg company
- Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412)
- Open the Luxembourg balance sheet (full or abbreviated)
Issue:
Line "V. Profit or loss brought forward" shows incorrect values.
Cause:
The `accounts` expression for that line used `account_codes` engine with formula `-14`, which only sums accounts by code prefix. Account 1412 ("Results brought forward (assigned)") was typed as `equity`, so its balance was carried forward as an initial balance instead of being captured as retained earnings in the formula.
Solution:
- Set account 1412 to `equity_unaffected`, consistent with account 142.
- Change the `accounts` expression of Line V in both the full and abbreviated balance sheet to use the `domain` engine: `['|', ('account_id.code', '=like', '14%'), ('account_id.account_type', '=', 'equity_unaffected')]` with subformula `-sum`. This correctly captures the balance of all 14x accounts and any `equity_unaffected` accounts, which covers the standard year-end affectation workflow.
opw-5883505
Forward-Port-Of: odoo/enterprise#111328This update fixes a misleading warning in the payroll system that appeared when payslips overlapped with employee contract dates. The change ensures the system correctly handles overlapping periods, preventing unnecessary warnings and improving user experience. This resolves a previous inconsistency between versions 17 and 19.
Original PR description
Bug reproduction: 1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well) 2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026…
Bug reproduction:
1 - Select Hong Kong (actually there is nothing about Hong Kong, you can select other companies as well)
2 - Create an employee and make its contract from 01-01-2025 to 05-03-2026 (DD/MM/YYYY) format.
3 - Generate payslip for March, the warning of "The period selected does not match the contract validity period" popups.
4 - But we do not want that, even though there is 1 overlapping day in contract with payslip we can continue.
Bug cause:
1 - In >= v.17 (not in v.19), there was a warning, when the contract dates do not fully contains the payslip dates, the warning was appearing.
2 - In v.19 it is not the case, when there is a contract that overlaps at least one dat of the payslip then we are fine, if no overlap then no contract on payslip warning should appear
Bug solution:
1 - I replaced old warning "The period selected does not match the contract validity period" with the one in v.19 "No running contract over payslip period"
Tests:
1 - There was a unit test about old warning (test_payslip_warnings), I changed that parts.
2 - I added further steps to the existing test about the new warning that should appear (No running contract over payslip period)
Last Test Update:
1 - I noticed that contract date changes was not affecting the warning appearance directly
2 - Unit test is expanded with contract date change and observing the warning appearance
Note: Implemented feature: need to check what happens after v.17, should be removed in v.19 latest, maybe before as well.
task - 6006693
Forward-Port-Of: odoo/enterprise#113566
Forward-Port-Of: odoo/enterprise#112758This update prevents regular employees from attempting to change the target job within an appraisal. The original issue stemmed from a permissions error when employees lacked access to view company job postings. The fix restricts editing this field to managers, aligning with the intended workflow and improving data integrity.
Original PR description
Steps to reproduce: 1- Create an appraisal for a regular employee 2- Confirm it so its state changes to 'ongoing' 3- Try to change the target job as an employee 4- Click on see more Cause: The main cause is that regular employees lack the privilage to view job postings by a company. therefore an access rights errors is resulted when the flow is executed. Solution: Made the field readonly for normal employees (as it should be, target jobs are the managers' responsibility to change). Forward-Port-Of: odoo/enterprise#112663
This update resolves a visual issue where text in the payroll view would split and misalign with checkboxes when the browser window was resized. The fix ensures all text remains on a single line, maintaining a consistent and professional appearance for users. This improves the user experience and data clarity.
Original PR description
Step to reproduce: play with the width of the window, at some point text splits and item are unaligned. Cause: with some window width, the text is splitted on 2 lines, which makes it unaligned with the checkbox. Solution: force text on same line using style="white-space: nowrap". Task: 6069017 Forward-Port-Of: odoo/enterprise#113386
This update ensures that planning times displayed in the Odoo interface match the format used when generating reports. Previously, planning slots were printed in 24-hour format, creating a discrepancy. This fix standardizes the time format for a more consistent and user-friendly experience.
Original PR description
Steps to reproduce: - Install the Planning module - Open the Planning app - Click the Print action Issue: Planning slots display in 12-hour format in the UI but print in 24-hour format. Cause: A hard-coded time format was used when printing planning slots. Fix: Remove the explicit format and rely on the locale aware short time format. task-5462276 Forward-Port-Of: odoo/enterprise#103359
This update fixes an issue where duplicate checks were being triggered during tax return generation, causing errors. The change prevents the same check code from being applied multiple times, ensuring smoother and more reliable tax return processing. This improves data integrity and reduces potential user disruption.
Original PR description
Steps to reproduce:
- Go to Accounting → Configuration → Accounting → Return Types.
- Open the standard Annual Closing: Corporate Tax return type.
- Select Generic Tax Report as a report in the Report field.
- Navigate to Accounting → Accounting → Closing → Tax Returns.
- Generate the tax return for the selected period.
Issue:
- Duplicate checks with code check_draft_entries are created for the same return, raising:
'You can only have a unique check code for each return.'
This happens because:
- `_check_suite_common_vat_report` adds a Draft entries check.
- `_check_suite_annual_closing` also adds a similar check (No draft entries) with the same code.
- Both run together, causing duplication.
Solution:
- Added `check_codes_to_ignore.add('check_draft_entries')`
in _check_suite_common_vat_report to ensure the check is not generated twice.
opw-6066030
Forward-Port-Of: odoo/enterprise#113393This update corrects payroll calculations in the l10n_be_hr_payroll module to reflect the latest Federal Fiscal Employee (FFE) rates for 2026. This ensures accurate tax and social security deductions for Belgian employees, aligning with current regulations. The change is a technical fix to maintain compliance.
Original PR description
Forward-Port-Of: odoo/enterprise#113426
This update resolves a bug that prevented users from printing labels when validating receipts through the barcode app. The fix involved adding a safeguard to handle situations where the barcode app didn't have the necessary data, ensuring label printing now works correctly.
Original PR description
Given a printer is configured to print a label for product receipts, when the receipt is validated from the barcode app, then a traceback appears. A filter on action.context.active_ids was introduced in https://github.com/odoo/enterprise/pull/106277. When validating the receipt from the purchase app, active_ids is set to the id of the purchase order and the behavior is as expected. When validating the receipt in the barcode app , it is not set (nor was it set in 17.0). The filter therefore crashes because it cannot work on undefined. An optional chaining operator is added to apply the filter only if active_ids is set. The barcode app does not raise a traceback anymore when validating a receipt and the label can be printed. Forward-Port-Of: odoo/enterprise#113146
A recent issue prevented users from accessing server actions correctly within the Documents module. This was caused by a conflict in how the system prioritized views, leading to an unusable interface. This update resolves the conflict by setting a priority for the Documents module's server action view, ensuring proper display.
Original PR description
When the document module is installed, sometimes the server action view that is shown when accessing the server actions from the normal menu can be broken: the model field for instance is no longer visible, which makes the user interface unusable. <img width="723" height="412" alt="image" src="https://github.com/user-attachments/assets/73f6d516-77be-4f66-80dc-033fd8c0cb7c" /> This is because the document module defines a new primary form view for server actions, but does not set a priority for that view. As a result we have 2 primary views, with the same default priority of 16 in the database, and in that case the sorting of view can lead to the document specific view to be selected, when the other one is expected. We fix this by explicitly setting a priority of 32 on the form view in the document module. Forward-Port-Of: odoo/enterprise#112847
This update resolves an issue where new users couldn't be properly linked to employees within the system, resulting in an error message. The fix clears a caching problem that was preventing the correct employee ID from being assigned, ensuring a smoother user onboarding process. This improves the reliability of user management.
Original PR description
In version 19.1, an error occurs when inviting a new user via General Settings and then clicking Manage Users: "The operation cannot be completed: A user cannot be linked to multiple employees in the…
In version 19.1, an error occurs when inviting a new user via General Settings and then clicking Manage Users:
"The operation cannot be completed: A user cannot be linked to multiple employees in the same company."
This happens even when logged in as an admin user with an existing linked employee. The issue stems from the `employee_id` field in the `res_users` model being a context-dependent computed field.
The `self.env.cache` lacks the employee data,
specifically `'res.users.employee_id': {(1, (2, True)): {2: None}}`.
To resolve this, i've used invalidate_recordset for proper clean the cache,
and again get the value of employee_id.
Clicking directly on "Manage Users" sometimes we cannot face an error, possibly a caching issue.
Inviting a user before accessing "Manage Users" results in an error,
<img width="1885" height="964" alt="2026-03-25_16-21" src="https://github.com/user-attachments/assets/8cd7d094-b0ce-42ca-a43f-1081de7ddc70" />
[opw-6041866](https://www.odoo.com/odoo/project/70/tasks/6041866)
[upg-4031096](https://upgrade.odoo.com/odoo/request/4031096)
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-prThis update fixes an issue where the product name displayed in purchase order lines would change when navigating to subsequent pages. The fix ensures the product's original name is consistently shown, improving clarity and accuracy for users managing purchase orders. This resolves a display inconsistency that could lead to confusion.
Original PR description
**Steps to reproduce:** * Install the *Purchase* module * Create a product and set an *Reference* and Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*. * Create a Purchase…
**Steps to reproduce:** * Install the *Purchase* module * Create a product and set an *Reference* and Under the *Purchase* tab, add a vendor and define a *Vendor Product Code*. * Create a Purchase Order with the same vendor set as on the product. * Add the configured product to the *Purchase Order Lines*. * Add the same product again on a second line and save the order. * Activate debug mode * Go to the view:Form and add a limit to have only 1 POL per page * Return to your PO * Go to the second page **Observed behavior:** * The *product display name* in the purchase order lines is different on the second page compared to the first page. **Cause:** * On the first page, purchase order lines are fetched via a web_read on the purchase order. * On subsequent pages, lines are fetched via a web_read directly on the purchase order lines. * The client requests both name and product_id.display_name. product field context includes partner_id, causing product_id.display_name to be computed as the vendor name. * As both values resolve to the vendor name, the original product name is lost, leading to inconsistent display across pages. **Note:** A similar issue was addressed in this commit : https://github.com/odoo/odoo/commit/28d53e0e565e266ca3fa2b67e359b4383fa42c36 * but its consequence it breaks the search using the vendor code/name in POL. * That change was reverted in this commit duo to the there consequence : https://github.com/odoo/odoo/commit/c9e8a802315be27a076ae677b9191c075e4c239d **Fix:** * This ensures the product name is propagated correctly in the form view while preserving search by vendor code or name. --- opw-5170924 Forward-Port-Of: odoo/odoo#258467 Forward-Port-Of: odoo/odoo#240515
This update fixes a minor issue in the Odoo list editor where the cursor wasn't updating correctly after normalizing list items. This ensures a smoother and more intuitive user experience when editing list data, preventing potential confusion for users. This change improves the overall usability of the Odoo interface.
Original PR description
Description of the issue this PR addresses: This PR is a fixup to [[1]](https://github.com/odoo/odoo/commit/77cbdc0120f7ae7d5c777eb946ad568f2caf05d7) where cursor was not updated properly before unwrapping the element. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258558
This update fixes an issue where the border around the cart quantity input appeared stretched and inconsistent after a recent Bootstrap upgrade. The fix ensures the border renders correctly, providing a consistent and professional user experience for customers adding items to their carts. This improves the overall visual quality of the website.
Original PR description
Steps to produce: --- - Install the `E-commerce` module. - Configure a product with a very large price. - Open the product on the website, add it to the cart, and navigate to the cart. Issue: --- -…
Steps to produce: --- - Install the `E-commerce` module. - Configure a product with a very large price. - Open the product on the website, add it to the cart, and navigate to the cart. Issue: --- - The quantity input group appears visually stretched, and the border rendering is inconsistent. Root Cause: --- - After upgrading from Bootstrap 5.1 to 5.3, border utility behavior changed. Classes like `border-end-0` no longer apply unless a base border class is also present. Solution: --- - Explicitly add the `border` class alongside `border-end-0` on the affected elements to restore the intended border styling. Before: --- <img width="822" height="185" alt="image" src="https://github.com/user-attachments/assets/6478083e-f5c1-4374-9c9a-979254eaee3d" /> After: --- <img width="828" height="188" alt="image" src="https://github.com/user-attachments/assets/5a1cb138-c9a5-4508-ad34-64d988904407" /> opw-6075996 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258572 Forward-Port-Of: odoo/odoo#256797
This update fixes an issue where the 'Results brought forward' line on the Luxembourg balance sheet was displaying incorrect values. The change ensures that year-end adjustments are accurately reflected, specifically by correctly categorizing account 1412 and using the appropriate formula to calculate the balance.
Original PR description
Steps to reproduce: - Use a Luxembourg company - Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412) - Open the Luxembourg balance sheet (full or abbreviated) Issue:…
Steps to reproduce:
- Use a Luxembourg company
- Post a P&L result for the year and do the year-end affectation (Dr 142 / Cr 1412)
- Open the Luxembourg balance sheet (full or abbreviated)
Issue:
Line "V. Profit or loss brought forward" shows incorrect values.
Cause:
The `accounts` expression for that line used `account_codes` engine with formula `-14`,
which only sums accounts by code prefix. Account 1412 ("Results brought forward (assigned)")
was typed as `equity`, so its balance was carried forward as an initial balance instead of
being captured as retained earnings in the formula.
Solution:
- Set account 1412 to `equity_unaffected`, consistent with account 142.
- Change the `accounts` expression of Line V in both the full and abbreviated balance sheet
to use the `domain` engine:
`['|', ('account_id.code', '=like', '14%'), ('account_id.account_type', '=', 'equity_unaffected')]`
with subformula `-sum`.
This correctly captures the balance of all 14x accounts and any `equity_unaffected` accounts,
which covers the standard year-end affectation workflow.
opw-5883505
Forward-Port-Of: odoo/odoo#253559This update resolves a minor typo that was causing an error in the PEPPOL integration process. The fix ensures the system handles errors correctly, improving the reliability of data exchange related to PEPPOL compliance. This change is considered low impact.
Original PR description
Correction in a typo from the last commit opw-6102471 Forward-Port-Of: odoo/odoo#258456
This update resolves an issue where attendance records were incorrectly flagged as 'already checked-in' due to incorrect timezone calculations during absence detection. The fix ensures accurate timezone handling, preventing these errors and improving the reliability of attendance tracking, particularly for employees in different time zones.
Original PR description
### Steps to reproduce: - Have a database in timezone America/Asuncion for example - Create an employee - Create an attendance for the day before yesterday from 13h to 19h - Run the absence detection cron - An error will be raised saying the user is already checked-in on that day ### Cause: When trying to create an absence attendance we localized yesterday's midnight into UTC and then apply the employee timezone. Which cause a one-day shift when having a timezone behind UTC as at that point we try to create an attendance on the day before yesterday not yesterday ### Fix: We use the timezone of the employee to localize midnight then get this time in UTC. opw-5930309 Forward-Port-Of: odoo/odoo#258230 Forward-Port-Of: odoo/odoo#257932
A recent update to our UBL export process previously hid the 'Export XML' button for certain invoices. This fix ensures the button appears only when an invoice is actually exportable, improving the user experience and preventing confusion. This change was made to align with updated export functionality.
Original PR description
Problem --------- Since the UBL export refactor, it was not possible to export the XML of non-imported bills and not self-bills. The Export XML option had been removed from the list view in odoo/odoo#255289. The Form view was omitted. Solution --------- Show the button "Export XML" only if the move can actually be exported. opw-6083344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258512 Forward-Port-Of: odoo/odoo#257910
This update fixes a warning message appearing on Odoo.sh production branches during module updates. Previously, the update process was flagged with a warning due to logging a temporary field change. This change lowers the log level to DEBUG, aligning with other processes and ensuring Odoo.sh branches consistently show a green, healthy status.
Original PR description
Description of the issue/feature this PR addresses: During a module update (-u ModuleName), the check introduced by #220983 patches temporarily a field with "company_dependent=True" because the…
Description of the issue/feature this PR addresses: During a module update (-u ModuleName), the check introduced by #220983 patches temporarily a field with "company_dependent=True" because the overriding module is not loaded yet. But currently it is logged as a warning and makes Odoo.sh production branch appears in yellow (warning state), while the update is actually fine. Current behavior before PR: Logs may contain warnings such as: - Patching res.partner.ref with company_dependent=True - Patching product.template.sale_ok with company_dependent=True - Patching product.product.default_code with company_dependent=True even though there is no actual issue (ok normal behavior) The main problem is that this makes Odoo.sh production branches appear not with green status, while the update module is actually fine. Desired behavior after PR is merged: Keep the same mechanism, but lower the log level from WARNING to DEBUG. This aligns the behavior with the "translate=True" patch logic, which is already logged at DEBUG. Having the production branches green. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258444 Forward-Port-Of: odoo/odoo#258326
This update fixes a frustrating user experience where accessing restricted record notifications would result in an error. Now, users are automatically redirected to their inbox when attempting to view notifications for records they don't have access to, providing a smoother workflow.
Original PR description
Currently, when a user clicks on a notification in the messaging menu relating to a record they don't have access to, an access error occurs. This PR changes this behavior so that the user is redirected to the inbox instead. task-5374528 Forward-Port-Of: odoo/odoo#258126
This update fixes an issue where session reports for Point of Sale (PoS) orders with decimal quantities displayed excessive decimal places. The fix ensures that report totals are rounded to the standard two decimal places, providing more accurate financial reporting. This improves the reliability of sales data.
Original PR description
When selling a lot of product with different quantities (quantities with decimals) the session report total by category might have a lot of decimals instead of 2. Steps to reproduce: ------------------- * Open PoS * Make an order with a lot of product and modify the quantities to have random values with decimals * Close the session * Generate the session report > Observation: The total qty by category has a lot of decimals instead of the 2 expected. The same error also happens for the total price Why the fix: ------------ We round each value with their respective precision to make sure we don't have 15 decimals. opw-6039016 Forward-Port-Of: odoo/odoo#257885 Forward-Port-Of: odoo/odoo#256038
This update resolves an issue where Odoo would crash when attempting to export XML for financial moves that didn't have a linked partner. The fix ensures that the export process doesn't attempt to use information that isn't available, preventing the error and improving the reliability of the XML generation.
Original PR description
Issue: Confirmed move without partner get a traceback while opening the cog wheel Steps to reproduce: - Create a misc move without Partner/commercial partner. - Confirm it - Click on the cog wheel button Current behavior: - Traceback Before commit 48983eb6efdd6690f92f2839eedd39d9a288ab42, looping on `move.commercial_partner_id` prevented calling `_get_ubl_cii_edi_format` on empty records. no-task Forward-Port-Of: odoo/odoo#258881