Thursday, March 19, 2026
30 changes · saas-19.2
Enhancements to existing features
This update allows for leave creation even when an employee has a validated payslip, providing greater flexibility for HR. The change relaxes previous restrictions based on payroll impact and disability percentages, ensuring employees can schedule leave without impacting payroll calculations. This improves the user experience for Swiss clients.
Original PR description
Currently we block leave creation if the employee has a validated payslip in that period. In this commit we relax the constraint in the following way, we will allow to put the leave if: - `l10n_ch_swissdec_payroll_impact` is False - `l10n_ch_continued_pay_percentage` and `l10n_ch_disability_percentage` are BOTH 100% if `l10n_ch_swissdec_payroll_impact` is True - `l10n_ch_swissdec_work_interruption` cannot be True in both cases task-5948505 Forward-Port-Of: odoo/enterprise#107847
Resolved issues and error corrections
This update corrects a technical issue in the Account Avatax module, ensuring it correctly identifies the company it's associated with within the system's settings. Previously, a key piece of information was missing, which has now been added to improve data accuracy and functionality. This ensures proper tax calculations and reporting.
Original PR description
Since the beginning `account_avatax` has had all of it's data stored on the company, however, it missed the company_dependent key in settings to mark it as such. This commit fixes that. Followup of odoo/odoo#254242 task-none Forward-Port-Of: odoo/enterprise#110983
This update resolves an error that prevented users from accessing the Timesheets Assistant feature. The issue stemmed from a missing employee record, causing a technical error. This fix ensures the Timesheets Assistant functions correctly for all users, regardless of whether they have linked employee records.
Original PR description
Currently, an error occurs when user opens the Timesheets Assistant. **Steps to Reproduce:** - Install the `timesheet_grid` module without demo data. - Go to `Settings` > Enable `Timesheets Assistant (BETA)`. - Now go to `Timesheets` > `Assistance`. **Error:** `KeyError: False` This error occurs because the current user does not have any linked employee record. As a result, the employee is empty [1], and accessing False in the work days data batch [2] raises the error. This commit ensures that if no employee record is linked to the user, working_hours is set to False. [1]: https://github.com/odoo/enterprise/blob/9d4424088bfda7e89d454a8bd642715a9281913d/timesheet_grid/models/account_analytic_line.py#L392 [2]: https://github.com/odoo/enterprise/blob/9d4424088bfda7e89d454a8bd642715a9281913d/timesheet_grid/models/account_analytic_line.py#L399 sentry-7323160235
A recent update to the document layout, including VAT information, caused a test to fail. This fix addresses a problem where the test's selection process was disrupted by the layout change. The update now correctly resets the editor selection, ensuring the test runs successfully.
Original PR description
Issue The test `test_edit_header_only_company` was failing after updating the document layout to include the VAT block in the company address section. Cause Adding the VAT line modified the DOM structure of the header layout. The tour step inserting the placeholder span no longer correctly set the editor selection, preventing the powerbox from opening and causing the test to fail. Solution Update the tour to explicitly reset the editor selection after inserting the span so that the powerbox can open correctly. opw-5373374 Related Community PR : https://github.com/odoo/odoo/pull/249225 Forward-Port-Of: odoo/enterprise#109924
This update fixes a potential issue with portal messages. Specifically, it adds a test case to ensure that avatar access tokens are correctly handled when a user who authored a message is deleted. This prevents incorrect message formatting and improves data consistency.
Original PR description
For PR https://github.com/odoo/odoo/pull/254175; This commit adds a test case to verify that the portal message formatting behaves correctly when the message author is deleted. The test ensures that the avatar access token is returned when the author exists, and is omitted when the related user and partner are deleted. Error: `ValueError - Expected singleton: res.partner()` sentry-7337698605
This update resolves an issue that prevented Dutch companies from correctly setting accounting periods. The fix corrects a mistake in how tax reporting data was accessed, which was causing a technical error. This ensures that users can now reliably create and manage accounting periods for their Dutch clients.
Original PR description
Creating an accounting period for a Dutch company raises a traceback. Steps to reproduce the error: - Install ``l10n_nl_reports`` and ``accountant`` module with demo data - Switch to NL Company - Go to Accounting > In Tax Returns > Click Set Periods > Set Opening Date > Apply Traceback: ```py 'l10n_nl_reports.ec.sales.report.handler' object has no attribute '_get_tax_tags_for_nl_sales_report' ``` https://github.com/odoo/enterprise/blob/f23c592a933d7e5e5745aea60d0dcc5738249580/l10n_nl_reports/models/account_return.py#L20 In commit [1], Here, ``_get_tax_tags_for_nl_sales_report()`` method is called instead of ``_get_ec_sales_tax_tags()``. which leads to the above traceback. [1]:https://github.com/odoo/enterprise/commit/0a0fa0dae918ec5198a019a3e5be71a919f0e7c6 sentry-7340518330
This update fixes an issue where cancelled vendor bills were incorrectly included in the Sweden accounting SIE export. The fix ensures that cancelled transactions are properly excluded, aligning the export with the general ledger's balance. This prevents inaccurate reporting and maintains data integrity.
Original PR description
Steps to reproduce: - Install l10n_se (Sweden - Accounting). - Create a Vendor Bill with a line using Account 4000 (Cost of goods) for any amount (e.g., 10,000 SEK). - Confirm/Post the bill. - Cancel the bill. - Go to Accounting > Reporting > SIE Export and generate the export for the current year. - Open the downloaded .se file and locate the #RES line for Account 4000. Expected: The balance should be 0.00 (cancelled entries must be ignored, matching the GL). Actual: The cancelled amount (10,000) is incorrectly summed into the exported balance. opw-5901999 Forward-Port-Of: odoo/enterprise#110612 Forward-Port-Of: odoo/enterprise#108767
This update corrects a technical issue that caused incorrect decimal values to be generated in intrastat XML reports for French companies. The fix resolves a problem with how the system processed invoice data, ensuring accurate reporting of intrastat transactions. This improves the reliability of our international trade reporting.
Original PR description
Steps to reproduce: - Select a French company and activate intrastat - Create an invoice with a 100% discount to a european partner and provide intrastat values such as intrastat code, product commodity code, ... and most importantly a weight with a decimal amount. - Create at least one other invoice to a european partner that has a date earlier than the first one (but on the same month) - Go to intrastat report and export the XML (DEBWEB2) and select EMEBI and then Departures. -> Issue: The line that got processed after the one with a 0 value is not properly post-process regarding the integer conversion because we used to iterate on a list that was modified at the same time. opw-5973832 Forward-Port-Of: odoo/enterprise#110971
This update resolves a problem with the tour (guided tutorial) feature within the industry_fsm_report module. The fix ensures that the tour is correctly displayed and functioning as intended, improving the user experience for accessing and understanding this specific reporting functionality. This addresses a minor usability issue.
Original PR description
task-4489657 Forward-Port-Of: odoo/enterprise#111099 Forward-Port-Of: odoo/enterprise#81823
This update clarifies error messages when payments are declined for vendors outside of Belgium. Previously, the message "Country not allowed" was confusing for users. The change now incorporates payment data to provide a more accurate and helpful message, ensuring a better user experience when dealing with international vendors.
Original PR description
A company in belgium creates a card, it's "allowed countries" is set to Belgium by default. If said card is used to pay online on a website ending with .be, it is understandable that the user believes the vendor to be located in Belgium If it is not the case (the vendor is actually in Luxembourg), the payment is refused but the message on the refused expense is unclear "Country not allowed" The change adds the data received to make the decision in the error message task: 5478443 Forward-Port-Of: odoo/enterprise#103974
This update resolves an issue where GS1 barcode filtering would fail due to an incorrect date interpretation. The system now gracefully handles these errors, ensuring that products can be correctly filtered by their barcodes, improving internal transfer accuracy.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal Transfers - Scan the barcode: 15099590225865 to filter transfers by this product barcode Problem: An validation error is raised: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in filter_on_barcode and explicitly reset parsed_results to False, allowing the normal filter on product resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product is correctly filtered opw-5929064 Forward-Port-Of: odoo/enterprise#110679 Forward-Port-Of: odoo/enterprise#110636
This update corrects a recent change that disabled a feature (showSeconds) in the MRP modules. Enabling this feature ensures that MRP modules now accurately display the time remaining on work orders and production schedules. This improves visibility and scheduling accuracy for operations.
Original PR description
Previously, showSeconds was True by default. It has now been set to False by default so we need to enable it for MRP modules.
This update simplifies how emoji data is loaded and managed within Odoo, leading to faster test runs and improved performance. The change reorganizes code to allow for better caching and reuse of emoji assets, addressing a previous performance bottleneck. This ultimately contributes to more stable and efficient nightly builds.
Original PR description
Feature that is aimed to ease and centralize the loading and management of emoji data. Follow-up of https://github.com/odoo/odoo/pull/253344 in the same effort to reduce overall memory consumption and increase performance in tests to restore (some) nightly builds. - Community: https://github.com/odoo/odoo/pull/253078
This update fixes a visual issue in the Partner Ledger report where overdue dates weren't highlighted in red and negative amounts weren't displayed in blue. The change ensures that key financial information is clearly visible, improving the accuracy and readability of financial reports. This enhances the user experience for managing accounts.
Original PR description
commit introducing the issue: https://github.com/odoo/enterprise/commit/6608d5c21a7fb9d57786c2a7618b878e244bd420 Steps to reproduce: - open the partner ledger with some one overdue invoice -> The expected result should be to see the due date in red. -> Negative amounts in the partner ledger should be displayed in blue as well.
This update ensures that follow-up emails for invoices now send the actual invoice PDF attachment, rather than relying on the main attachment. This prevents issues where users might have uploaded alternative PDF documents, ensuring accurate and complete invoice information is sent to customers. This resolves a previous bug related to attachment selection.
Original PR description
Before, the followup emails used the Invoice's main attachment. This is not correct because a user might have uploaded an arb PDF. Only the actual PDF should be sent. Use `invoice_pdf_report_id` instead of `message_main_attachment_id`. opw-5126420 Forward-Port-Of: odoo/enterprise#110894 Forward-Port-Of: odoo/enterprise#98820
This update corrects an issue where incorrect folio numbering occurred when a Customer Accounting File (CAF) wasn't set up. The fix ensures folios are generated correctly, preventing errors and maintaining accurate accounting records. This resolves a potential problem with sequence management and avoids unnecessary system retries.
Original PR description
`l10n_cl_edi` overrides `account.move._get_last_sequence()` to ensure the folio belongs to an available in-use CAF. When no CAF exists at all, `l10n_latam.document.type._get_start_number()` returns 0 and the fallback builds a previous sequence using start_nb - 1. Formatting -1 as `:06d` yields “-00001”, which then propagates to “FAC -00002”, “-00003” and corrupts the sequence chain. In addition, returning an invalid “last sequence” may force `sequence.mixin` to search for a free number under the UNIQUE constraint by retrying increments inside a savepoint and rolling back on UniqueViolation, which is costly when many values are already taken see [ _locked_increment()](https://github.com/odoo/odoo/blob/18.0/addons/account/models/sequence_mixin.py#L352). Now we only reset to the CAF start when an in-use CAF actually exists (start_nb > 0). opw-5918758 Forward-Port-Of: odoo/enterprise#108909
This update optimizes the database by removing unnecessary default values from company and partner records. Specifically, the automatic setting of branch codes and purchase date defaults has been streamlined, reducing data storage and improving performance for businesses using multiple companies. This change ensures a more efficient and responsive system.
Original PR description
On multi-company databases, having the defaults value on res.partner fields can unnecessary bloat the database for other companies with different fiscal package (localization). This commit remove the `l10n_ke_branch_code` field default on `res.partner` - the related field on `res.company` has been converted to a stored-compute + inverse so that partner related to a company automatically get the default value `00` whithout needing to touch other partner records. The `l10n_ke_oscu_last_fetch_purchase_date` default on `res.company` has also been removed, cron already fallback to the same default value when none are provided and will update it anyway after it ran. opw-5220129 Forward-Port-Of: odoo/enterprise#105917
This update corrects a technical issue that prevented users from opening expenses linked to multiple payments. The fix ensures the system handles expenses correctly, regardless of how many payments are associated with them. This resolves a potential error that could occur during upgrades.
Original PR description
**Description:** In previous versions, a single move could have multiple payments linked to it, and that move could also be linked to multiple expenses. When opening expenses from the payment action,…
**Description:**
In previous versions, a single move could have multiple payments linked to it, and that move could also be linked to multiple
expenses. When opening expenses from the payment action, which caused a singleton error when multiple expenses were linked.
This situation can occur during upgrades because older versions https://github.com/odoo/upgrade/pull/9685/changes here is identified allowed creating such records. However, after the removal of expense reports [^1], this type of record can no longer be created in newer versions.
**To fix the issue**
the code now handles multiple expenses instead of assuming a singleton.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2283, in _serve_db
return service_model.retrying(serve_func, env=self.env)
File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 185, in retrying
result = func()
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2338, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2553, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 355, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 794, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/19.0/addons/web/controllers/dataset.py", line 38, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 94, in call_kw
result = method(recs, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/addons/hr_expense/models/account_payment.py", line 37, in action_open_expense
'name': self.expense_ids.name,
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5940, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.expense(22, 21)
```
opw-5494047
upg-3974547
[^1]: https://github.com/odoo/odoo/pull/189701
Forward-Port-Of: odoo/odoo#254167Portal users were experiencing errors when submitting website forms that created tasks. This update resolves a restriction in how the system accesses task details, preventing a 'permission denied' error. The fix uses a special system command to allow access to the necessary data, ensuring smooth task creation for all users.
Original PR description
Currently, submitting a website form that creates a task crash for portal users on the confirmation page. ### **Steps to reproduce:** 1) Install website_project with demo data 2) Create a website…
Currently, submitting a website form that creates a task crash for portal users on the confirmation page. ### **Steps to reproduce:** 1) Install website_project with demo data 2) Create a website form that creates a task 3) Set a project on the form 4) Submit the form as a portal user ### **Error:** `AccessError: You do not have enough rights to access the field project_privacy_visibility on Task (project.task)` ### **Root Cause:** The confirmation template evaluates `task.project_privacy_visibility` in a t-if condition at [1]. since [commit](https://github.com/odoo/odoo/pull/203891/changes/17664b3f118491f954dd6a810521ce5865d51a43), project task restricts portal users to a whitelist of fields defined by [_portal_accessible_fields()](https://github.com/odoo/odoo/blob/b9e3ca44ceb2b0b35b5e91a06f2905e042aa7f89/addons/project/models/project_task.py#L1015-L1019). Field access is then validated in [_has_field_access()](https://github.com/odoo/odoo/blob/b9e3ca44ceb2b0b35b5e91a06f2905e042aa7f89/addons/project/models/project_task.py#L1021-L1031), which denies read access to fields not present in this whitelist. `project_privacy_visibility` is not part of the portal readable fields list. When the template tries to read it, _has_field_access() rejects the operation and raises an AccessError. [1]- https://github.com/odoo/odoo/blob/b9e3ca44ceb2b0b35b5e91a06f2905e042aa7f89/addons/website_project/views/project_portal_project_task_template.xml#L13-L16 ### **Fix:** Use `sudo()` when reading `project_privacy_visibility` in the template to avoid the portal field access restriction. **opw-6010622** Forward-Port-Of: odoo/odoo#254326 Forward-Port-Of: odoo/odoo#254099
This update fixes a bug where the VAT (Tax ID) was not correctly displayed in document layouts like invoices and previews. The issue stemmed from a missing piece of code in the document template. Now, VAT information is accurately reflected in generated documents, ensuring compliance and accurate reporting.
Original PR description
Steps to reproduce 1. Install `account`. 2. Go to Settings → Configure Document Layout. 3. Enter a value in the Tax ID field. 4. Generate a document (invoice / preview document). Issue Unlike other fields in the document layout, the `Tax ID` value is not updated and does not appear in the document preview. Cause The VAT (Tax ID) rendering logic was missing from the document layout template XML. Solution Add proper logic to display the Tax ID using the company VAT Before: <img width="1089" height="750" alt="image" src="https://github.com/user-attachments/assets/8d27808f-d605-447c-807a-d5f3450eef36" /> After: <img width="1080" height="722" alt="image" src="https://github.com/user-attachments/assets/0af04d77-a318-4e39-9a4b-0911f2446e60" /> opw-5373374 Forward-Port-Of: odoo/odoo#249225 Forward-Port-Of: odoo/odoo#240234
This update corrects a technical error in how images are displayed within Odoo's user interface. The fix ensures that images are rendered correctly, resolving a visual issue that may have affected some users. This improves the overall user experience and prevents potential display problems.
Original PR description
Forward-Port-Of: odoo/odoo#254633
This update fixes a visual issue in the table picker component of the Odoo interface. Previously, non-active cells in dark mode didn't have the correct background color. This change ensures a consistent and visually appealing experience across both light and dark modes, improving the overall user experience.
Original PR description
Currently in dark mode, we don't display the right bg color for (non active) cells in table picker. This PR uses the right variable for the bg color of non active cell that is more suitable for both light and dark mode. task-6009282 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252378
This update resolves a potential issue where forum URL title requests could hang indefinitely, causing performance problems. By adding a timeout, the system now responds more reliably and quickly, ensuring a smoother user experience for forum visitors. This improves overall forum stability and responsiveness.
Original PR description
Add a timeout to the requests done by /forum/get_url_title to avoid blocking indefinitely Forward-Port-Of: odoo/odoo#254607
This update resolves a crash that occurred when users clicked directly on images within the To-Do app's image transformation feature. The issue stemmed from a change in how transformation types were handled, leading to an undefined type being created. This fix ensures stable image transformations.
Original PR description
### Steps to Reproduce: - Open the To-Do app. - Insert an image (e.g. using /media). - Select the image. - Click on Image Transformation from the toolbar. - Click directly on the image instead of a transformation handle. - A traceback occurs. ### Purpose of this commit: - Since [commit](https://github.com/odoo/odoo/commit/633267efef54bc6f88d2d6b5517e2dd56ec135f0#diff-7611cc3ab11e330827e96b643deb9605c42512e004f50b1ea12dded7ca6bd63e), the default transformation type value was removed. When clicking directly on the image (instead of a handle), a transformation state could still be created with an undefined type, which later caused a crash in mouseUp. task-5998153 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update prevents a traceback error that occurred when internal users initiated live chat conversations, specifically when the `hr_holidays` module was active. The fix addresses a discrepancy between the user's active company and the information available in the frontend session, ensuring a smoother live chat experience.
Original PR description
...when the `hr_holidays` module is installed. Before this commit, starting a live chat conversation as an internal user would produce a traceback. Steps to reproduce: - Log in as internal user and navigate to the website. - Start a live chat by sending a message -> traceback. This is because since [1] the "back on" banner is loaded in the embed bundle, causing the `employee_id` field to get accessed. The `employee_id` field is computed based on the user active company, which is not present in the frontend session, causing the traceback. This commit fixes the issue by guarding the access to `user.activeCompany`. [1]: https://github.com/odoo/odoo/pull/247141 task-6003634
This update corrects a problem where duplicate entries were being created for work entry types. This fix ensures data integrity within the HR module, preventing errors and streamlining the management of employee work schedules. It's a routine maintenance update to improve the reliability of our core HR functionality.
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
This update resolves an issue where adding attributes to archived product templates caused errors. The fix ensures all variants (active and archived) are counted, preventing template deletion and maintaining archived product variants when their template is archived.
Original PR description
When adding attributes to an archived product template, an error was raised because the template was incorrectly deleted. This happened because variant counting only considered active variants. Now counts all variants (active and archived) to prevent template deletion, and filters variants before activation to keep them archived when their template is archived. @qrtl QT6449 Forward-Port-Of: odoo/odoo#254137 Forward-Port-Of: odoo/odoo#252927
This update resolves an issue where users with limited accounting access couldn't successfully import vendor bills via XML. The fix adjusts how system settings are applied, ensuring that restricted users receive the expected error message when attempting to import. This prevents potential data import issues for users with restricted permissions.
Original PR description
[FIX] account_edi_ubl_cii: restricted access user cannot import bill To reproduce: - create a user that has readonly access in Accounting - try to import a XML in vendor bills -> should traceback This commit modifies the `res_field` assignation by setting both `res_model` and `res_id` at the same time Forward-Port-Of: odoo/odoo#254698
This update fixes a blank page issue when printing the Discuss app, which was caused by overlapping print styles. It also addresses several layout problems like a persistent sidebar and unnecessary UI elements, resulting in a cleaner and more functional print experience for users.
Original PR description
Before this commit, using the brower's print feature without knowledge installed would show a blank page. This occurs because knowledge print assets add an overflow visible rules to a bunch of DOM elements. This commit fixes the issue by doing something similar for the discuss app. Additionally, the print discuss layout has several issues: - The sidebar is hidden but still takes space. - The composer is displayed and takes up space, even though only the conversation content matters. - Thread actions are shown in the discuss header. - Visitor offline banner is shown. This PR fixes these issues. task-6008968 | | | |--|--| |Before|<img width="611" height="385" alt="image" src="https://github.com/user-attachments/assets/d8060268-ed04-45f2-b152-04c7c50a03c2" />| |After|<img width="624" height="407" alt="image" src="https://github.com/user-attachments/assets/41fa26ee-e25d-4495-8d22-088782d9e8e1" />|
This update resolves a visual issue in the mobile version of Odoo where incorrect time off balances were displayed and leave types without limits lacked the 'Available' label. This ensures users see accurate time off information and a consistent mobile experience, improving usability.
Original PR description
This change fixes 2 problems in the mobile UX side panel: - Time off types with zero allocations were shown. - Leave types without a max leave amount didn't show the "Available” label. task-6030539 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253357