Monday, May 11, 2026
24 changes · saas-19.2
New functionality added to Odoo
This update adds Russian language translations for the Odoo accounting module (l10n_uz). This expansion allows Odoo users in Uzbekistan to interact with the system in their native language, improving usability and customer satisfaction. The changes were based on a previous development effort.
Original PR description
Forward-Port-Of: odoo/odoo#263479
Resolved issues and error corrections
This update resolves a technical issue where the payroll amount calculation wasn't working correctly when a default value was set for a specific field. The fix ensures that the calculation is triggered properly, regardless of the default value chosen, leading to accurate payroll processing. This improves the reliability of the HR payroll module.
Original PR description
The compute is not triggered when a default value is assigned to a field. So all property inputs default to 'fix' for amount_select. This removes the default parameter from the field and adds the default value to the compute method. task-6126332 Forward-Port-Of: odoo/enterprise#113102
Documentation and clarification updates
This pull request addresses a legal clarification regarding contributions from BMyA and BML. The changes include signing a contributor license agreement (CLA) and updating documentation to reflect these new partnerships. This ensures compliance and proper recognition of the new developer contributions.
Original PR description
New contributors from BMyA --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261658
This update fixes a bug where the PDF viewer field didn't save the uploaded file's name. Now, when you upload a PDF, the correct filename is stored, improving file management and organization within Odoo. This ensures users can easily identify and access their documents.
Original PR description
When uploading a file using the PDF viewer field, the filename was not stored in the corresponding filename field. This commit updates the PdfViewerField to support a filename field via the `filename` attribute. task-4825728 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262767 Forward-Port-Of: odoo/odoo#259795
This update fixes an issue where the end date on generated payslip PDFs was displayed incorrectly. The problem stemmed from a formatting error in the XML file, which has now been corrected to ensure consistent date display across all payslips. This ensures accurate and professional payslip documentation for employees.
Original PR description
ٍSteps: - Go to the payslip tabs under payroll app - Create a payslip and preview the generated PDF - The end date format is messed up Cause: The format was different because the end date was being overriden in the xml file and being displayed in the xml through t-out tag instead of span and t-field tags. Solution: Matching the format of the start date and end date of the payslip template. Task: 6168607 Forward-Port-Of: odoo/enterprise#115317
This update adjusts the NSSF (National Social Security Fund) payroll deductions to stop when an employee reaches 60 years of age. The deduction stop will align with the employee's birthday, starting in the following month. This ensures compliance with Kenyan regulations regarding pension contributions for older workers.
Original PR description
[IMP] l10n_ke_payroll: stop NSSF deductions after 60
When the user is creating a payslip and if the age of employee is >=60 the NSSF deductions must stop
(If the 60 years is finished in 10th of March -> it will stop in April (deduction stop starts from next month))
Test:
Unit test is written to check stopping NSSF deductions with dynamic birthday.
task - 6074658
Forward-Port-Of: odoo/enterprise#115236This update resolves a bug where the 'Add a line' button was unresponsive at the top of mobile grid views (like Timesheets). The fix adjusts how elements are sized on mobile devices, ensuring the button is always clickable regardless of the employee's position in the list.
Original PR description
**Steps to reproduce** On mobile: - Open a grid view (e.g. Timesheets > All timesheets) - Try to click on "Add a line" for the first employee - Issue: nothing happens. Notice that by scrolling down the list to employees at the bottom, it becomes possible to click on "Add a line". **Cause** `o_grid_cell_overlay` elements (with `h-100`) were taking more than the expected height in mobile, because the `o_grid_section_title` divs only have `position: sticky` on larger viewports. With the default `position: static`, the child element's height was exceeding its parent's height. opw-5853489 Forward-Port-Of: odoo/enterprise#113400
This update resolves an issue where errors from the Danish tax reporting system (l10n_dk_reports) could cause the entire system to fail. The fix ensures that error messages are handled correctly, preventing exceptions and improving the stability of the reporting process. This change was driven by a technical update to properly manage data types within the system.
Original PR description
before this commit, if the SKU server was returning an error message, the error handler would raise an exception because of the lazyTranslate. The reason is that `join()` expects an actual sting as argument, not a lazy string. This commit adds some tests for the error case and fixes the error due to the lazytranslate in the error codes. opw-6171466 Forward-Port-Of: odoo/enterprise#115887 Forward-Port-Of: odoo/enterprise#115515
This update resolves an issue where the HR system might fail if no active versions were available. The change provides a fallback mechanism, ensuring that core HR functions continue to operate smoothly. This improves system stability and prevents potential disruptions to employee management processes.
Original PR description
Forward-Port-Of: odoo/odoo#263324
The customer list view was displaying incorrect total calculations (showing dashes instead of numbers) when certain columns were enabled. This fix ensures that total amounts, including overdue balances, are accurately calculated and displayed, providing users with reliable financial reporting.
Original PR description
In the partner list view, enabling the "Total Due" and "Total Overdue" columns results in empty aggregates (—) at the bottom of the list. Steps to reproduce: - Navigate to Accounting -> Customers -> Customers - Add columns 'Total Due' and 'Total Overdue'. - Check the computed totals. Issue: The totals displays dashes (—) instead of the numbers. Analysis: The web client list renderer requires a currency field to be present in the view to correctly format and display aggregate sums for monetary fields, otherwise empty dashes are shown as fallback. opw-6169513 Forward-Port-Of: odoo/odoo#263585 Forward-Port-Of: odoo/odoo#261820
This update removes a restriction that previously required Lazada products to be 'storable'. When stock synchronization with Lazada is disabled (as is common), tracking stock levels is unnecessary. This change allows businesses to list a wider range of product types on Lazada without impacting synchronization.
Original PR description
Lazada items previously required products to be of type 'storable'. This restriction is unnecessary when stock synchronization is disabled, since no stock tracking is performed in that case. opw-6173986 Forward-Port-Of: odoo/enterprise#116543
This update resolves an issue where the composer field in the portal chatter wouldn't automatically focus after an emoji was added. The fix ensures the composer always receives focus, improving the user experience. This was caused by a missing default value for the composer's autofocus property.
Original PR description
Before this commit, after adding an emoji via the emoji picker in the portal chatter, the composer would not be focused. This is due to the `autofocus` prop of the composer being optional and not having a default value, leading to `NaN` when being incremented while `undefined`. This commit fixes the issue by giving it a default value of 0. task-6204911 Forward-Port-Of: odoo/odoo#263494
A bug in the product creation test for the SOL editable form was preventing the correct default value ('no') for the expense policy from being set. This fix ensures that new products created through this test process initialize the expense policy correctly, resolving a validation error. This improves the reliability of product creation tests.
Original PR description
When creating an on-the-fly product in the SOL editable form test, expense_policy was not initialized to its default value ('no') on the transient record created with `new()`.
This happens because `new()` only initializes defaults for fields needed by the current form view (required fields, modifiers, onchanges, etc.), and expense_policy is not part of them in this flow.
Also Since `product_id.expense_policy` is also not a dependency of `qty_delivered_method`, the compute keeps using the incorrect initial value, causing the readonly assertion on `qty_delivered` to fail.
Fix by explicitly passing the expense_policy's default value in the product creation values.
runbot error-239939
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update resolves an issue where the cursor wasn't correctly positioned after inserting a code block within a list. The fix eliminates a technical glitch that created an invisible text node, ensuring the editor accurately restores the cursor's location. This improves the overall user experience when working with code blocks.
Original PR description
#### Description of the issue this PR addresses: - In shortcut plugin, extractContent leaves an empty text node at block start - When converting to a code block, that invisible node is removed, so the editor cannot restore the cursor correctly #### Desired behavior after PR is merged: - Delete the selection directly instead of extracting text - This prevents creating the invisible empty node #### Steps to reproduce: - Type `1. ` to create a list - Immediately insert `/code` - Cursor does not move inside the code block task-6169180 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263256 Forward-Port-Of: odoo/odoo#261799
This update resolves an error that prevented access to public departments when managing employees across multiple companies. Previously, a user wouldn't be able to view departments managed by employees defined in a different company. The fix ensures correct access permissions are granted, allowing users to manage departments regardless of employee company affiliation.
Original PR description
## Short functional explanation of the error When accessing a public department from a multicompany setting, an access error is triggered. ## Reproduction Steps 1. Create another company. 2. Go to…
## Short functional explanation of the error When accessing a public department from a multicompany setting, an access error is triggered. ## Reproduction Steps 1. Create another company. 2. Go to Employees and create an employee. 3. Go to Departments and create a Department. Set the manager of the department to the employee you just created. Make sure that this department doesn't have a company assigned. 4. Select the company you just created, and unselect the previous one. ### Expected behavior The public department should appear in the list. ### Unexpected behavior An error occurs: ```Uh-oh! Looks like you have stumbled upon some top-secret records. Sorry, Mitchell Admin (id=2) doesn't have 'read' access to: - Employee (hr.employee) ``` ## Origin of the issue In the case where we want to access departments but managers are employees only defined in one specific company, which isn't the current company, the access is denied as we try to access such employees. However, we should be able to access their departments as they're publicly visible. Therefore, in the code, we need to check if the employee we want to access is a manager from a department that is accessible. __ opw-6113535
This update ensures that 'Back on' messages for employees on holiday are now consistently displayed in both the standard and compact versions of the chat sidebar. Previously, these messages were only visible in the larger sidebar view. This enhancement provides a more complete and user-friendly experience for all users.
Original PR description
Before this commit, the "Back on X" text below chats of people that are away was only displayed in non-compact sidebar. This comes from `xpath` that targets only the non-compact sidebar. This commit fixes the issue by adding the `xpath` for the compact sidebar. Task-6197362 Before / After <img width="247" height="254" alt="before" src="https://github.com/user-attachments/assets/da149668-7649-479a-baca-c3df9f6600b6" /> <img width="240" height="279" alt="after" src="https://github.com/user-attachments/assets/072405d1-b050-4314-933f-31f1c1c30ad4" /> Forward-Port-Of: odoo/odoo#263426 Forward-Port-Of: odoo/odoo#263071
This update resolves a technical issue causing broken sponsor logos on event pages. The fix prevents the QWeb image widget from generating invalid image URLs by limiting the image sizes used in the sponsor footer cards. This ensures all sponsor logos display correctly and maintains a professional appearance.
Original PR description
Problem: Sponsor logos were broken on the event sponsor footer cards after https://github.com/odoo/odoo/commit/36e680feca4884940e020119de6a13cd7f927516, even when `image_128` / `image_512` were set. The QWeb image widget generated a `srcset` including larger sizes (`image_1024`, `image_1920`) that do not exist on `event.sponsor`, allowing browsers to pick invalid URLs. Cause: The template renders `sponsor.image_128` with the generic image widget, which auto-generates a `srcset` from the image family. Without restricting it, larger nonexistent variants are included. Solution: Set `t-options` with `"preview_image": "image_128"` in the sponsor footer template to limit `srcset` to existing variant and ensure valid image URL is selected. Task-6079695
A recent update introduced a one-hour delay when scheduling shifts in the Gantt day view. This was caused by a change in how timezone information was handled. The fix ensures that shift times are now accurately reflected based on the resource's timezone, resolving the scheduling issue.
Original PR description
Steps to reproduce:
-
- Open Planning
- Switch to Gantt day view
- Select a time slot from 1 PM to 3 PM for a resource
Issue:
-
- When creating a planning shift from the Gantt day view, the created shift has a 1 hour time lag compared to the selected slot.
Cause:
-
- In saas-19.2, the timezone field was removed from the resource calendar.
- _work_intervals_batch was called without resources_per_tz, causing it to default to {UTC: resource} instead of the correct resource timezone.
Solution:
-
- Pass the resource timezone when calling _work_intervals_batch so attendance times are stamped with the correct resource timezone instead of defaulting to UTC.
task-5966733This update resolves an issue that occurred when users attempted to merge a single mailing list. The fix addresses a technical error related to empty recordsets, preventing a database syntax error and ensuring the merge functionality works correctly.
Original PR description
Currently, error occurs when user tries to merge a mailing list. Steps to replicate: - Install `mass_mailing`. - Open Email Marketing > Mailing Lists > Mailing Lists and switch to list view. - Select…
Currently, error occurs when user tries to merge a mailing list.
Steps to replicate:
- Install `mass_mailing`.
- Open Email Marketing > Mailing Lists > Mailing Lists and switch to list view.
- Select a single record and Click merge.
Error:
```
psycopg2.errors.SyntaxError: syntax error at or near ")"
LINE 8: AND src_sub.list_id IN ()
^
ValueError: SyntaxError('syntax error at or near ")"\nLINE 8: 'AND src_sub.list_id IN ()\n'
^\n') while evaluating 'action = records.action_mailing_lists_merge()'
```
Cause:
- Error occurs due to a recent [PR].
- When the user selects only a single record, `self - dest` [1] evaluates to an empty recordset. As a result, `action_merge()` receives an empty `src_lists`.
- Later, this is used [here] and converted into an empty tuple, producing an invalid SQL clause like `src_sub.list_id IN ()`, which leads to this error.
Solution:
- When `src_lists` is an empty recordset, we early return from `action_merge()`.
[PR]: https://github.com/odoo/odoo/pull/72156
[1]: https://github.com/odoo/odoo/blob/4193b3735d64518290613f5c8132f1fd07afa229/addons/mass_mailing/models/mailing_list.py#L218
[here]: https://github.com/odoo/odoo/blob/4193b3735d64518290613f5c8132f1fd07afa229/addons/mass_mailing/models/mailing_list.py#L266
sentry-7447326420
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where products added to a sales order catalog were appearing in the wrong order. The fix ensures products are added to the catalog in the intended sequence, improving the user experience when managing product selections. This resolves a discrepancy in how the system handles adding products to sections within the catalog.
Original PR description
# How to reproduce
- Create product n1 & n2
- Create a SO
- Add a section to that SO
- Go to the catalog
- Ensure the section is selected, then add product n1 followed by n2
# The problem
The orders of the product are reversed. n2 is before n1 in the SO
# Cause
Clicking on the Add button will trigger an RPC call to "/product/catalog/update_order_line_info"
that will endup adding a new sale order line :
https://github.com/odoo/odoo/blob/c7f05ae216de64d1f8e76e332bc6dd9cf11ce657/addons/sale/models/sale_order.py#L2222-L2227
To determine the sequence of this new order line, we call `_get_new_line_sequence`.
Since a section_id is given, the new order line is inserted right after, before any
product under the same section :
https://github.com/odoo/odoo/blob/c7f05ae216de64d1f8e76e332bc6dd9cf11ce657/addons/account/models/product_catalog_mixin.py#L59-L63
opw-6175704
Forward-Port-Of: odoo/odoo#262556This update resolves an error that occurred when installing the Saudi Arabia EDI module, specifically related to demo data setup. The issue stemmed from deleting demo invoices, which caused a problem when the system attempted to update related records. The fix ensures the system handles missing records gracefully during the demo data update process.
Original PR description
Currently, error occurs when user tries to install Saudi Arabia EDI module. Steps to replicate: - Install `l10n_sa` with demo and switch to SA company. - Open Invoices > `INV/2026/00001` > Reset to…
Currently, error occurs when user tries to install Saudi Arabia EDI module.
Steps to replicate:
- Install `l10n_sa` with demo and switch to SA company.
- Open Invoices > `INV/2026/00001` > Reset to draft > Delete.
- Open Invoices > `INV/2026/00002` > Reset to draft > Delete.
- Install `l10n_sa_edi`.
Error:
```
File '/home/odoo/src/odoo/saas-19.2/addons/l10n_sa_edi/demo/account_demo.py', line 16, in _l10n_sa_edi_onboard_sa_sale_demo
self.ref('demo_sa_invoice_1', raise_if_not_found=False)
TypeError: unsupported operand type(s) for +: 'NoneType' and 'NoneType'
```
Cause:
- As the user deleted `INV/2026/00001` (linked to `demo_sa_invoice_1`) and `INV/2026/00002` (linked to `demo_sa_invoice_2`), [here] when we try to create a recordlist to update we get this error.
Solution:
- Avoided direct concatenation of `self.ref(...)`, which may return None.
- Iterated over the expected IDs, fetched records safely, and skipped missing ones before processing.
[here]: https://github.com/odoo/odoo/blob/b8bcaa6af2531f49654d804231942b6af2261933/addons/l10n_sa_edi/demo/account_demo.py#L15-L20
sentry-7458234787
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where the 'Import records' option was missing from the Journals list view. The change was caused by a setting that unintentionally restricted importing. The fix removes this restriction, restoring the previously available functionality.
Original PR description
**Steps to reproduce:** * Go to Accounting App. * Open the Journals list view (Configuration > Accounting > Journals). * Click on the "Action" (cog) menu. **Observed behavior:** * The "Import…
**Steps to reproduce:**
* Go to Accounting App.
* Open the Journals list view (Configuration > Accounting > Journals).
* Click on the "Action" (cog) menu.
**Observed behavior:**
* The "Import records" option is completely missing.
**Cause:**
* In [commit](https://github.com/odoo/odoo/commit/082c70e6d411afd28efffbaf437d8b56d8351e38), `create="False"` was added to the `account.journal` list view to hide the "New" button, intentionally redirecting users to use the journal creation wizard instead.
* However, Odoo's standard `base_import` framework evaluates the XML architecture of the view (`config.viewArch.getAttribute("create")`). Because `create="False"` was set on the view, the framework automatically hid the `Import records` action menu item, assuming importing was entirely restricted.
**Fix:**
* Remove `create="False"` from the XML view architecture so the `base_import` framework evaluates it correctly and displays the "Import records" action.
* Introduce a custom `js_class` (`account_journal_list`) for the journal list view. By explicitly setting `this.activeActions.create = false` inside the controller's `setup()` lifecycle method, we can safely hide the inline "New" button on the UI layer without interfering with the backend XML architecture evaluation.
Ticket [link](https://www.odoo.com/odoo/project.task/6132990)
opw-6132990This update corrects a bug where a project warning calculation was incorrectly processing data, leading to potential display issues. The fix ensures all projects will display a 'no warning' status, and the unused field will be removed in a future update. This improves data accuracy and stability.
Original PR description
Prior to this commit, the `compute` method was getting all the projects that had missing employee sale order line mappings through an SQL query. The result of the query is supposed to be a tuple but was treated as an array of `Integer` ids causing trouble while browsing and then later writing the value for the field. Since the field `warning_employee_rate` is not used in the views we can assume that the warning will be `False` for all projects and remove this field later on Master. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263866
This update resolves an issue in our testing environment where a key piece of information related to product routes wasn't visible. The change ensures that test setups correctly access this data, preventing errors and allowing for more reliable testing of the manufacturing process. This improves the accuracy of our test results.
Original PR description
The setup in `TestMultistepManufacturingWarehouse` was failing with: ``` AssertionError: field 'route_ids' is not visible ``` This happens because the `route_ids` field on the product form view is only visible when `has_available_route_ids` is True, which depends on having at least one `product_selectable` route. This commit enables `product_selectable` on those routes in the test setup, so that `route_ids` becomes visible and the Form helper can access it safely. [RB-232576](https://runbot.odoo.com/odoo/error/232576) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237293