Wednesday, May 13, 2026
16 changes · 18.0
New functionality added to Odoo
This update adds a new test to ensure the structure of payment data sent to our payment processor (Odoofin) remains consistent. This helps prevent unexpected changes on Odoofin's side and ensures developers are aware of any necessary updates on both sides. It's a preventative measure to maintain reliable payment processing.
Original PR description
Add a test asserting the payment payload structure sent to Odoofin. The goal is to safeguard against unintended payload changes that are not handled on Odoofin's side by making such changes explicit during testing, and reminding developers that corresponding updates may also be required there. No task ID
Resolved issues and error corrections
This update resolves an issue where users were incorrectly receiving an error message when exporting payroll data to SDWorx for freelance employees. The change removes a redundant check for SDWorx codes specifically for this employee type, streamlining the export process. This ensures accurate data transfer for all employee types.
Original PR description
Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set…
Steps to reproduce: ------------------------------- 1. Install `l10n_be_hr_payroll_sd_worx` module 2. Switch the active company to a Belgian company 3. Go to Employees and create a new employee. Set the Employee Type to Freelancer from HR Settings page. 4. Navigate to Payroll > Reporting > Export Work Entries to SDWorx Observation: ------------------------------- A user error is raised stating: ``` There is no SDWorx code defined for the following employees ``` Issue: ------------------------------- In https://github.com/odoo/enterprise/pull/106065/changes/c19009c776349c3f5d8aebf99aff8efe987b54db The Check for Freelance Employee type was removed, which was earlier added in the fix https://github.com/odoo/enterprise/pull/102211/changes/96724c3cc55725e87e618443b96069921b8f3bda Solution: ------------------------------- Add a condition to the employee filter to exclude freelance employees from the SDWorx code validation. opw-5387342 Forward-Port-Of: odoo/enterprise#114411
This update resolves a technical issue that was causing database errors when calculating membership states. The fix uses a more robust method within Odoo's database system to handle empty data, preventing the error. This ensures the membership system functions correctly and reliably.
Original PR description
SQL `IN %s` clause failed due to an empty tuple, causing a syntax error. By switching to `read_group`, the ORM handles empty domains gracefully. This also improves maintainability by using standard API methods instead of direct cursor execution. opw-6196166 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264030
This update fixes a discrepancy in how contract types are defined within Odoo's HR modules. Specifically, the contract type ID was standardized across modules to ensure consistency and prevent potential errors. This change improves data accuracy and stability within the HR contract management system.
Original PR description
[IMP] hr_contract_salary: fix contract_type_id definition The definitions of the contract_type_id in hr_contract_salary_offer and l10n_be_hr_contract_salary/hr_contract_salary_offer should be same I converted the definition of contract_type_id in the base module to the Belgium one. Also, the contract_type_id was inserted to the view in Belgium one as well, I deleted that part to prevent double appearance. This task is only for v.17, after this version I will open a new PR to handle them. Do not forward the task after v.17 (only for v.17) task - 6101717 Forward-Port-Of: odoo/enterprise#113244
This update resolves an issue where a command used to check for updates on IoT boxes was causing unexpected upgrades. The change now skips the upgrade process if the command fails, ensuring updates only occur as intended and preventing disruptions to IoT Box systems.
Original PR description
If `git ls-remote origin <db_branch>` randomly fails, we assume `db_branch` is `master`. It was useful for devs in the past, but now lead to update to Trixie on IoT Boxes 25_07 and previous, which is unwanted in such circumstances. We now skip upgrade if `db_branch` is `master`. Forward-Port-Of: odoo/odoo#264126
This update removes a requirement for write access to company records when fetching transactions from Codabox. Previously, the system checked for write access, which was unnecessary after the initial connection was established. This change improves efficiency and simplifies the process for users.
Original PR description
Currently, we use the `_l10n_be_codabox_verify_prerequisites` method before trying to fetch transactions. This method checks if the user has write access rights on res.company model which should not be mandatory to fetch transactions from codabox when the connexion is already created. opw-6108811
This update resolves a rare access error that occurred when users accessed bank reconciliation widgets within child companies. The fix uses 'sudo' to ensure the correct currency ID is retrieved, allowing proper functionality for accounting operations in multi-company setups. This improves stability and usability for users managing accounts across different companies.
Original PR description
The bug is easy to reproduce, but niche. 1. Have a company set up with a child company 2. Have a non admin user with administration rights for accounting 3. Create a bank statement in a journal with no set currency_id and fully reconcile it 4. While only in the child company, try to access the bank reconciliation widget -> access error The error occurs because of how journal_currency_id is computed on the bank rec widget. The fallback value for the currency is derived from the journal_id.company_id.currency_id which is inaccessible from the child company. To circumvent this, we just add sudo() to the call.
This update corrects a test failure related to expected subject lines in the mass mailing testing suite. The fix involves adding a specific test identifier to the expected subject, resolving an issue caused by an outdated test configuration. This ensures the tests continue to run successfully and maintain the stability of the mass mailing functionality.
Original PR description
**Issue:** Test won't fail after [1] due to the added `[TEST]`. (Forgot to update the test on 18.0 and 18.2 in the original PR) **Fix:** Add it to the expected subject. [1] https://github.com/odoo/odoo/commit/4ef8b7ce36ddd8de1c9de324bd56359af438d7a0 original: https://github.com/odoo/odoo/commit/05c9d50c651e817cac9074bbea953da836ec129d opw-6168632
This update resolves an issue where users couldn't select colors for images with shapes when using the website editor's snippet tools. The fix ensures that the necessary data is included in the image templates, allowing users to customize the appearance of these images correctly. This improves the overall user experience and design flexibility.
Original PR description
Steps to reproduce: 1. Go to the website and enter edit mode. 2. Drop `s_cta_mockups` or `s_closer_look` snippet. 3. Click on any image that has a shape. Issue: The color picker option is missing for images with shapes in these snippets. Reason: These snippet templates do not include the `shapeColors` dataset on the image elements. task-5880905
This update optimizes PDF report generation by compressing the output files after merging, reducing file sizes and memory usage. The change addresses a previous memory leak and leverages newer versions of the pypdf library for better performance, particularly with large reports.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 Forward-Port-Of: odoo/odoo#261879
This update optimizes PDF generation by compressing files after merging, resulting in significantly smaller output sizes. It also addresses a memory leak issue in the underlying PDF library, leading to improved performance and reduced resource usage. The changes result in faster PDF creation, particularly with large documents.
Original PR description
When merging pages with pypdf, the resulting content is uncompressed. A compression pass should be done right after to reduce the resulting file size. Additionally, this helps alleviate a memory leak in PyPDF2 where resources in the merged page are not properly released. Newer versions of pypdf (>=3.15.4) do not have this leak but still see benefits in the output file size. In practice the CPU overhead is negligible, and we actually see a speed increase in cases with high memory usage. Benchmark Printing 400 page annual report | |Print Time|Peak Memory|Output File| |------|----------|-----------|-----------| |Before|142s |3.6GB |103MB | |After |127s |0.4GB |5MB | opw-6148786 Forward-Port-Of: odoo/enterprise#115550
This update fixes a bug in the journal report that caused it to repeatedly load the same data when using the 'Load More' feature. The fix ensures the report correctly handles pagination, preventing performance issues and providing a smoother user experience. This improves the efficiency of report generation.
Original PR description
Steps to reproduce: - Install `Accounting` module - Accounting > Configuration > Accounting Reports > Journal Report > Options > Set `Load More Limit` to 1 - Accounting > Review > Journal Audit > Expand Sales > `Load more...` The "Load More" button in the journal report was repeatedly loading the same lines because the custom engine query was not applying the offset and limit parameters passed to the method. Solution: Applied pagination to the query by using the `_get_engine_query_tail` helper method from `account.report`, which correctly appends `OFFSET` and `LIMIT` clauses to the SQL query. opw-6193697, 6125082
This update resolves an issue where users could create a circular reference when attaching files, leading to errors. The fix prevents attachments from being linked to themselves in both the user interface and during data writing, ensuring data integrity and preventing system instability.
Original PR description
Currently, users have the option to attach an ir.attachment to itself. This causes a recursion depth error when accessing attachments. This commit prevents this in the UI and the write. Firstly, the ir.attachment does not show itself in the dropdown when selecting the resource ID. Second, the write raises a UserError if attempting to write an ir.attachment with the same ID as the Resource ID. Steps to reproduce: 1. Create an attachment and save 2. Set the Resource Model `(res.model)` to "ir.attachment" 3. Select the same attachment in Resource ID `(res_id)` 4. Attempt to view attachments: `RecursionError: maximum recursion depth exceeded` opw-6206075 closes #263591
This update resolves an issue where cloud storage uploads were limited to a single attachment per cron job. By adjusting a setting, multiple attachments can now be uploaded simultaneously, improving the efficiency of automated file transfers. This change streamlines the process of backing up and syncing data to the cloud.
Original PR description
make the `limit_time_real > 0` when --limit-time-real-cron=0 --limit-time-real=0 to allow multiple attachments to be uploaded in a single cron job. 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 the Microsoft SwiftKey keyboard caused incorrect table selections, leading to unexpected focus movement. The fix caches the selection to ensure the editor always reflects the user's intended selection, improving the table editing experience.
Original PR description
Problem: When using the Microsoft SwiftKey keyboard, placing the caret at the beginning of a table cell and triggering a `beforeinput` event can result in `getSelection()` returning an incorrect selection. Notably, the selection immediately before the event is correct, but it changes unexpectedly without firing a `selection_change` event. Solution: Cache the selection whenever a `selection_change` event fires, ensuring we keep the last correct selection set by the user or editor. Steps to reproduce: - Edit a table with an empty cell. - Place the caret inside the empty cell. - Press Backspace. - Observe that the focus moves to the previous cell unexpectedly. task-6150731 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where Knowledge articles appeared narrow when printed on large screens. The fix specifically targets the Knowledge editor's form view, preventing a default CSS rule from causing a constricted layout. Now, articles print correctly in a readable format.
Original PR description
Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size. See: ```scss .o_form_view.o_xxl_form_view { .o_form_view_container {…
Currently, a CSS rule forces the form container width to 1px to ensure that the nested list view can correctly compute its size.
See:
```scss
.o_form_view.o_xxl_form_view {
.o_form_view_container {
width: 1px; /* List view needs a width value to recompute the size correctly */
}
}
```
However, since the Knowledge editor is implemented as a form view, this rule also affects Knowledge. When zooming out, the `o_xxl_form_view` class is added to the form view container, causing the rule to apply. If an article is printed while this class is present, it is constrained to an extremely narrow column, making it unreadable.
Steps to reproduce:
1. Open an article in Knowledge
2. Zoom out using `Ctrl` + `-`
3. Open the kebab menu and select "Export"
=> The article is rendered in a very narrow column.
To address this issue, we override this rule specifically for Knowledge. With this change, articles are now rendered correctly when printed or exported as PDF.
Task-5999878