Tuesday, June 2, 2026
48 changes · saas-19.1
Resolved issues and error corrections
This update addresses a requirement from the Peruvian tax authority, SUNAT, regarding delivery guides for freight transport. Previously, a 'carrier handover date' field was missing, causing errors when submitting delivery guides. The fix automatically detects this error and prompts users to update to the latest module version to ensure compliance.
Original PR description
SUNAT R. S. N° 000108-2026/SUNAT and the GRE validation rules published on 2026-06-01 add field 34 "Fecha de entrega de bienes al transportista" (cac:LoadingTransportEvent/cbc:OccurrenceDate). It is required, and rejected with error 3617 when absent, only when the transport modality is '01' (public transport). Enforcement started 2026-06-01, so affected customers can no longer submit their delivery guides.
In our implementation the departure start date is equivalent to this date, so we reuse it instead of adding a new field. The node is gated to public transport to match the validation rule and avoid emitting it on private transport ('02') guides.
Because the new node only ships with this module version, customers on an older version keep hitting error 3617 from SUNAT. Detect that code in the SUNAT response and store an actionable message asking the user to update the module, instead of surfacing the raw rejection.
task-6266662
Forward-Port-Of: odoo/enterprise#119038This update optimizes the way Odoo calculates the appearance of work orders, specifically during actions like resizing windows or scrolling. By changing a selector, the system now recalculates styles more efficiently, leading to a smoother user experience. This improves performance without changing any functionality.
Original PR description
Avoid using the :has() selector and use a specific class on the body instead to replicate the same behavior, this reduces work during the "Recalculate Style" phase. It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. Forward-Port-Of: odoo/enterprise#118618
This update resolves an issue where custom POS modules could unexpectedly block login. By introducing a new control mechanism, modules can now reliably manage login access without relying on specific `setCashier` return values, ensuring a smoother and more consistent login experience for users.
Original PR description
When a custom module patches `setCashier` without returning a value, the login check in `select_cashier_mixin` received `undefined` (falsy), causing the login flow to abort even though the cashier was set correctly. Introduce a dedicated `canLoginCashier` hook on `PosStore` that controls whether a login attempt should proceed. The mixin now calls this method before `setCashier`, decoupling the login guard from `setCashier`'s return value entirely. Custom modules that need to block login should override `canLoginCashier` instead of relying on `setCashier` returning `false`. opw-6247190 Forward-Port-Of: odoo/enterprise#118951
This update fixes an issue where custom POS module configurations were unexpectedly blocking login. By introducing a new check within the POS system, we now ensure that login attempts are handled correctly regardless of how a cashier is set, providing a smoother and more reliable user experience. This change simplifies module customization for POS login behavior.
Original PR description
When a custom module patches `setCashier` without returning a value, the login check in `select_cashier_mixin` received `undefined` (falsy), causing the login flow to abort even though the cashier was set correctly. Introduce a dedicated canLoginCashier hook on PosStore that controls whether a login attempt should proceed. The mixin now calls this method before setCashier, decoupling the login guard from setCashier's return value entirely. Custom modules that need to block login should override canLoginCashier instead of relying on setCashier returning false. opw-6247190 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267428
This update fixes a visual issue in the Project Kanban view where custom colors weren't being displayed correctly. The fix ensures that project status colors are accurately rendered by updating the stylesheet to match the calculated modulo values used by the frontend.
Original PR description
### The Issue: The frontend Kanban view enforces a strict 12-color limit using a modulo 12 mathematical rule (which calculates the remainder after dividing by 12). When the frontend receives our high backend IDs (20-24), it runs this modulo math (e.g., 23 % 12) to force them into the allowed limit, converting them into the remainders: IDs 8, 9, 10, 11 and 0. Because stylesheet was still searching for the original high numbers (20-24) instead of these modulo results, the custom colors were completely ignored by the browser. ### The Fix: Updated the stylesheet to target the actual modulo-computed classes (.oe_kanban_color_8 through 11 and 0). Mapped these classes to their correct variables (-success, -info, -warning, -danger, -primary) and fixed the left border styling so the colors render properly. task-6064106 Forward-Port-Of: odoo/odoo#266693 Forward-Port-Of: odoo/odoo#256023
This update resolves an issue where the E-Invoice QR code would break when multiple invoices were displayed, and a related layout problem with Mydata classification groups shrinking. The changes ensure the QR code displays correctly regardless of the number of invoices and maintain a consistent layout.
Original PR description
before this commit: - The QR code on the E-Invoice broke when multiple invoice lines were reduced the available space. - Mydata classification group is shrink. after this commit: - Adjusted the layout to ensure the QR code moves to a new page if there isn't enough space on the current page. - Fix Mydata classification shrink issue. task-6026681 Forward-Port-Of: odoo/odoo#266660
This update resolves an issue where branch users were unable to save new journal entries due to access restrictions. The fix adds elevated permissions to the query used to identify sequence gaps, allowing branch users to correctly create entries within their company's journal. This ensures branch users can perform standard accounting tasks.
Original PR description
**Steps to reproduce:** * Create a parent company with a branch company (Settings > Companies). * Create a user whose **only** allowed company is the branch. * While logged in as a parent-company…
**Steps to reproduce:** * Create a parent company with a branch company (Settings > Companies). * Create a user whose **only** allowed company is the branch. * While logged in as a parent-company admin, open the Miscellaneous Operations journal, find the first or second posted entry, reset it to draft, clear its name to a digits-only value (e.g. `0001`) and save – leaving it in draft state. This stores `sequence_prefix = ''` and `sequence_number = 1` in the database. * Log in as the branch-company user. * Navigate to Accounting > Journal Entries > New. * Set any date and save the draft entry (or simply write `name = '/'` on it). **Observed behavior:** * Saving fails with: `odoo.exceptions.AccessError: You are not allowed to access 'Journal Entry' (account.move) records.` **Cause:** * `_update_sequence_made_gap`, introduced in 19.0, detects sequence holes by running a raw SQL query that finds the two entries immediately before and after each move in the same journal with the same `sequence_prefix`. The query contains **no `company_id` filter**. * In a branch-company setup the parent's journal (`journal_id`) is shared across companies. When an early entry's `name` is cleared to a digits-only value its `sequence_prefix` becomes `''`. A new entry created by the branch user also starts with `name = '/'`, which gives it `sequence_prefix = ''` and `sequence_number = 0`. The SQL therefore returns the parent company's entry (`sequence_number = 1`, `sequence_prefix = ''`) as the `next_id` neighbour. * The IDs from that query are passed to a local `browse()` closure, which in 19.0 read: https://github.com/odoo/odoo/blob/af37df9bee34fe60c1e51896af23fc7fe9b76cfc/addons/account/models/account_move.py#L5770-L5771 * `self.browse()` inherits the **non-sudo** environment of the branch user. When the method subsequently writes `move_n1.made_sequence_gap = …` on the browsed parent-company record, the ORM record-rule check finds the branch user has no access to that company → **`AccessError`**. * This is a regression from 18.4 where the equivalent `_set_next_made_sequence_gap` explicitly used `.sudo()` when searching for neighbour moves: https://github.com/odoo/odoo/blob/22d84ae99bb79e7b1022367e6bc1b61cc8d9e8b1/addons/account/models/account_move.py#L5453-L5457 **Fix:** * Add `.sudo()` inside the `browse()` closure so that neighbouring moves are always accessed with elevated rights, regardless of the calling user's company context. * `made_sequence_gap` is a UI-only flag that indicates sequence holes; it carries no security or financial significance, making the sudo escalation safe. opw-6231085 Forward-Port-Of: odoo/odoo#266676
This update fixes an issue where the Table of Contents in the HTML editor wasn't updating properly after editing headings. Specifically, deleting a heading caused the ToC to fail to refresh. The fix ensures the ToC always updates correctly, regardless of editing activity, improving the user experience when creating and managing content.
Original PR description
Steps to Reproduce : - Go to To-Do → Create New and add a Table of Content block - Type text → in new line create /h1 → it appears in ToC - Place cursor before /h1 and press Backspace → it merges with paragraph Description of the issue: Table of Content block does not update accordingly Cause: After the heading is merged with the previous paragraph, `delayedUpdateTableOfContents` is triggered, but at that time no heading is available in the editable area. As a result, instead of updating the Table of Contents, it returns without making any changes. Solution: If Table of content already contains heading, then update regardless of whether editable contains heading elements or not. task-6150579 Forward-Port-Of: odoo/odoo#264161 Forward-Port-Of: odoo/odoo#261675
The WIP report now displays accurate information when using analytic items tracked only with projects. Previously, demo data was shown, which could mislead users. This fix ensures the report preview correctly reflects the data associated with the analytic item, improving report clarity and user understanding.
Original PR description
Currently, when printing the WIP report, demo data is displayed if no product or references are provided on the analytic item. ## Steps to produce: - Install Manufacturing and Accounting - Go to…
Currently, when printing the WIP report, demo data is displayed if no product or references are provided on the analytic item. ## Steps to produce: - Install Manufacturing and Accounting - Go to settings and Enable Analytic Accounting - Search Analytic items and create a new Analytic Item by providing a description and amount. - Gear Icon > print and open the WIP report ## Observed Behavior: The report displays a product (laptop) with a demo reference. This becomes problematic when an analytic item is tracked only with a project, as it still causes product and reference data to appear on the analytic item. This can mislead the user. ## Root cause: After this [commit](https://github.com/odoo/odoo/commit/967ac550e38bab915180647dea6eccb2ae1b3b31), demo data values were added to the report to support report editor previews in the web studio. This helps users understand how the report will look while they are editing it. However, although an account analytic line is defined at [1], no values for fields such as products and references are specified on the form. As a result, the template falls back to the preview values provided. [1]- https://github.com/odoo/odoo/blob/d66bb0d7b550b11876dbc7b9d87f5b2adc17dd74/addons/mrp_account/report/report_mrp_templates.xml#L32-L53 ## Solution: Using `data-oe-demo` instead of removing the fallback data appears to be the best approach, as it allows the report editor to continue using demo values for the report preview, as shown at [2] **Before:** <img width="871" height="340" alt="image" src="https://github.com/user-attachments/assets/91897dbd-65d8-4f70-8f22-ea38b42ba28d" /> **After:** <img width="815" height="380" alt="image" src="https://github.com/user-attachments/assets/ffcf509b-f534-47a8-be1d-53a798995443" /> [2]: https://github.com/odoo/enterprise/blob/a739c6c03c6629bad80f3fe61b1035ce156d59c6/web_studio/static/src/client_action/report_editor/report_iframe.scss#L65-L75 opw-6151563 Forward-Port-Of: odoo/odoo#262517
This update resolves an issue preventing users from scheduling tasks via drag and drop in the Field Service calendar view. The problem stemmed from a validation rule within the industry_fsm module incorrectly resetting deadlines when date changes were detected. This fix ensures drag-and-drop scheduling functions correctly, improving the usability of the Field Service calendar.
Original PR description
Steps to reproduce: ----------------------------------- 1. Install the Field Service module with demo data 2. Go to Projects > Field service 3. Navigate to Calendar view 4. If there's no task in 'To…
Steps to reproduce: ----------------------------------- 1. Install the Field Service module with demo data 2. Go to Projects > Field service 3. Navigate to Calendar view 4. If there's no task in 'To Schedule' section, Drag and drop some tasks into it 5. Now, Try to drag and drop task from 'To Schedule' to the calendar Observation: ----------------------------------- The task is not scheduled by drag and drop in the calendar view Issue: ------------------------------------ When a user drags a task, the Javascript Calendar Model creates an RPC call to `plan_task_in_calendar(vals)`, where `vals` uses `planned_date_start` as the key instead of the database column name `planned_date_begin`. https://github.com/odoo/odoo/blob/153d6bab23f41f340058b98b7708ed058019f35c/addons/project/static/src/views/project_task_calendar/project_task_calendar_model.js#L44-L58 For standard project tasks, the backend `write()` method accepts `planned_date_start` and triggers its `_inverse` method, effectively redirecting the value to the deadline without complaining https://github.com/odoo/enterprise/blob/2f8121157f6dd2e19e242cf8de93b321d7ae0415/project_enterprise/models/project_task.py#L412-L418 However, the `industry_fsm` module implements strict validation in its own `write()` override: if it detects that dates were changed but `planned_date_begin` is totally missing from the update values, it forcibly resets all deadlines to `False`. Therefore, the FSM task scheduling was silently aborted entirely. https://github.com/odoo/enterprise/blob/2f8121157f6dd2e19e242cf8de93b321d7ae0415/industry_fsm/models/project_task.py#L169-L175 Solution: ------------------------------------ We override `plan_task_in_calendar` inside the `industry_fsm` module. This cleanly resolves the mismatch between the frontend interface and the backend table structure precisely at the RPC entry point. By isolating the fix mapping strictly to the FSM module override, we ensure we satisfy the strict FSM `write()` validations Note ------------------------------------ Alternate Approach: https://github.com/odoo/enterprise/commit/5cd627efdc3b2cf1db99a3532b36f2299b123724 Update the calendar view XML definition to use `planned_date_begin` instead of `planned_date_start` for the `date_start` attribute. As calendar drag-and-drop functionality fails due to field name mismatch. The `scheduleEvent` method uses `fieldMapping` to construct vals with 'planned_date_start' as the `date_start` field. https://github.com/odoo/odoo/blob/01df8267ec14cac4a773f78952a7aa9406e00fd4/addons/project/static/src/views/project_task_calendar/project_task_calendar_model.js#L44-L54 opw-6090448
This update clarifies the 'invalid_scope' error message displayed when users lack the necessary legal permissions to grant consent for a company. The change improves user understanding and helps ensure proper setup of the l10n_be_intervat module. This resolves a previous usability issue.
Original PR description
The invalid_scope error message means the user doesn't hav the legal rights to give consent for the given company. But the error message is not clear enough. This commit improve the error message clarity. task-6144883 Forward-Port-Of: odoo/enterprise#115650
This update resolves a technical issue where the headers in the DMFA report were incorrectly switched. The 'Calculation Basis' and 'Contribution Type' headers have been corrected, ensuring accurate reporting for payroll calculations. This fix maintains the integrity of financial data.
Original PR description
DMFA report had "Calculation Basis" and "Contribution Type" header switched. Got switched back correctly. task-6227590 Forward-Port-Of: odoo/enterprise#117740
A test was failing due to a limitation in how the POS system loads partner data. This fix ensures that all partners are properly searched for, resolving the test failure and improving the reliability of the point-of-sale tax feature. This ensures consistent functionality for users.
Original PR description
**Issue:** `test_pos_fiscal_position_without_pos_avatax` test is failing with demo data because a US partner is created and searched for in the tour, but only the first 100 partners (alphabetically ordered) are loaded in the POS. Therefore, he's not found. runbot-938983 Forward-Port-Of: odoo/enterprise#118345
This update ensures that the l10n_id_reports module can be properly translated within Odoo. By adding the module to the Weblate configuration file (.weblate.json), the team can now manage and update translations for this specific module, improving localization support.
Original PR description
Enable translation management by adding the module entry to .weblate.json. task-6239169 Forward-Port-Of: odoo/enterprise#118931
A recent test failure related to demo data installation has been resolved. The fix ensures that simulation offers are hidden by applying a filter, preventing the test from failing. This improves the stability of the salary payroll module.
Original PR description
**Problem**: The test fails when demo data is installed because some steps expect an empty list view. **Fix**: Ensure the simulation offer is hidden by applying a custom filter on the simulation employee Task: 6246575 Forward-Port-Of: odoo/enterprise#118358
This update corrects a display issue in the Sales graph view where the currency was incorrectly showing as USD even when all data was in EUR. The fix prevents unnecessary currency conversion when only one currency is present in the graph, ensuring accurate reporting and a consistent user experience. This resolves a bug related to how the system handles currency grouping.
Original PR description
Steps to reproduce ================== - Install sale_managemement - Enable the EUR currency - Create a new company with the EUR currency - Enable both the current and the new company as the main one - Go to Sales - Switch to the graph view - Group by Order Date > year - Hover over a bar => The currency is in USD - Group by Order Date > Week => The currency is now in EUR even though all records are in USD Cause of the issue ================== _web_read_group_fill_temporal returns an empty array in currency_id:array_agg_distinct when there are no records in that group The undefined currency was then added to graphCurrencies. => graphCurrencies = [1, undefined] Since graphCurrencies has more than one item, the currencies are converted opw-6226827 Forward-Port-Of: odoo/odoo#266972
This update resolves an issue where employees with overlapping contracts would incorrectly receive a 'Duplicate Payslip' warning. The change limits the warning check to only consider payslips with the same version, ensuring accurate reporting and reducing unnecessary alerts for common contract transitions. This improves the user experience and data accuracy.
Original PR description
If an employee has a contract that ends in the middle of the month and another contract starts in the same month, the two payslips that are created for the month trigger the "Duplicate Payslip" warning, even though they use different version IDs. This commit limits the search domain for the duplicate payslips to only consider payslips with the same version ID. task-6226391 Forward-Port-Of: odoo/enterprise#118652
This update resolves an issue where invoices on the customer portal were not sorted correctly by payment status. The fix changes the sorting field to use the actual payment state, ensuring users see invoices organized by their payment status (e.g., Paid, In Payment).
Original PR description
Steps to produce: --- - Install the `Accounting` module. - Create several invoices for a portal user with different payment states (e.g., In Payment, Not Paid, Paid). - Log in as the portal user. -…
Steps to produce: --- - Install the `Accounting` module. - Create several invoices for a portal user with different payment states (e.g., In Payment, Not Paid, Paid). - Log in as the portal user. - Navigate to the invoices list and attempt to sort by **Status**. Issue:- --- - Sorting by **Status** does not reflect the actual invoice payment status, resulting in incorrect ordering. Root cause: --- - At [1], the sorting field for Status is set to state, which corresponds to invoice states (Draft, Posted, Cancelled). However, the portal displays and expects sorting based on payment_state. Fix: --- - Update the sorting configuration to use payment_state instead of state, ensuring that invoices are sorted correctly according to their payment status on the portal. [1]https://github.com/odoo/odoo/blob/5b85287ec4ea9f1b51e0f33402900777dfeeb725/addons/account/controllers/portal.py#L46-L52 opw-6128998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262976
This update resolves a recurring issue in a key test for our web interface. Previously, a delay in the autocomplete process could cause the test to fail. By ensuring all timers are executed, this fix guarantees the autocomplete search is always performed and verified, increasing the reliability of our testing process.
Original PR description
This test was sometimes failing, when the debounce delay (250ms) of the autocomplete ended before the end of the test, resulting in an unexepected "web_name_search" step. With this commit, we run all timers, thus ensuring the web_name_search to be always done, and we assert it. runbot error~937794 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#267407
This update resolves an issue where the PEPPOL response service was missing after a company registered as a receiver. The fix ensures that the system correctly updates supported services following the initial registration process, allowing for seamless integration with PEPPOL.
Original PR description
To register as receiver we only call the `2/connect` route (and not any of the other `register*` routes). But currently that route does not update the supported services. Thus the response service is missing when the `account_peppol_response` module is installed before registering. We add the supported document identifiers to the `connect` call here. We change the route on IAP to update the services. task-None IAP PR: https://github.com/odoo/iap-apps/pull/1582 Forward-Port-Of: odoo/odoo#263747
This update resolves a visual glitch where a gradient color filter remained on website sections after the background image was removed. The fix directly removes the associated filter element, ensuring a cleaner and more consistent appearance for website pages. This improves the user experience and prevents unexpected visual artifacts.
Original PR description
Steps to reproduce: - Edit a website page. - Select a section with a background image. - Set a gradient color filter on the background image. - Remove the background image. => The gradient color filter stays in the section DOM. After this commit, `removeBackgroundImage` directly removes the related `.o_we_bg_filter`. Forward-Port-Of: odoo/odoo#265025
This update resolves an issue where VeriFactu invoices were failing due to unexpected characters in the generated sequence numbers. The fix prevents errors when users add prefixes or suffixes to the sequence configuration, ensuring invoices are correctly sent to VeriFactu. This improves the reliability of the VeriFactu integration.
Original PR description
**Steps to reproduce:** 1. Install l10n_es_edi_verifactu. 2. Switch to a ES company. 3. Create a customer invoice and send it to VeriFactu. 4. Enable Developer Mode. 5. Go to Settings > Technical >…
**Steps to reproduce:** 1. Install l10n_es_edi_verifactu. 2. Switch to a ES company. 3. Create a customer invoice and send it to VeriFactu. 4. Enable Developer Mode. 5. Go to Settings > Technical > Sequences & Identifiers > Sequences. 6. Search for the `Sequence Code: l10n_es_edi_verifactu` and open it. 7. Set a prefix or suffix using any alphabetical character. 8. Create a new invoice and send it to VeriFactu **Issue:** Traceback on sending Veri*Factu: `ValueError: invalid literal for int() with base 10: 'F260001'` **Cause:** The value returned by `ir.sequence.next_by_id()` may contain alphabetical characters (due to prefix/suffix), while the field `chain_index` expects an integer. The raw sequence value was directly assigned, causing the conversion to fail. **Fix:** Catch the ValueError raised by int() when the sequence value contains non-numeric characters (e.g. due to a prefix/suffix). Instead of crashing, surface a user-friendly error on the document telling the user to remove the prefix/suffix from the sequence configuration. **opw-6037528** Forward-Port-Of: odoo/odoo#255473
This update resolves an issue where Odoo was incorrectly flagging incoterm requirements for invoices with service products, specifically export invoices. The fix ensures that service invoices, which don't require incoterm information, no longer trigger this alert, streamlining the export process for GT EDI users. This prevents unnecessary errors and improves invoice processing efficiency.
Original PR description
With l10n_gt_edi: - Create an invoice with a partner without a country (in l10n_gt this is considered an export invoice) and a service product. When trying to export the invoice to the tax agency, the following alert is triggered: Incoterm is required on export invoice with goods product but it's currently missing However, service products do not require incoterm configuration. opw-6170409 Forward-Port-Of: odoo/enterprise#115833
This update fixes an issue where XML imports for l10n_co_dian bills incorrectly defaulted the bill type to '01' when using the Purchase journal. Now, imported bills will retain the original bill type specified during the import process, regardless of the Purchase journal used.
Original PR description
In l10n_co_edi on bills, the field l10n_co_edi_type can only be changed when the journal is DIAN Support Documents and not purchase. However when importing a XML, the field is not imported and is instead always computed to type 01. It should be possible to have imported bills using the Purchase journal and maintain their original type. (Take the xml on the ticket to reproduce the issue) opw-6203930 Forward-Port-Of: odoo/enterprise#118533
This update resolves an issue where a color filter applied to a video background in the website editor would disappear after navigating to another block. The fix ensures the color filter remains consistently applied to video backgrounds, regardless of the selected block, improving the visual consistency of website designs. This enhancement provides a better user experience when using video backgrounds.
Original PR description
The color filter applied to a video background would disappear after selecting the block. Commit [1] fixed this problem, but only when the color filter is a gradient, but it didn't take into account just a plain color. This commit fixes it. Steps to reproduce: 1. Enter Edit mode on the website. 2. Drag and drop a snippet (e.g., "Intro"). 3. Set a video background for the block and apply a color filter with a custom color. 4. Click on another block then click back on the block with the video. -> The color filter is removed. [1]: https://github.com/odoo/odoo/commit/bd105a168df64c35ff09b9e51bcf83868fcfb378 task-6102345 Forward-Port-Of: odoo/odoo#264348