Daily updates from Odoo
Wednesday, May 6, 2026
56 changes · saas-19.2
Resolved issues and error corrections
This update resolves an issue where the payroll system incorrectly flagged users as unauthorized document owners in multi-company environments. The fix replaces a problematic field lookup with a stored employee flag, ensuring accurate document ownership validation during background processes like payroll generation. This prevents errors and ensures proper system functionality across all companies.
Original PR description
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for…
Steps to reproduce- 1) In a multi-company environment, create an employee in a secondary company. 2) Link a Portal User to this employee via the user_id field. 3) Create and validate a payslip for this employee. 4) Run the 'Payroll: Generate pdfs' cron. Error - ValidationError: The following user(s) cannot own root documents/folders: portal_employee: Payslip - portal_employee Cause - The validation logic uses the employee_id field on res.users to check if a user is an employee. Since employee_id is a non-stored computed field, its value depends on the current company context (self.env.company). When the payroll cron runs under the OdooBot user in the default company context (ID = 1), it cannot resolve the employee_id for users belonging to other companies. The field evaluates to False, causing the system to incorrectly flag the user as an unauthorized document owner. Fix - Replace the validation check with the employee boolean field. Unlike the computed Many2one, employee is a stored field that is not restricted by the active company context. This ensures that a user's employee status is correctly identified during background tasks across all companies. opw-6143042 Co-authored by Tina Lin (liti) Forward-Port-Of: odoo/enterprise#115570
This update optimizes the HTML editor's performance by minimizing unnecessary style recalculations during updates. Previously, the system repeatedly checked element styles, leading to slower performance. This change extracts style measurements outside the update loop, resulting in a faster and more responsive user experience.
Original PR description
Description of the issue this PR addresses: Before this PR, updateHooks retrieved the computed style for each visible element and accessed marginTop and marginBottom inside the loop. Accessing properties of CSSStyleDeclaration may trigger style resolution, causing repeated 'Recalculate Style' work during hook updates. This PR extracts marginTop and marginBottom after getComputedStyle outside the loop, which reduces style reads during hook updates and avoids unnecessary style recalculations. task-6063534 closes odoo/odoo#252385 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259341
This update resolves a critical error in the l10n_ar_edi module related to a missing dependency on the currency_rate_live module. The fix ensures the module functions correctly after an upgrade, preventing a system error. This ensures proper functionality for Arabic-based financial reporting.
Original PR description
Backport of https://github.com/odoo/enterprise/commit/ddec80d136063a24e4ddd4062d4d3591c861455d The module [adds](https://github.com/odoo/enterprise/blob/saas-19.2/l10n_ar_edi/models/res_company.py#L66-L69) selection values to field `res_company.currency_provider`, a field [defined](https://github.com/odoo/enterprise/blob/a0038c1aeaf9c0304afdfc220bcb7c0a309fac34/currency_rate_live/models/res_config_settings.py#L194-L200) in module `currency_rate_live`, but althouth it is auto-install, it's not a direct dependency, which can trigger errors. To reproduce: - Install `l10n_ar_edi` in 19 - Uninstall `currency_rate_live` - Upgrade to a saas~19.2 It will break with ``` AssertionError: Field res.company.currency_provider without selection ``` I had made the fix in master to avoid changing dependencies in stable, but the dependency is implicitly already there.
This update fixes an issue where the VAT label on invoices displayed in PDF format was incorrectly set to the user's preferred language instead of the company's language. Now, invoices will always display the VAT label in the correct language based on the company's settings, ensuring accurate and consistent invoicing for international clients. This resolves a discrepancy in language display for VAT labels.
Original PR description
When having for example a polish company but setting the language as an user to another one for example chinese, vat label on the top of the invoice pdf would be written in your user preference language so in this case chinese where it should be written in companies language so here in polish opw-6067250
A test related to rental stock management was failing due to demo data. The fix prevents the creation of duplicate 'out of stock' ribbons, which were being triggered by the test's attempt to create a second ribbon with the same configuration. This ensures the test runs successfully and accurately reflects the system's behavior.
Original PR description
Currently, running test `test_out_of_stock_ribbon_is_not_applicable_for_rentals` with demo data enabled leads to a validation error: `Only one ribbon with the "assign when out of stock" option is allowed.` This happens because, with demo data loaded, an "out of stock" ribbon is already created via XML data. The test then attempts to create another ribbon with the same configuration, triggering the constraint and causing the failure. Related PR: https://github.com/odoo/enterprise/pull/112660 runbot-[242457](https://runbot.odoo.com/odoo/error/242457) --- Forward-Port-Of: odoo/enterprise#116162
This update corrects a problem in how payslips are calculated for the Hong Kong payroll module. The calculation relied on a default year, causing issues when tests were run in different environments. This ensures accurate payslip generation for all scenarios, particularly for January 2026 payslips.
Original PR description
ir56b._compute_period depends on year_of_employer_return, which is derived from submission_date (defaults to today). If tests are run in a different year (mocked time or different environment), the period won't cover the January 2026 payslip. Forward-Port-Of: odoo/enterprise#116172
This update resolves an issue where users would lose focus when searching in the company switcher dropdown. The fix ensures the search input remains focused, providing a smoother and more reliable experience for selecting companies. It prevents interruptions during typing and improves usability.
Original PR description
If a user leaves their mouse resting over a company in the dropdown and starts typing in the search bar, the search bar loses focus, interrupting their typing and removes focus from the search input. Update the `onSearch` method to: - Remove focus from the highlighted dropdown item. - Put focus immediately back into the search input. - Briefly disable mouse events on the menu (for 100ms). This prevents the system from registering a fake mouse hover while the list updates. Forward-Port-Of: odoo/odoo#259369
This update fixes an issue where a horizontal scrollbar obscured the bottom border of the code view when content overflowed. By repositioning the scrollbar, the code view now maintains its intended visual appearance, ensuring a consistent and professional user experience. This change improves the overall readability and usability of the code editor.
Original PR description
Problem: When the code view contains content that overflows horizontally, the horizontal scrollbar hides the bottom border of the code view. Solution: Move the scrollbar inside the code view so the bottom border remains visible. Before: <img width="716" height="76" alt="image" src="https://github.com/user-attachments/assets/05b16d8e-4014-488f-84d6-f4e4c0dcae23" /> After: <img width="707" height="108" alt="image" src="https://github.com/user-attachments/assets/7151e3e0-254c-4e7c-bcda-bea2d7ab2cea" /> Steps to reproduce: - Add content in the code view that overflows horizontally. - Observe that the scrollbar hides the bottom border. task-6124267 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261554
A technical error preventing cash payments on POS terminals using Razorpay was resolved. The fix ensures the system correctly handles payment selections, preventing a 'null value' error that interrupted the transaction process. This improves the reliability of cash payments within the Odoo POS system.
Original PR description
Steps: - Open a POS configuration with the Razorpay payment method set to all payment modes. - Process an order and initiate a Razorpay transaction. - Select a cash payment option on the terminal. Issue: - A traceback occurs with the error: `Cannot read properties of null (reading 'replace')`. Cause: - The code attempts to call the replace method on a null value. Fix: - Ensure the replace method is called only when the value is a valid string. Task-6190355 Forward-Port-Of: odoo/odoo#261922
This update optimizes the way the spreadsheet component interacts with field selections, reducing unnecessary processing. Previously, a repeated process caused performance slowdowns. This change improves the responsiveness and efficiency of spreadsheet views, leading to a smoother user experience.
Original PR description
Currently, the component `ModelFieldSelector` will call the field service on `willUpdateProps` regardless of its current state. Since the introduction of the persistent cache, there is a slight overhead when calling the fieldService (notably caused by the call to deepCopy) and this call can now become costy when called repeatedly, which occurs in the spreadsheet component for instance. Task-6185388 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 Forward-Port-Of: odoo/odoo#262497
A minor correction was made to the French financial reports (pnl) to ensure accurate reporting. Specifically, a typo was fixed where 'exceptionnel' was incorrectly using masculine language when it should be feminine, aligning with French accounting standards. This ensures consistent and compliant reporting for our French clients.
Original PR description
There was a small typo in section 8 of the pnl report. "exceptionnel" must go feminine when referring to charges. Forward-Port-Of: odoo/enterprise#116198
This update resolves a technical problem that prevented the `l10n_tr_nilvera_edispatch` module from installing correctly when certain automatic installations were skipped. By updating the module's dependencies to include `stock_account`, the system now ensures this critical module is properly set up, avoiding installation errors.
Original PR description
Issue: currently, the module `l10n_tr_nilvera_edispatch` depends on `l10n_tr_nilvera_einvoice` and `stock`. and in `l10n_tr_nilvera_einvoice` , it eventually gets `account` in its dependencies [from dependency chain]. So `stock` and `account` both are installed, and ideally `stock_account` is also installed since it is set to `auto_install: True`. but if we try to install edispatch module with `--skip-auto-install` the module installation fails, because we skip auto install modules and `stock_account` is not installed, due to this, `country_code` field defined in `stock_account` module and used in `l10n_tr_nilvera_edispatch` module is not found which causes error. Solution: This PR fixes this issue by updating dependency from `stock` to `stock_account` to make sure it is installed in all conditions. Related runbot error: https://runbot.odoo.com/odoo/runbot.build.error/238909 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where error messages from the Aspone API were not being displayed correctly. The change ensures that error messages are now presented to the user, improving the reliability and usability of the French reporting module. This prevents potential data discrepancies and provides clearer feedback to users.
Original PR description
Since the v2 rest api of aspone was implemented, error messages were no more well handled and a traceback was raised while getting one. This commit displays the write errr to the user task-5955980
A bug in the testing process was causing tests to fail when demo data was loaded. This was due to a duplicate IoT Box record created both in the tests and within the demo data. This fix resolves the conflict, ensuring tests run correctly and reliably.
Original PR description
We define an IoT Box record in tests with name "Shop". Another IoT Box with this name is defined in the demo data of the module. As a result, when tests are started with demo data loaded, we tend to click on the first IoT Box record with whis name, which correspond to the one from demo data. Some tests are then failing as they can't find device record defined in the test setup. related: odoo/enterprise#96760 Forward-Port-Of: odoo/enterprise#116234
This update fixes an issue where stock synchronization with Amazon was failing due to incorrect fulfillment channel data. The team switched to a new API field that accurately reflects available quantities across fulfillment channels, defaulting to FBM when necessary to ensure continued synchronization. A related update also improves how user-specific configurations are handled.
Original PR description
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not…
During the upgrade from XML-based feeds to the new JSON Listings API for stock management, we chose to use Amazon's API to fetch a listing's fulfillment channel information. However, Amazon does not provide a clear answer for a given listing. After some research, we assumed an offer was FBM when the listing contained a `merchant_shipping_group`, because this setting is specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. This assumption was flawed: Amazon can keep the shipping group even after a listing switches to FBA, which can block stock synchronization. This commit uses the `fulfillmentAvailability` field from the Listings API instead. This field stores the available quantity for each fulfillment channel in which the listing is sold. When multiple fulfillment channels are present, the offer defaults to FBM so stock synchronization can continue. The `sale_amazon_channel_management` module can then be installed to manually select and disambiguate the channel. This commit also upgrades the patching method used to update the FBM stock to ensure user specific configuration aren't overriden during the synchronization. opw-6064896 opw-5152359 Forward-Port-Of: odoo/enterprise#115899 Forward-Port-Of: odoo/enterprise#114473
This update clarifies French accounting reports by splitting a key account (649) into two new accounts (6491 and 6492). This change accurately separates social security charges from salaries, aligning with French accounting standards. The original account remains for legacy systems but is marked as deprecated.
Original PR description
Splitting account 649 into two new accounts (6491 and 6492) is necessary to handle the Profit and Loss report properly. This ensures we can accurately separate social security charges from salaries in the report. Reference: ANC PCG 2026, page 445, note (h) https://www.anc.gouv.fr/files/anc/files/1_Normes_fran%C3%A7aises/recueil/RECEUIL-PCG-2026-AVEC-COUVERTURE.pdf task-6053784 Forward-Port-Of: odoo/enterprise#114412 Forward-Port-Of: odoo/enterprise#111420
This update corrects a technical error in how Odoo's Discuss feature sorts partners based on email addresses. The fix ensures that partners with matching email prefixes are correctly prioritized, leading to more accurate search results and improved user experience. This resolves a previously undetected issue.
Original PR description
In Discuss, the function used to sort partners prioritizes those whose email addresses start with the search terms. However, due to an error in the programming of the corresponding condition, this check could never be true. This commit adjusts the condition so that it behaves as expected. Forward-Port-Of: odoo/odoo#262583
This update resolves a visual bug where text highlights in the website editor were appearing in front of the text on Firefox. The fix adjusts how SVG highlights are added to the HTML to ensure they are rendered correctly behind the text, improving the user experience.
Original PR description
# How to reproduce - Go to the website editor - Select some text that wraps - Add text highlight to that text # The problem On firefox, for every line of text that wraps, the highlight is displayed in front of the text instead of behind. # Why The highlights are made of SVG's that are added to the html element of the selected text. To be sure that theses SVG's are displayed behind the text, they have position: absolute and z-index: -1. Sadly, z-index and absolute positionning in an inline context (like in a span) is a browser specific behavior and in the case of firefox, seems to sometimes be ignored. Since the SVG's are appended in the html element after the text, they are rendered after. This fix aims to insert the SVG's in the html element before the text to make sure the rendering order is correct opw-5976647 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254196
This update fixes an issue where users could inadvertently select customers from different companies within the Helpdesk module. The fix involved adding a restriction to the customer selection process, ensuring users only see customers within their assigned company. This improves data accuracy and prevents potential errors in ticket management.
Original PR description
Steps to reproduce: - - Create two companies (Company A and Company B) - Create one partner in each company - Enable both companies for the user - Open Helpdesk and go to the tickets Kanban view for a Company A team. - In the quick create form, the customer dropdown shows customers from Company B Issue: - - Customers from other companies are visible in the customer field, Cause: - - The partner_id field in the quick create view had no domain, so it displayed partners from all allowed companies. Solution: - - Added a domain on partner_id in the Python field. task-4971466 Forward-Port-Of: odoo/enterprise#116157 Forward-Port-Of: odoo/enterprise#111909
This update fixes an issue where the emission factor date range wasn't accurately shown. The missing 'always_range' option was corrected, ensuring that users now see the correct validity periods for emission factors. This improves data accuracy and reliability within the ESG reporting features.
Original PR description
Before this commit, the validity period was not correctly displayed because the always_range option was missing no related task Forward-Port-Of: odoo/enterprise#115832 Forward-Port-Of: odoo/enterprise#114784
This update resolves a bug that prevented correct balance calculations during multi-currency bank reconciliation edits. Specifically, changing the currency of a bank statement move line and then making further edits would reset the balance to zero. This fix ensures accurate balance tracking for financial reporting.
Original PR description
Fixed an issue where when editing a move line for the bank reconciliation and setting the currency to a currency other than the company's currency if we edit the move line again we will find that the balance is equal to 0. task-6037835 Forward-Port-Of: odoo/enterprise#114898
This update resolves an issue preventing the successful installation of the `sale_stock` and `purchase_stock` modules when existing sale or purchase orders included non-stock items like downpayments. The fix filters out these problematic lines during the installation process, preventing a critical error and ensuring smooth module installation.
Original PR description
## Summary When installing `sale_stock` or `purchase_stock` module on a database that already has sale/purchase orders with non-stock lines (downpayments, section notes), the installation fails with:…
## Summary
When installing `sale_stock` or `purchase_stock` module on a database that already has sale/purchase orders with non-stock lines (downpayments, section notes), the installation fails with:
ValueError: Expected singleton: uom.uom()
## Root Cause
The `post_init_hook` (`_create_pickings_for_open_sale_orders` / `_create_pickings_for_open_purchase_orders`) filters order lines to create pickings:
```python
empty_lines = open_sale_orders.order_line.filtered(
lambda l: l.product_uom_id.is_zero(l.qty_delivered)
)
```
This accesses product_uom_id without checking if it exists. Lines with:
- display_type set (sections, notes)
- is_downpayment = True (downpayments)
...don't have a product_id or product_uom_id, causing the error.
Fix
Add filters to skip non-stock lines before accessing product_uom_id:
```
empty_lines = open_sale_orders.order_line.filtered(
lambda l: not l.display_type and not l.is_downpayment and l.product_uom_id.is_zero(l.qty_delivered)
)
```
Steps to Reproduce
1. Create a fresh database (without sale_stock/purchase_stock)
2. Create a sale order with a downpayment line or section/note
3. Install sale_stock module
4. Error: ValueError: Expected singleton: uom.uom()
Reproduction Reference
- purchase_stock issue: https://drive.google.com/file/d/1aKw-ago-pMds_-x_y9f8nJZyZsLqGJ67/view?usp=sharing
- sale_stock issue: https://drive.google.com/file/d/1I9fY8UZZZ3ULcairl3YGZTi_KttsYLNR/view?usp=sharing
opw-6179073
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262439This update resolves a rounding error issue that occurred when importing purchase orders processed through OCR. The fix restores the original rounding precision, aligning with the intended functionality for EDI imports rather than the OCR process. This ensures accurate financial data import.
Original PR description
Since commit odoo/odoo@86463ce, there could be rounding issues when importing a purchase order matched through the OCR. A first attempt at fixing this was done in commit odoo/odoo@5dbb814, but it was eventually reverted as deemed too risky for a stable branch. More information about how the rounding error occurred is available in that commit description. This second fix should be much safer, we simply don't disable the rounding precision when the OCR is used, as this was intended for EDI in mind in the first place, not the OCR. opw-[6113387](https://www.odoo.com/odoo/my-support-tasks/6113387) Forward-Port-Of: odoo/enterprise#116141 Forward-Port-Of: odoo/enterprise#116021
This update resolves an issue where enabling 'Secure Posted Entries with Hash' on LATAM purchase journals caused posting errors due to vendor-assigned document number discrepancies. The fix hides this option for LATAM purchase journals, ensuring data integrity and preventing misleading security indicators. This change only affects LATAM localization modules.
Original PR description
Steps to reproduce 1. Install l10n_ar (or any LATAM localization). 2. Go to Accounting > Configuration > Journals and open a Purchase journal that has "Use Documents?" enabled. 3. Enable "Secure…
Steps to reproduce 1. Install l10n_ar (or any LATAM localization). 2. Go to Accounting > Configuration > Journals and open a Purchase journal that has "Use Documents?" enabled. 3. Enable "Secure Posted Entries with Hash". 4. Create and post a vendor bill with a high document number (e.g. 00001-00009999). 5. Create another vendor bill with a lower document number (e.g. 00001-00000100) and try to post it. Issue Posting the second vendor bill fails with: "This move could not be locked either because some move with the same sequence prefix has a higher number. You may need to resequence it." The hashing logic in account_journal.py enforces a strict continuous sequential chain per journal: https://github.com/odoo/odoo/blob/89993885823f7309b921145eacc7bbe2c3c1e427/addons/account/models/account_journal.py#L671-L678 In LATAM countries, vendor bill document numbers are assigned by the vendor, not by Odoo. A bill with a lower number can legitimately be entered after one with a higher number, which breaks the sequential assumption the hash chain relies on. Allowing it would produce a hash that no longer represents a proper chain, giving users a false sense of security. Sales journals are unaffected because Odoo controls their sequence. Solution Hide the "Secure Posted Entries with Hash" field on purchase journals that have "Use Documents?" enabled, preventing users from enabling an option that cannot work correctly for vendor-assigned document numbers. Sales journals keep the option available since Odoo controls their sequence. opw-6076673 Forward-Port-Of: odoo/odoo#262614 Forward-Port-Of: odoo/odoo#259206
This update resolves an issue where attaching images to invoices could cause system crashes. The fix prevents the system from incorrectly syncing orphaned attachment files, ensuring invoices and PDF generation work reliably. This improves overall invoice processing stability.
Original PR description
Steps to reproduce: - Install documents_account and account_accountant. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError:…
Steps to reproduce: - Install documents_account and account_accountant. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError: `proforma_pdf_attachment` Cause: When attaching an image via a log note, the file becomes the main attachment but is intentionally unlinked (res_model=False) by the system to avoid UI clutter. Downstream modules unknowingly sync this orphaned file. Later, when "Send & Print" generates the real PDF, the system attempts to update the orphaned downstream record, causing model linkage conflicts and eventually a crash. Solution: Add `no_document=True` to the context during `_message_post_after_hook` for invoices. Previously, for incoming emails or log notes, the mail framework would trigger document creation immediately before the core accounting module could evaluate and orphan invalid files (like images). This change suppresses that premature sync, allowing downstream modules to explicitly handle the sync after the attachment's final state is resolved. opw-5930888 Forward-Port-Of: odoo/odoo#262637 Forward-Port-Of: odoo/odoo#258307
This update resolves a bug where sending invoices with attached images caused a system crash. The fix prevents the incorrect syncing of orphaned image attachments, ensuring stable invoice processing and preventing data inconsistencies. This improves the reliability of the documents account feature.
Original PR description
Steps to reproduce: - Set a journal with documents folder sync. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError:…
Steps to reproduce: - Set a journal with documents folder sync. - Create and post a customer invoice. - Add an image attachment via a log note. - Click Send & Print. -> KeyError: `proforma_pdf_attachment` Cause: Adding an image via log note sets it as the main attachment, but it is intentionally orphaned (res_model=False) to prevent UI clutter. `documents_account` incorrectly syncs this unlinked file, creating a workspace document with a missing model. During "Send & Print", the official invoice PDF replaces the image as the main attachment. The document versioning logic intercepts this swap and attempts to re-parent the new PDF to match the orphaned document. This destroys the PDF's linkage to the invoice, causing a crash when the system later attempts to fetch the PDF. Solution: Since the base module now suppresses premature document creation during the message post, we explicitly handle the sync ourselves. We override `_fix_attachments_on_record_from_files_data` to iterate over the validated attachments and trigger document creation only for files that retained their `res_model`. We also add a check inside `_update_or_create_document` to strictly block orphaned attachments. opw-5930888 Forward-Port-Of: odoo/enterprise#116124 Forward-Port-Of: odoo/enterprise#115065
This update resolves an issue preventing non-admin internal users from accessing website import functionality. The fix grants read-only access to a broader group of users, allowing the website generator systray to function correctly without errors. This ensures a smoother experience for all users during website imports.
Original PR description
Steps to reproduce: =================== 1. On a 19.1, launch a website import as admin 2. Log in as a non-admin internal user => AccessError on website_generator.request Cause: ====== The website generator systray polls `website_generator.request` on every page load: https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/website_generator/static/src/systray_items/generator_request.js#L48 Only `base.group_system` had access on the model, so any non-admin user hit an AccessError as soon as an import request existed (session_info sets show_scraper_systray=True for everyone based on the last request's notified flag). Solution: ========= Grant read-only access to `base.group_user`; writes/creates stay restricted to system so the import flow itself is unchanged. => Systray loads silently, shows status indicator opw-6092411 Forward-Port-Of: odoo/enterprise#114879
This update fixes a problem where tax amounts weren't accurately adjusted when users grouped lines within a financial transaction. The change ensures that tax calculations are correct after grouping, improving financial reporting accuracy. Additionally, the test suite has been updated to reflect Belgian tax regulations and a related context key has been removed to align with a recent Odoo update.
Original PR description
[FIX] account_edi_ubl_cii: correct tax amount when grouping lines When the user group lines of a move, the tax amount is now corrected if there's a difference in the tax amount before and after grouping This commit also removes the `ungroup_lines` context key, as the flow was changed in odoo/odoo#252458 Reword the `test_import_and_group_lines_by_tax` test: use belgian company and belgian taxes task-5993555 Forward-Port-Of: odoo/odoo#259256 Forward-Port-Of: odoo/odoo#252719
This update fixes an issue where the CustomGroupByItem dropdown in the search bar wasn't correctly styled on hover. The fix ensures the dropdown items are properly highlighted, improving the user experience and accessibility. It also restores keyboard navigation functionality for this item.
Original PR description
The CustomGroupByItem select was missing the `o-navigable` class, so the navigation system never registered it. On hover, it would not receive the `focus` class, which ensures proper styling of dropdown items. The fix also restores the ability to reach the CustomGroupByItem select with keynav. task-6108677 Forward-Port-Of: odoo/odoo#262608 Forward-Port-Of: odoo/odoo#260675
This update resolves an issue where attachments weren't always uploading correctly when navigating between records in the chatter. The fix ensures attachments are properly associated with the intended record, preventing data inconsistencies and improving the user experience. This improves reliability of attachments in conversations.
Original PR description
Currently, when uploading a bunch of attachments or a big one to the chatter, if you click on the pager (e.g. next) before the upload is complete, the attachments that have not yet been uploaded are uploaded to the next record. Due to the persistence of the Chatter component during record navigation and the fact that the `FileUploader` logic is tied to `state.thread`, an async callback that finishes after a record switch will attempt to update the currently active thread rather than the one that initiated the upload. With this change we tie uploader lifecycle to a specific record and ensure the completion callback only affects that record. task-5119290 Forward-Port-Of: odoo/odoo#262714 Forward-Port-Of: odoo/odoo#261552
This update optimizes how Odoo searches for products, particularly when using complex search criteria. By switching from 'OR' to 'UNION ALL' in database queries, the system now efficiently utilizes indexes, resulting in significantly faster search times. This improves the overall responsiveness of product searches, especially with large product catalogs.
Original PR description
When doing a name_search with positive operators (=, ilike, in) the resulting query combines domains with the OR operator. This works fine when the leaves are all on the same table (product_product…
When doing a name_search with positive operators (=, ilike, in) the resulting query combines domains with the OR operator. This works fine when the leaves are all on the same table (product_product or product_template) as postgresql uses a Bitmap OR when everything is properly indexed.
When leaves are on multiple tables however postgresql has to plan a Seq Scan. For instance, let's take a simple domain on product.product of the form `['|', ('name', 'ilike', 'test'), ('default_code', 'ilike', 'test')]`. Because `name` is an inherited field via `product_tmpl_id`, the resulting query has the where clause `join_table.name ilike %s OR product_product.default_code ilike %s` with `join_table` the table you get after joining product_product and product_template. Since it's an `OR` condition, postgresql does not know in advance whether a given row will pass this condition. There's no way to filter the tables before the join. The condition moves therefore to a `Join Filter` node and postgresql has to scan the whole join table to fetch the correct tuples.
Same thing when there's a subquery. In case of a where clause `cond OR cond OR subquery`, postgresql does not know in advance whether or not a given row is gonna pass the subquery condition. So it has to scan the whole table.
In both cases this becomes a bottlneck when the number of products increaases. This commit introduces the use of `UNION ALL` instead of `OR`. There's one SubPlan for each individual table in the domain. The results are then appended to get the final products matching the conditions. Thanks to each table having its own SubPlan postgresql can now properly hit indexes for each table, greatly improving the performances.
#### speedup
In a database with 2.5M product_product, the name_search on product with a partner_id in the context and the ilike operator goes from 8s -> 5ms.
In another database with 500k product_template, the name_search on template with a partner_id in the context and the ilike operator goes from 1.8s -> 5ms.
opw-4921944
opw-5103287
opw-5049054
opw-5256691
opw-5221753
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#240860
Forward-Port-Of: odoo/odoo#229275This update fixes an issue where self-order combo prices were inaccurate when multiple quantities of the same combo were ordered. The fix accurately calculates prices for combos, ensuring consistent pricing across the mobile app and the linked restaurant's order view. This improves the accuracy of transactions and enhances the customer experience.
Original PR description
**Steps to reproduce:** - Order a combo in the self order Mobile with multiple products - Order the same combo more than once - Checkout and go to the linked restaurant - Go to the orders, the price…
**Steps to reproduce:** - Order a combo in the self order Mobile with multiple products - Order the same combo more than once - Checkout and go to the linked restaurant - Go to the orders, the price is not the same as in the self - If you check the unit prices in the backend, they are not consistent **Why the fix:** This is mostly a backport of bd117e8 with an addition because the extras still did not work as intended. In the backend, during the price recomputation, we did not account for the fact that we could have a parent line with multiple quantity during the split between the free and the extra lines. This means that we counted too many lines, and had to put some in the extra lines. We then override the price_unit with the total_price in this code https://github.com/odoo/odoo/blob/f73c32960721b046076b91e4bc017ddb924e0837/addons/pos_self_order/models/pos_order.py#L341-L342 But the total price has been computed to zero, so the previously computed price_unit is overridden and set to zero. We now divide the line's qty by the parent line's qty to get the qty per parent line, allowing us to have a qty of more than 1 for the parent line. The same is done for the computation of the remaining amount to pay, as **child.qty** is the number of time the item is selected in the combo * the number of combo ordered, meaning it was messing up the computation. There was an oversight in the original fix, which meant that the unit prices were not distributed as they should have been, even though the total was correct. When we only order one combo that costs 25 and has 2 items, both items will have a price_unit of 12.5, but if we have more than 1 qty of said combo, the price_unit will be all over the place and the second item will have to compensate for the first one thanks to https://github.com/odoo/odoo/blob/b108bb847b1c4d3a91f223d77a4888b8139b0a8d/addons/pos_self_order/models/pos_order.py#L322-L323 We now update the original total to take the fact that multiple combo can be ordered. opw-6076911 Forward-Port-Of: odoo/odoo#261810 Forward-Port-Of: odoo/odoo#257922
This update corrects a technical issue that caused a traceback when users removed the Unit of Measure (UOM) from a sales order line. The fix prevents unnecessary calculations related to discounts, ensuring smoother operation when a UOM isn't specified. This improves the reliability of the sales order process.
Original PR description
Issue: --- Due to this issue, there is a TB when you try to remove uom. Steps to reproduce: 1- Create a SO and add a line. 2- On SOL, remove uom. You get a traceback. This is because of `ensure_one` here: https://github.com/odoo/odoo/blob/saas-18.4/addons/product/models/product_pricelist_item.py#L588 We can prevent the discount compute on the line which is causing the `compute_price`, when uom is not set. opw-6144426 Forward-Port-Of: odoo/odoo#262266
This update prevents users without write access from dragging and dropping files into the Odoo chatter interface. This enhancement ensures data security and prevents unauthorized file uploads within conversations, aligning with best practices for user permissions. It's part of a broader effort to improve the stability and security of the Odoo platform.
Original PR description
This commit disables the drag&drop of files into the chatter if the user cannot post on the thread. Part of task-6071789 PR enterprise: https://github.com/odoo/enterprise/pull/115658 Forward-Port-Of: odoo/odoo#262018
This update resolves an issue where the 'attach file' button within the enterprise email system wasn't appearing until the email thread was fully loaded. This change ensures users can seamlessly attach files to emails, improving the overall email functionality. It's a small but important fix for a common user experience problem.
Original PR description
Wait for the attach file button to be enabled, meaning that the thread is loaded. PR community: https://github.com/odoo/odoo/pull/262018 Forward-Port-Of: odoo/enterprise#115658
This update resolves an issue where quantities were incorrectly doubled when settling sales orders in POS using the 'Pick then Deliver' warehouse method. The fix ensures accurate lot quantity tracking by filtering move lines correctly, preventing double-counting of inventory. This improves the reliability of sales order fulfillment.
Original PR description
When settling a sale order in POS after validating the delivery, quantities and lots were wrong for lot-tracked products with warehouse "Pick then Deliver (2 steps)": quantity doubled when loading…
When settling a sale order in POS after validating the delivery, quantities and lots were wrong for lot-tracked products with warehouse "Pick then Deliver (2 steps)": quantity doubled when loading SN/Lots. Steps to reproduce: ------------------- * Create a product with Tracking by lots * In Inventory, set warehouse Outgoing Shipments to "Pick then Deliver (2 steps)" * Create a quotation with the product and confirm it * Validate the delivery * In POS, settle the sale order from Quotation/Order * When asked "Do you want to load the SN/Lots linked to the Sales Order?", click Yes > Observation: Quantity doubled. Why the fix: ------------ read_converted() used move_line_ids from all moves linked to the sale line. With 2-step, both pick and delivery moves have move_line_ids with the same lots, so quantities were counted twice. We now use move lines from exactly one picking and filter by sale_line_id. opw-6001585 Forward-Port-Of: odoo/odoo#262237 Forward-Port-Of: odoo/odoo#253539
This update resolves an unexpected crash in the website's testing environment. The issue stemmed from a recent update to the knowledge component, specifically when the sidebar is closed by clicking the 'save' button. This fix ensures the system handles component destruction gracefully, preventing the crash.
Original PR description
The goal of this commit is to fix the `test_10_website_conditional_visibility` test in the website, which has been crashing unpredictably since the dropdown patch in knowledge. This patch does not handle the case where `dropdownActiveEl` and `this.activeEl` are `undefined` because the component has already been destroyed. In our case, we have a popover that closes when the sidebar closes, triggered by clicking the “save” button. error-243073 Forward-Port-Of: odoo/enterprise#115316
This update resolves an issue where a delay in website navigation elements (specifically dropdown menus) could cause unexpected behavior and errors. By ensuring the menu fully renders before other actions are processed, this fix improves the overall stability and reliability of the website experience. This prevents issues like dropdowns closing prematurely.
Original PR description
[FIX] website: wait for extra menu to fully render before continuing When clicking on the extra menu item, a Bootstrap dropdown is displayed with a transition. Because this transition takes time, it can lead to undeterministic behavior especially in tests. For example, if a tour clicks on the extra menu item and then clicks on the "Site" button in the navbar, the dropdown transition may still be in progress. This can cause the "Site" dropdown to close prematurely. runbot-240955 Forward-Port-Of: odoo/odoo#262660 Forward-Port-Of: odoo/odoo#261179
This update resolves an issue causing instability in the Point of Sale (POS) tour experience. By making the tour predictable and correctly selecting the order, the problem is fixed. A minor typo in a test was also corrected to ensure consistent results.
Original PR description
Remove the `undeterministicTour_doNotCopy` key from `OrderFlowTour` and make the tour deterministic by properly selecting the order. Also, fix a typo in the assertion in `test_01_order_flow`. Task-6065459
This update corrects a bug in how HR version searches were performed. Previously, searches were incorrectly using outdated date fields, leading to inaccurate results. This fix ensures searches now correctly utilize the intended date ranges, improving the reliability of HR version searches.
Original PR description
Previously, the searches defaulted to delegating the search to the contract_date_start/end fields instead of mapping to the actual computes of date_start and date_end, which caused incorrect results when searching for versions with a specified date_start or date_end. This PR fixes this by implementing the search method on date_start and date_end to correctly map the search to the expected values for date_start and date_end. Task-6067139 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 Forward-Port-Of: odoo/odoo#256581
This update corrects an issue where payslips were incorrectly referencing contract dates instead of the correct version dates. This change ensures payslips accurately reflect the version of the contract being processed, improving payroll accuracy. This fix was enabled by a related update to Odoo's search functionality.
Original PR description
Prior to this commit, the version domain on payslips only looked at the contract dates rather than the version's dates. The domain was fixed in this commit to limit the domain based on the version's dates instead, and this was allowed after the searches on the version date_start and date_end fields were fixed in the odoo/odoo#256581. task-6067139 Forward-Port-Of: odoo/enterprise#113818
This update resolves an issue where users could unintentionally create links within inline code or code blocks when using the Ctrl+K shortcut. The change ensures that the editor correctly handles selections within code formatting, preventing unwanted link creation and improving the overall user experience. This improves the reliability of the HTML editor.
Original PR description
Description of the issue this PR addresses: This commit ensures that links are not created when the selection is inside inline code or a code block, even when using the Ctrl+K shortcut. task-5489870 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262778 Forward-Port-Of: odoo/odoo#262397
This update resolves an issue where referenced refunds in Viva.com payments were incorrectly reversing the original payment due to a missing session ID. A previous update inadvertently removed this key information. This fix restores the session ID, ensuring refunds process correctly and accurately reversing the intended payment.
Original PR description
Referenced refunds in Viva.com require the session ID of the original payment to be sent, resulting in that payment being reversed. Unfortunately this functionality was broken when a forward-port PR (odoo/odoo#236004) mistakenly removed the `parentSessionId` field from the request. This commit restores the `parentSessionId` field, fixing the issue. It also adds a tour to test the full payment and referenced refund flow. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262911 Forward-Port-Of: odoo/odoo#262475
This update resolves an issue where invoices sent via Peppol were failing for customers in Iceland and Albania. The change ensures that VAT numbers for these countries retain their country code prefix, allowing successful invoice transmission. This improves compliance and usability for our international customers.
Original PR description
Current behavior before PR: To send an invoice via Peppol, the customer's VAT must have the country code as a prefix. But while creating customers from countries like Iceland and Albania, It removes the country code prefix. Which later raises an error while sending the invoice that "The VAT of the customer should be prefixed with its country code." Desired behavior after PR is merged: VAT numbers for customers in Iceland and Albania now keep their country code prefix, letting users to send invoices via Peppol. task-6050791 Forward-Port-Of: odoo/odoo#259105
This update fixes an error where the cost of kits was being incorrectly calculated in sales orders. Previously, when ordering a kit with multiple components, the system was multiplying the cost by the batch size, leading to inflated prices. This change ensures accurate kit costing by dividing the total component cost by the kit's quantity.
Original PR description
### Issue: When a kit BoM has `product_qty` > 1 (e.g. 12 Kit X = 12 Comp A + 12 Comp B), the SO line cost after confirmation is multiplied by the batch size. Selling 1 Kit X shows a cost of 360…
### Issue: When a kit BoM has `product_qty` > 1 (e.g. 12 Kit X = 12 Comp A + 12 Comp B), the SO line cost after confirmation is multiplied by the batch size. Selling 1 Kit X shows a cost of 360 instead of 30. ### Cause: The method `_compute_average_price` uses `bom.explode(self, 1)`, which returns raw BoM line quantities for one full batch. It accumulates the total batch cost but returns it without dividing by `bom.product_qty`. ### Steps to Reproduce: - Costing Method = AVCO, Inventory Valuation = Automated - Comp A (cost 10), Comp B (cost 20), Kit X (cost 0) - Kit BoM: 12 Kit X = 12 x Comp A + 12 x Comp B - Create and confirm a SO for 1 x Kit X - Expected SO line cost: 30 - Actual SO line cost: 360 Solution: This fix mirrors the normalization already done in `_compute_bom_price`, which correctly divides by `bom.product_qty` and converts UoMs. opw-5969310 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#259005 Forward-Port-Of: odoo/odoo#253406
This update fixes a bug where users could accidentally add text within image-only gallery items (like Banner and Image Wall blocks). The change prevents users from directly editing the image content, ensuring galleries always display images as intended. This improves the visual consistency and reliability of website designs.
Original PR description
Some image items are supposed to not contain any extra content. Grid image items and `s_image_gallery`'s images are such images. Grid image-only items are actually `contenteditable`. This makes it possible to replace the image with text. A similar issue exists for images inside `s_image_gallery` blocks. This commit makes such items non-editable, while keeping the media inside it replaceable. Steps to reproduce: - Drop a Banner block - Select an image - Type something => Image was replaced with text - Drop an Image Wall - Select an Image - Type something => Image was replaced with text task-5436148 Forward-Port-Of: odoo/odoo#258018
This update resolves an issue where signing documents with read-only date fields would be blocked due to a system error. The fix ensures that read-only date fields are correctly recognized and included during the signing process, preventing the 'required items not filled' warning. This improves the overall usability of the signing feature.
Original PR description
Version: - saas-19.2 Steps to reproduce: - Create a sign template with a read-only (constant) date field. - Add at least one more sign item (e.g., text/signature). - Try to sign the document. Issue: - Signing is blocked with warning: “Some required items are not filled”. Cause: - Read-only date fields don’t have a value in `item.el.value`. - The system only checks value, so it treats the field as empty. - Even though the date is visible in the document, it is not picked during submission. Solution: - Update date value extraction to also read from `textContent` when value is empty. - This ensures read-only date fields are correctly considered filled. task-6181883
This update resolves an issue where uploading an empty file to the Sign Documents feature would cause an error. The fix ensures that empty file uploads are handled correctly, preventing the application from crashing. This improves the reliability of the Sign module for users.
Original PR description
## Steps to Reproduce: - Install the Sign module. - Try to upload an empty file in Sign Documents. Sample File: https://drive.google.com/file/d/1ik3b7Z--Xla_TmvRj92uTCGy1PspQ_cP/view?usp=drive_link ## Error: `TypeError - a bytes-like object is required, not 'bool'` ## Cause: Before saas-19.2, at [1] `datas` returns an empty binary string (`b''`) when the file content is empty. After the [refactor], `raw` is used instead, which returns `False` for empty content, leading to this error. ## Fix: This commit ensures that when the attachment raw value is False, it is replaced with an empty binary string (`b''`). [refactor]: https://github.com/odoo/enterprise/commit/8d66ffa62ab3fb3334528999d4534a9a995c6830 [1] - https://github.com/odoo/enterprise/blob/0d70215fb5d7b72dcfe86ac23fd04208329aad5d/sign/models/sign_document.py#L65 sentry-7432818850
This update corrects an issue where multiple users were incorrectly added to Whatsapp discussion channels after a message was sent. The fix ensures that only the user who initiated the conversation is added, preventing notification overload and improving channel management. This resolves a bug related to improperly formatted phone numbers.
Original PR description
…ser sends a template message when creating discussion channels after the partner sends a message back. Issue: Currently, When there are multiple users listed under whatsapp.account.notify_user_ids no matter what, when creating a new discuss channel it will add all users in that list. Even when a single user inside that list initiated the conversation with a template. To replicate in runbot add multiple users to whatsapp.account.notify_user_ids, make a partner with a number, send a template, then have the partner send a message back. All users will be notified and added to the channel. There was an unformatted number being passed to a function that required the formatted number. This caused _find_active_channel to find 0 active channels. Fix: Format the number received from the message values inside WhatsAppAccount._process_messages opw-5349138 Forward-Port-Of: odoo/enterprise#114912 Forward-Port-Of: odoo/enterprise#102452
This update resolves an issue where Spanish invoices with amounts below a certain threshold were incorrectly included in the Mod347 BOE export. The fix removes a redundant search process that was adding partners unnecessarily, ensuring that only relevant partners are included based on the core BOE requirements. This improves the accuracy of the export data for Spanish businesses.
Original PR description
Fix a bug in mod347 BOE export. Steps to reproduce: 1- Create an invoice with a spain Company, with an amount lower than 3 005,06€ 2- Add a Type for mod347 3- Create a cash payment 4- Export the mod347 BOE The partner will appear in the BOE with all line at 0. But this partner shouldn't be in the export. This is due because of a search on account.partial.reconcile, which add partners to the export if a cash payment is found in the period. But this search is not usefully as there is no legal indication that these partners should be in the export in this case, as the partners should only be returned by the main queries. Backport of PR #84317 opw-5960226 Forward-Port-Of: odoo/enterprise#116035 Forward-Port-Of: odoo/enterprise#110947
This update fixes an issue where Purchase Orders generated from Point of Sale orders weren't including the custom attribute information. The change ensures that the product description is correctly computed for POS orders, leading to more accurate purchase order details. This improves the consistency of order data.
Original PR description
Step to reproduce: - install "purchase_stock" and "point_of_sale" - Create a product attribute -> Display Type: Radio Button -> Variant Creation Mode: Never create variants -> Add two attribute…
Step to reproduce: - install "purchase_stock" and "point_of_sale" - Create a product attribute -> Display Type: Radio Button -> Variant Creation Mode: Never create variants -> Add two attribute values, ensuring that one includes a 'is_custom' field. - Create a product and assign this attribute to it. - Enable the MTO (Make To Order) route. - Add a vendor to the product. - Create and confirm a POS order for this product. (add text for custom attr) - Observe that a Purchase Order is generated automatically. Observation: - the PO does not have that text in description Cause: - After commit [1], `description_picking` became a computed field. - Previously, its value (`product_description_variants`) was set in `_prepare_procurement_values`. - That key is no longer used for this purpose, so the information is not propagated and the data is lost. https://github.com/odoo/odoo/blob/71b1267e54fd53fb283c41b579756c72e393cbfa/addons/stock/models/stock_rule.py#L341-L343 above code is removed following that commit Fix: - The description is computed for pos orders [1] https://github.com/odoo/odoo/commit/6b2d3af64a076654e04494972acc4c42d7c54bd8 opw-5969378 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262503 Forward-Port-Of: odoo/odoo#253231
This update fixes an error in the manufacturing report that incorrectly converted quantities between different units of measure (UoM). The report now accurately calculates the total cost and quantity produced, ensuring consistent results regardless of the input UoM, which is crucial for accurate cost tracking and reporting.
Original PR description
Steps to reproduce:
- Create a product W1 with UoM = Kg with the following BoM:
- Component C1: 1 unit, cost = $1
- Create and confirm MO1:
- Produce 1 Kg of W1 → total cost = $1
- Create and confirm MO2:
- Produce 1 Ton of W1 → total cost = $1000
- Open the Manufacturing Report and group results
Problem:
- qty_produced ≈ 1.001 instead of 1001
- unit_cost average ≈ 1000 instead of 1
Expected behavior:
- qty_produced = 1001
- unit_cost average = 1 (consistent across MOs)
The manufacturing report (`mrp.report`) incorrectly converts quantities from move UoM to product UoM, leading to wrong `qty_produced` and `qty_demanded` values when different units of measure are used
The current implementation uses:
sm.quantity / uom.factor * uom_prod.factor
This inverts the conversion ratio. As a result:
- 1 Ton is converted to 0.001 Kg instead of 1000 Kg
opw-6097098
Forward-Port-Of: odoo/enterprise#114233
Forward-Port-Of: odoo/enterprise#113979This update ensures Odoo's Dutch reporting modules (SBR) correctly submit data to the new Digipoort infrastructure, which is migrating to digipoort.logius.nl by May 1, 2026. This change is critical to avoid submission failures and maintain compliance with Dutch reporting requirements.
Original PR description
*: l10n_nl_reports_sbr{,_icp,_status_info}
---
Description of the issue this commit addresses:
The Dutch Digipoort endpoint infrastructure is being migrated from procesinfrastructuur.nl to digipoort.logius.nl effective May 1, 2026. Odoo's SBR modules need to use the new endpoints or submissions will fail.
---
Desired behavior after this commit is merged:
This commit updates all Digipoort endpoint URLs (delivery and status services) from the old domain to the new logius.nl domain, and clarifies that valid PKIoverheid certificates are required for both environments. Reports now submit to the new Digipoort infrastructure correctly.
---
task-6171403
Forward-Port-Of: odoo/enterprise#115668This update resolves an issue where purchase order suggestions were sending the wrong key in the context, leading to incorrect behavior. The fix ensures the correct key, `section_id`, is used, improving the accuracy and reliability of the purchase order suggestion process. This ensures purchase order suggestions function as intended.
Original PR description
Issue: - `_editSuggestContext` sends `sectionId` in the context, but `action_purchase_order_suggest` expects the key to be `section_id`. Fix: - Update the `_editSuggestContext` to send the correct context key, `section_id`. Forward-Port-Of: odoo/odoo#261930
This update resolves an issue where the last column of accounting reports was partially cut off when scrolling to the bottom. The fix adds bottom padding to the reports, ensuring all data is fully visible and accessible. This improves the clarity and usability of financial reports.
Original PR description
Before this commit, there was no bottom padding in the accounting reports, which caused the last column’s values to appear partially cut off when scrolling to the bottom. This issue started occurring after the PR: https://github.com/odoo/enterprise/pull/99198 opw-6130981 **Before fix (runbot)** <img width="1920" height="1005" alt="image" src="https://github.com/user-attachments/assets/808bbb2b-3b4e-4b5c-a872-b8bd7bf589ba" /> **After fix:** <img width="1917" height="1006" alt="image" src="https://github.com/user-attachments/assets/55f04e1f-0469-46e1-af69-f5055a7232d9" /> Forward-Port-Of: odoo/enterprise#116329 Forward-Port-Of: odoo/enterprise#116168
This update resolves an issue where custom website snippets weren't correctly reflecting translated content when using the delayed translation feature. The change ensures that translated values are properly applied to snippets immediately after saving, improving the user experience for multilingual websites. This prevents a delay in seeing translated content when using custom snippets.
Original PR description
The feature "delayed translation" and "copy translation in custom snippet" have been worked on in parallel, but had buggy interactions. This commit changes the way translations terms are copied in custom snippets to read and write the translated values as expected with delayed translations. Steps to reproduce: - With a page with some content on a website in 2 languages - Open the website builder in the main language - Drop a custom snippet - Save - Bug: The change is immediate on the version in the second language (instead of being only available after user translated it) Delayed translations: 2d08f97c0778469b409fca23f2be5f5a98ce3df8 Copy translation in custom snippet: d3426b7714012e833caae10281cfb8433223299a Re-enabling delayed translations: 03a85b13b2c46ef7174123d902e95d5103031c6c task-5474184 Forward-Port-Of: odoo/odoo#262814 Forward-Port-Of: odoo/odoo#245850