Thursday, April 16, 2026
12 changes · saas-18.4
Resolved issues and error corrections
This fix prevents existing tax group settings from being automatically pointed to newly repurposed accounts during a chart of accounts reload. It helps avoid accounting setup errors and preserves the intended use of existing accounts when tax configuration is refreshed.
Original PR description
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g.…
Upon chart reload, accounts will not be updated (except for tax_ids), but tax groups are. If a tax group was changed to relate to a different account and this account was re-purposed (e.g. account_type changed from an incompatible to a compatible type, the fact that the account is not updated will trigger constraints in the tax group when it is written. IOW, if the purpose of an account is not changed, its use should not be changed either. E.g.: 1f4710deb206736cd71580d8fd95552d9b7c8014 changed the value of `tax_payable_account_id` on tax group `tax_group_cofins_incl_goods` to `account_template_202011005` and the same commit changed the value of `account_type` on `account_template_202011005` from `liability_non_current` to `liability_payable`, triggering `_constrains_payable_receivable_account` (in 19.2: https://github.com/odoo/odoo/blob/e00dd21880c3c4e5c22d65567c700e02541f7259/addons/account/models/account_tax.py#L68). So here, we skip the update of relations to accounts on tax groups, if the account already exists. Forward-Port-Of: odoo/odoo#259160
This fix updates demo data for Peppol and Danish Nemhandel electronic invoicing so it matches recent response handling changes. It prevents errors during demo mode, helping sales, testing, and evaluation workflows run smoothly.
Original PR description
With the recent addition of responses in Peppol and Nemhandel, we forgot to adapt the mocking data for demo flows, which resulted in tracebacks in demo mode. Forward-Port-Of: odoo/odoo#258655
The restaurant point of sale now shows only the floors assigned to the current POS setup. This prevents staff from accidentally seeing or selecting floors from another restaurant area or configuration, reducing confusion during service.
Original PR description
Floors loaded indirectly (e.g. via recursive loading of paid orders) could appear in the floor selector even if they belonged to a different PoS config. The selector was iterating over the full in-memory model store instead of the floors explicitly assigned to the current config. opw-6025172 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#258178 Forward-Port-Of: odoo/odoo#257113
Boolean fields in calendar popovers no longer show an unhelpful tooltip that could display raw HTML when hovered. This keeps the calendar view cleaner and avoids confusing users with technical-looking content.
Original PR description
Before this commit, the tooltip of a boolean field in calendar popover shows html content when the user hovers the boolean field. This commit removes the tooltip of boolean field in calendar popover since the information inside that tooltip is not really useful for the user. Issue found during the development of task-5994205 Forward-Port-Of: odoo/odoo#259069 Forward-Port-Of: odoo/odoo#259011
This fixes an issue where editors could not add content by clicking a snippet group on Forum help pages. The editor now falls back to available page areas when no preferred drop zones exist, keeping website editing usable in this scenario.
Original PR description
Steps to reproduce the issue: - Go to Forum, then go to the Help page - Enter Edit mode - Try to drag and drop a snippet => The dropzone in the s_cover at the top of the page are available - Try to click on a snippet group => Nothing happen, because all dropzones are filtered The s_cover element has the [data-snippet] attribute. When clicking on a snippet group, the editor filters out dropzones inside other snippets. Since s_cover is treated as a snippet, its dropzones are excluded, even though they are the only ones available on the page. The solution is to treat dropzones inside snippets as low priority instead of strictly forbidden. If no other valid dropzones exist, we allow these as a fallback to ensure snippet insertion remains possible. task-5938138 Forward-Port-Of: odoo/odoo#257527 Forward-Port-Of: odoo/odoo#256078
This fixes website snippet images that could disappear on pages with longer URLs, such as product pages. The change ensures those images always load from the correct website location, improving visual consistency for visitors.
Original PR description
This commit fixes two missing leading slashes in the "src" attribute of two "img" tags in `s_cta_mockups`. The browser resolves links differently based on leading slashes. Before this commit, the lack of leading slahses caused the snippet to not display properly on deeper pages (for example, "/shop/product-name"). task-6103616 Forward-Port-Of: odoo/odoo#258879
Draft delivery orders now correctly show products as available when current stock exactly covers the requested quantity. This prevents users from seeing a false red warning when there is enough inventory to fulfill the move.
Original PR description
Steps to reproduce: - Create a storable product "P1" - Update on-hand quantity to 2 units - Create a delivery with 2 units of P1 and keep it in draft state Problem: The forecast availability is…
Steps to reproduce: - Create a storable product "P1" - Update on-hand quantity to 2 units - Create a delivery with 2 units of P1 and keep it in draft state Problem: The forecast availability is displayed in red (not available), even though the stock is sufficient to fulfill the move. Explication: For draft consuming moves, the forecast availability is computed as: `virtual_available - move.product_qty` In the case where stock exactly matches the demand, this results in 0. However, on the JS side, availability is evaluated with: `forecast_availability >= product_qty` So with forecast_availability = 0 and product_qty = 2, the condition evaluates to False, incorrectly marking the move as not available. https://github.com/odoo/odoo/blob/c7fede7f44c668ccc0a094d8341c3cae8879a7f1/addons/stock/static/src/widgets/forecast_widget.js#L31 Solution: When the available quantity is sufficient to cover the move (using float_compare), set forecast_availability to the full available quantity instead of subtracting the move quantity. This ensures the JS condition correctly evaluates to True and the move is marked as available. opw-5159142 Forward-Port-Of: odoo/odoo#257670 Forward-Port-Of: odoo/odoo#257354
This update resolves a technical problem within the AI composer patch that was causing crashes. The fix ensures the focus event is correctly passed to the base handler, maintaining stability and preventing errors when the AI composer is used. This improves the overall reliability of the AI composer functionality.
Original PR description
**Purpose of this PR:** The AI composer patch overrides `Composer.onFocusin()` but did not forward the focus event to the base handler. This used to be harmless while the base mail composer focus handler did not use the event. Since odoo/odoo#258974, the mail composer now uses the event to stop `focusin` propagation, so dropping it makes the base handler crash when AI composer focus is triggered. This commit fixes the AI composer patch by forwarding the focus event to the base handler, preserving the expected handler contract. Related: odoo/odoo#258974 Task-5954657 Forward-Port-Of: odoo/enterprise#113763
This update ensures that transaction data pulled from iap uses the correct date range. Previously, incorrect date ranges could occur, leading to inaccurate reporting. This fix now uses the latest statement or statement line date, guaranteeing accurate data retrieval.
Original PR description
To fetch transactions from iap, we have to give a date from. Before this commit, it was possible to have a date from prior the lock date which is not supposed to happen. This commit will do the max between the lock date the last date of either the statement or the statement line. task-6019584 Forward-Port-Of: odoo/enterprise#110010
This update resolves an issue preventing users from generating session reports in the CO company setting. The fix corrects a technical error related to accessing sale details, ensuring the report generation process now functions correctly. This improves the usability of the POS system for CO company users.
Original PR description
Currently when trying to generate the session report a traceback appears. Steps to reproduce: ------------------- * Install l10n_co_edi_pos * Switch to CO company * Open pos session * Make a sale * Close register * Generate session report > Traceback Why the fix: ------------ We get the sale details with: https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L429-L430 Where the config ids given to `get_sale_details` are given here https://github.com/odoo/odoo/blob/0ce5baf2918960591284eb494d82dfef07043af0/addons/point_of_sale/models/report_sale_details.py#L413-L414 From there we can't access any field from a list of number. opw-6049484 Forward-Port-Of: odoo/enterprise#111627
This update fixes a potential issue where the year for payroll reports was defaulting to the current year, causing test failures. The change ensures the correct year is always referenced, preventing future errors and maintaining accurate reporting. This improves the reliability of payroll calculations.
Original PR description
Making sure we set the reference year when exporting the sd_worx report as if not stated it will call the current year and this will cause the test failing in future builds runbot-242148 Forward-Port-Of: odoo/enterprise#112325
This update resolves an issue where POS users with limited access rights were unable to fully close their Fiskaly VAT resolution sessions, requiring administrator privileges. The fix simplifies the process by removing unnecessary checks for API credentials, ensuring a smoother user experience for POS users handling Fiskaly transactions. This improves the reliability of the POS system for German customers using Fiskaly.
Original PR description
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager)…
In German location with Fiskaly setup. POS users hit an AccessError on read when closing the session from the frontend, then had to finish closing in the backend with admin (base.group_erp_manager) rights. Steps to reproduce: ------------------- * Enable Germany + Fiskaly POS (l10n_de_pos_cert), with a company registered for Fiskaly * Use a user with POS rights only (no Access Rights) * Open POS, sell, then close the session from the POS UI > Observation: A warning redirects to the back end; manual close shows: insufficient rights to read l10n_de_fiskaly_api_secret on res.company (operation read). Why the fix: ------------ The guard only needs to know whether the company is in the Germany + Fiskaly flow; that is already expressed by l10n_de_is_germany_and_fiskaly(), without reading API credentials. Fiskaly RPC helpers on res.company continue to use sudo() where secrets are required; this change fixes unnecessary reads of protected fields in the tax helper, not the security model of the credentials themselves. opw-6074960 Forward-Port-Of: odoo/enterprise#112618