Daily updates from Odoo
Wednesday, May 13, 2026
26 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 optimizes a key query in our Point of Sale system, resulting in significantly faster report generation. By adding the journal to the search criteria, the system now leverages an existing database index, dramatically reducing the time it takes to retrieve account move information. This improves the overall performance and responsiveness of the POS system.
Original PR description
Currently the query to get the closing difference account move is done by searching for the reference of the move, which is not very efficient. This commit optimizes this query by adding the journal…
Currently the query to get the closing difference account move is done by searching for the reference of the move, which is not very efficient. This commit optimizes this query by adding the journal to the search criteria, which allows us to benefit from the index on the journal_id field. Here is an example of the before after on a database with 39 million account_move records. Meanwhile only 10-20K account_move are linked to specific journals used in POS payment methods. All measures are performed with a warmed up cache [Explain Before](https://explain.dalibo.com/plan/h8edf56c09d7dfd7) ### Benchmark: <table> <thead> <tr> <th># of am</th> <th>Before</th> <th>After</th> </tr> </thead> <tbody> <tr> <td>38982635</td> <td>~17s</td> <td>~22ms</td> </tr> </tbody> </table> [Explain After](https://explain.dalibo.com/plan/be2397f176a6b29d) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262148
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 strengthens the signup process by ensuring all email addresses entered during registration are validated. Previously, users could enter any string, creating a potential security risk. The change enforces email format validation and adds autocomplete attributes to the signup form for a better user experience.
Original PR description
**Problem**
Before this commit, the email address typed in the signup form was not validated. Consequently, the user could use whatever string as email address.
**How to reproduce**
1. Activate "free sign up" ("Settings"->"Website"->"Customer Account")
2. While being signed off, navigate to "/web/signup"
3. No validation is enforced on the email field
**Fix**
The email field is correclty marked as "required", but its type was set as "text" instead of "email". This commit fixes the problem by changing the type to "email".
task-6094631
Forward-Port-Of: odoo/odoo#258967This 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 ensures that when stock valuation moves are created from purchase orders, the correct analytic account from the PO is automatically applied to the corresponding account move lines. Previously, these moves didn't inherit the analytic distribution from the PO, leading to incorrect accounting. This change aligns the behavior with how analytic distributions are handled for invoices.
Original PR description
**Problem:** account move created by stock valuation layer does not take analytic account from PO **Steps to reproduce:** - make sure you have at least one analytic account - create a storable…
**Problem:** account move created by stock valuation layer does not take analytic account from PO **Steps to reproduce:** - make sure you have at least one analytic account - create a storable product with categ standard automated - set a positive cost - create a PO for 1 quantity - on the PO line of the product, in the analytic distribution column (might need to be unfiltered) set an analytic account - confirm PO and validate receipt - click on the valuation smart button and on the book widget of the stock valuation layer **Current behavior:** the account move lines have no analytic distribution **Expected behavior:** The account move lines should inherit the analytic account from the purchase order line like it's the case for the bill. For the analytic distribution of the Bill, the selection is : 1) take analytic distribution from PO if one 2) if not, take from distribution model if there is one 3) empty Currently for the account move lines of the svl the selection is: 1) take from distribution model if there is one 2) empty But we should use same selection as for the bill **Cause of the issue:** When setting the analytic distribution we first try to use the one from PO/SO by calling _related_analytic_distribution() https://github.com/odoo/odoo/blob/4cc1e6884be673523f768d5ec471a1ffa19c5fb4/addons/account/models/account_move_line.py#L1157 But since the account move lines have no purchase_line_id no analytic distribution will be returned https://github.com/odoo/odoo/blob/4cc1e6884be673523f768d5ec471a1ffa19c5fb4/addons/purchase/models/account_invoice.py#L540-L545 opw-6022695
This update enables customers to cancel Stripe payments directly through the payment terminal, both on the standard POS and self-order kiosks. Previously, cancellation was only possible through the POS interface, creating a frustrating experience for users. This change improves customer satisfaction and streamlines the payment process.
Original PR description
Before this commit, when making a payment on a Stripe terminal, the only way to cancel the payment was from the POS interface. In the self order kiosk, it was impossible to cancel the payment. After this commit, a cancel button will appear on the payment terminal for both POS and kiosk Stripe payments. task-6166789 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
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 French Intrastat export was incorrectly omitting quantity data for products with supplementary units. The fix ensures that accurate quantity information is included in the DEBWEB2 XML file, improving the reliability of Intrastat reporting for French businesses. This prevents data discrepancies and ensures compliance.
Original PR description
Steps to reproduce 1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set…
Steps to reproduce
1. In a French company with Intrastat enabled, set up a product whose commodity code has a CN supplementary unit (e.g. 8802 30 00, "p/st") and set `intrastat_supplementary_unit_amount` on it.
2. Post EU customer invoices for that product.
3. Export the DEBWEB2 XML from the Intrastat report.
Issue
The FR export collapses engine rows a second time in `_group_items`, because the DEBWEB2 format groups more aggressively than the SQL. The aggregator only declares `value` and `weight`: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/models/account_intrastat_report.py#L308-L313 Items are then rebuilt as `dict(zip(grouping_key, key_tuple)) | grouped_item_values`. `SU_code` survives (it is in the grouping key), but the numeric `supplementary_units` is in neither side and is silently dropped as soon as two engine rows merge. The template then skips the element because of its `t-if="item.get('supplementary_units')"` guard: https://github.com/odoo/enterprise/blob/6ae5d3df6e9305416e4d6f74259cd01753025f42/l10n_fr_intrastat/data/intrastat_export.xml#L61
opw-6139657This update resolves an issue where Point of Sale orders would fail if a product used an archived Unit of Measure. Now, archived UOMs are automatically loaded into the POS, ensuring orders can be processed without errors and improving the reliability of the POS system. This change prevents order processing failures and enhances the user experience.
Original PR description
If a product uses an archived UOM and an order is then created in the POS with this product, an error would occur because it could result in trying to use a UOM that wasn't loaded in the POS since it was archived. To fix this issue, we now load archived UOMs in the POS. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6197465
This update resolves a bug that caused reconciliation errors when dealing with kit components in Odoo. The issue stemmed from how valuation layers were being handled, leading to duplicate reconciliation attempts. The fix ensures accurate reconciliation of inventory movements for kits and their components, improving accounting accuracy.
Original PR description
Steps to reproduce ----- - Modules: Sale, Purchase, Mrp, Accounting - Enable automatic accounting & anglo-saxon valuation - Create an AVCO Product category (AVCO automatic valuation) - Create a Kit…
Steps to reproduce
-----
- Modules: Sale, Purchase, Mrp, Accounting
- Enable automatic accounting & anglo-saxon valuation
- Create an AVCO Product category (AVCO automatic valuation)
- Create a Kit product storable & AVCO
- Kit bom
- Comp as a component (storable & AVCO)
- Settings > Decimal Accuracy > Product Price > set to 4 digits
- Purchase 3 units of Comp at 3.3333 piece & validate reception
- Make 2 sales for 1 unit of Comp each & validate both deliveries
- Create a SO for 1 Kit and 1 Comp & confirm
- Create & confirm invoice
- Go to the delivery, force quantity on the component and try to validate delivery
> Error message: "You are trying to reconcile some entries that are already reconciled."
/!\ Fun(?) fact: this error doesn't occur if the order of the moves is inverted.
Cause
-----
When the purchase delivery is validated, a stock valuation layer is created for 3 units with a value of 10. As they are sold individually, these 3 units generate a valuation layer for 3.33 per unit summing to 9.99.
When we validate the last delivery, the 0.01 difference is detected and an adjustment is made on the valuation layer in `_prepare_out_svl_vals`.
However this adjustment is made for the product when the invoice line concerns the kit. As a result, the first reconciliation fails and the line is added to the list to be reconciled later.
Then, when handling the line for COMP2, it will successfully reconcile the lines while it is still in the pool to be reconciled, resulting in an error when attempting to reconcile it later.
This is caused by `_stock_account_anglo_saxon_reconcile_valuation` where the `product_stock_moves` only contains the kit move when called with the kit product as argument, but it contains both moves when called with the component itself as argument. This leads to the same AML being reconciled twice.
https://github.com/odoo/odoo/blob/f0b9f4c234cd0101f5cb259e58620e1cf65bb2b7/addons/stock_account/models/account_move.py#L222-L225
-----
Ticket:
opw-5722072
Forward-Port-Of: odoo/odoo#258013This update resolves an issue causing the FatturaPA import in the l10n_it_edi module to fail when the related account module isn't installed. The fix duplicates key helper functions from another Odoo module to ensure compatibility and stability of the import process. This prevents crashes and ensures correct FatturaPA invoice processing.
Original PR description
The FatturaPA import in `l10n_it_edi/models/account_move.py` calls `self.env['account.edi.common']` for the partner and the bank account. That model belongs to `account_edi_ubl_cii`, which `l10n_it_edi` does not depend on. Without that module installed, the import dies with a `KeyError`. It is not correct to add that dependency. PR #254505 (`63926d9d`) introduced the two calls and removed the search-only lookups that lived there before. ### Fix Copied `account.edi.common._import_partner` to `_l10n_it_edi_import_partner` Copied `account.edi.common._import_partner_bank` to `_l10n_it_edi_import_partner_bank` Fixes: https://github.com/odoo/odoo/issues/264306
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
A bug in the Point of Sale system was causing automatic database maintenance to delete critical sequences, leading to temporary system unavailability. This fix ensures that the system correctly identifies and protects these sequences, preventing future disruptions to the POS functionality. The change improves system stability and reliability for our Point of Sale users.
Original PR description
The `_gc_session_sequences` method searches for sequences using Odoo's `=like` operator, which maps to SQL LIKE where `_` is a single-character wildcard. The prefix `pos.order_` (added by `pos_self_order`) therefore matched the `pos.order.line` sequence, which has no integer suffix and was never added to `keep_codes`, causing the autovacuum to delete it silently. This made POS unusable until the sequence was recreated manually. Fix by filtering the search results with `str.startswith` to retain only sequences whose code literally begins with the prefix, discarding any false positives introduced by the SQL wildcard. opw-6215331 --- 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-5999878This update resolves a technical issue impacting invoice accuracy for Mexican VAT (SAT) compliance. Specifically, it corrects rounding errors that occurred when invoices with many items had a small negative line, leading to discounts being hidden due to currency precision. This ensures invoices pass SAT validation and avoid potential compliance problems.
Original PR description
…any lines Fix SAT validation errors CFDI40111 and CFDI40108 that occur when invoices with many lines contain a small negative line, causing per-line discounts to be hidden due to currency precision. opw-6187014