Daily updates from Odoo
Wednesday, September 3, 2025
47 changes · saas-18.4
New functionality added to Odoo
Adds support for Taiwan electronic invoicing through ECPay, enabling businesses to send, refund, and print compliant invoices directly from Odoo. This helps Taiwan-based companies streamline invoicing operations and meet local e-invoicing requirements.
Original PR description
This commit adds the module for implementing the ECPay integration for Taiwan's electronic invoicing system task-2663805 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225016 Forward-Port-Of: odoo/odoo#223132
Enhancements to existing features
The demo invoice shown when fetching incoming bills in Peppol demo mode has been replaced with a clearer, more representative example. This helps users better understand what Peppol bill imports look like during demonstrations or testing.
Original PR description
Replace Peppol demo bill that you get when fetching incoming bills in demo peppol mode. Forward-Port-Of: odoo/odoo#225086
Creating records with HTML content now avoids repeating an expensive cleanup step, which can significantly speed up batch operations such as mass mailing. This also reduces memory use during long-running processes, with a small trade-off that reading the same HTML immediately after creation may require an extra database lookup.
Original PR description
Description ----------- When creating records with `vals` for HTML fields, there are two 'sanitization' operations happening: 1) Once in `convert_to_column`, when converting the `vals` for *database*…
Description ----------- When creating records with `vals` for HTML fields, there are two 'sanitization' operations happening: 1) Once in `convert_to_column`, when converting the `vals` for *database* insertion 2) Once post-insert in `convert_to_cache`, when converting the `vals` for insertion in the *cache* for the newly created records. This redundancy has a negative performance impact when creating many records where new HTML fields are set, e.g., mass-mailing, as potentially large HTML documents are parsed and validated, often with external libraries. To address this issue, this commit removes the insertion into *cache* of the HTML values for the newly created records. This removes the overhead of the second sanitization, speeding up the creation, and also helps with overall memory pressure, as we're not inserting large HTML fields into cache. The latter is particularly noticeable for long-running batch creation processes that do *not* commit intermediate results. The downside of this patch is the potential *cache-miss* (and therefore the subsequent *query*) if the HTML field of the newly created records is read. This is unlikely in business code because intrinsically, an HTML field is often just a data 'blob' that has no logical usage. In the rare case where it needs to be read after creation, since the value in the database is already sanitized, re-sanitization is not necessary for insertion in the cache. Given these considerations, the trade-off seems reasonable to make. Benchmark --------- In a scenario for a marketing campaign with 1000 recipients, using a *mid-sized* email template and emulating a typical campaign, the results were: | Method | Before | After | Speed up | |-------------------------------|----------|-----------|----------| | `_process_mass_mailing_queue` | 2.84 min | 1.55 min | 1.8x | | `create` | 2.11 min | 50.23 sec | 2.5x | This represents roughly a *2x* performance improvement in processing an email campaign. * more detailed benchmarks are available in the task's description Reference --------- task-4962646 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224794 Forward-Port-Of: odoo/odoo#223875
The IoT app now includes a test button for the fiscal data module, allowing users to check the blackbox status and see the result immediately in a notification. This helps businesses verify fiscal device connectivity more easily and reduces false connection failures by allowing a slightly longer response time.
Original PR description
This PR adds a "test" button for the fiscal data module in the IoT app. When used it will send a status request to the blackbox and display the result in a notification. It also removes "response_size" supposed to specify how many characters to read in blackbox response which was unused since this PR: https://github.com/odoo/enterprise/pull/87988 task-5055029
Financial reports grouped by account code now also show the matching account name for the current company. This makes consolidated reporting easier to read when multiple accounts from another company are mapped to the same account code.
Original PR description
In the current consolidation, you can make multi-company accounts and assign a code for each company. But a code must be unique inside each company. So it is not designed to map multiple accounts from a second company into one account of a first company. It is actually possible to achieve that effect by not making the accounts of the second company belong to the first company, and still make the code mapping. So you can make several accounts from the second company, map to the same code for the first company. Thus grouping by account codes become interesting for the accounting reports, in order to get a view of that consolidation. In order to make this reporting more clear, the name of the account corresponding to the account code (in the current company) is now shown when grouping by account code. task-4801891 Forward-Port-Of: odoo/enterprise#86403
This update adjusts internal performance test expectations after a backend caching behavior change for HTML content. It helps keep automated checks accurate so teams can continue monitoring Knowledge performance reliably without affecting day-to-day users.
Original PR description
Adapting query count, due to not putting html fields in cache upon creation. task-4962646 Forward-Port-Of: odoo/enterprise#93503 Forward-Port-Of: odoo/enterprise#93171
The Peruvian electronic invoicing setup now shows the updated Estela branding instead of Digiflow in labels, help text, and translations. This keeps customer-facing configuration screens aligned with the provider's current name without changing how invoicing works.
Original PR description
This PR updates the Peruvian electronic invoicing configuration to reflect the recent brand change from Digiflow to Estela (formerly Digiflow). Changes: - Updated help texts and string labels in `res_company.py` - Adjusted references in `account_edi_format.py` - Updated translations in `es.po` This change is purely textual and does not affect logic or behavior. It ensures users see the correct branding across the Peruvian EDI settings. Forward-Port-Of: odoo/enterprise#93649 Forward-Port-Of: odoo/enterprise#85934
Resolved issues and error corrections
This fix prevents subcontracting manufacturing orders from being fully cancelled when a receipt quantity is reduced to zero. Keeping one open order lets users adjust the receipt later without getting stuck or needing manual recovery.
Original PR description
Steps to reproduce:
- Unarchive subcontracting operation type
- Create a storable product P1 with a BoM:
- BoM type: Subcontracting
- Subcontractor: Azure Interior
- Component C1 (route: Resupply Subcontractor on Order)
- Create a purchase order:
- Vendor: Azure Interior
- 10 units of P1
- Confirm the PO → 2 pickings are created:
- Resupply of 10 units of C1
- Receipt of 10 units of P1
- Confirm and validate the resupply of C1
- Components are reserved in the subcontracting MO
- Validate the consumption of 10 units in the receipt
- The MO is updated to 10
- Update the quantity of P1 to 0 in the receipt
Issue:
The manufacturing order is cancelled. As a result, subsequent updates on the receipt cannot recreate MOs.
Fix:
When reducing the receipt quantity, cancel only the extra MOs, but always keep at least one open MO if a subcontracting move is still ongoing.
opw-4792379
Forward-Port-Of: odoo/odoo#223858Event attendees can now download calendar invite files for published sessions without hitting an access error. This fixes reminder links that include session calendar files, ensuring public visitors can add event tracks to their calendars reliably.
Original PR description
[1] introduces email reminders for tracks which include an ics file url. The ics file generation includes the location name, which is not accessible by public users. It is safe to sudo the name by the point you already have access to the track (i.e. it is published and all ir rules were checked) [1]: b7efd90f23833dee85c69434f84f859056650e66 task-5061885 Forward-Port-Of: odoo/odoo#225316
Unbuild operations no longer force costs to match the original manufacturing order when product costs have changed. Any difference is now handled with a corrective accounting entry, keeping inventory valuation and average costs accurate for manufacturers.
Original PR description
**Current behavior:** Since https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3, we valuate an unbuild operation by attempting to match the ensuing OUT layer with the IN…
**Current behavior:** Since https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3, we valuate an unbuild operation by attempting to match the ensuing OUT layer with the IN layer from the original MO. The point being to eliminate a potential valuation imbalance for the manufactured product (might affect cost, etc.). **New behavior** Don't attempt to match an unbuild valuation layer with the original MO valuation layer. If there is some cost difference between build time and unbuild time, make a corrective journal entry for it. **Issue with current behavior** The following sequence: 1. Create Product A with average costing, real-time valuation 2. Create 2 components, avg costing, real-time val 3. Create a BoM for Product A with the components 4. Manufacture 3 units of Product A with different component quantities (can set flexible consumption on BoM) 5. Unbuild the first manufactured unit Results in Product A's cost not matching the expected average cost according to the valuation layers. **Cause of the issue:** Unbuilding the first MO created an out move at the original "build time" cost, but since we've built 2 additional qty, that original cost is not the current average cost- thus the "theoretically current" standard price of the product (sum of layers value divided by remaining qty) is no longer the value we see on the product form. **Fix:** Don't try and match the valuation layers. Aside from issues such as the one described above, it might not actually make functional sense to do so (e.g., FIFO isn't actually adhering to first-in-first-out if we're preferring the original IN layer for an unbuild valuation). Instead we make a journal entry with any excess cost of production (it was actually a solution proposed in the discussion on https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3 in the first place). Additionally, now that we aren't doing this mapping, we can revert the non-test difference of https://github.com/odoo/odoo/commit/3a69456a291da593748475c86e7efc6234019e47, as this commit was fixing an issue introduced by the change which added the mapping. opw-[4877597](https://www.odoo.com/web#id=4877597&view_type=form&model=project.task) Forward-Port-Of: odoo/odoo#222014 Forward-Port-Of: odoo/odoo#221718
Users can now retry deleting a row in related-item lists after cancelling a confirmation prompt. The delete button is briefly disabled only to prevent accidental double clicks, then becomes available again so workflows are not blocked.
Original PR description
PR [1] aimed at fixing a double-click issue with the delete button in x2many lists. In standard views, it works fine. However, there are customizations (e.g. project sub tasks, product attributes...) that add a confirmation step before actually removing the row. If the user cancelled the deletion, clicking on the delete icon of that row afterwards had no effect at all. This commit fixes the issue by re-enabling the button after 500ms, thus only preventing double clicks. [1] https://github.com/odoo/odoo/pull/173481 opw~5019621 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#225174 Forward-Port-Of: odoo/odoo#225072
This fixes an issue where changes typed into a form could be overwritten when background loading finished. Users can now start editing cached forms immediately without losing their input, while unchanged fields still refresh with the latest data.
Original PR description
Before this commit, when opening an already cached form view (i.e. creating or opening a record) would display the cached information. If a user changed a field before the RPC returned, these changes would be lost as the form view would update with the data from the RPC result. Now, the changes made by the user are kept when the RPC returns and only the non-changed fields are updated.
This fix ensures analytic plan hierarchies are processed in the correct order when installing the Project app. It prevents installation failures for customers who have parent and child analytic plans already configured.
Original PR description
When installing the `project` module, `_sync_plan_column(self, model)` is called for all existing analytic plans. The method iterates through `self` in arbitrary order, which means a child plan can…
When installing the `project` module, `_sync_plan_column(self, model)` is called for all existing analytic plans. The method iterates through `self` in arbitrary order, which means a child plan can be processed before its parent. In such a case, the code tries to create a related field pointing to a parent-level column that does not yet exist, leading to errors like: `Field name "x_plan26_id" unknown for related field "x_plan26_id.plan_id"` This happened because `self` was iterated without guaranteeing that parents are processed first. As a result, the related field chain (`.plan_id.parent_id...`) could reference missing intermediate fields. The fix is ordering the recordset by `parent_path`. Steps to reproduce: 1. In Odoo Inspector, search for model `account.analytic.plan`. and go to records. 2. Create a first plan. 3. Create a second plan and set the first plan as its parent. 4. Install the `project` app (triggers `_sync_plan_column`). 5. Observe the crash due to an unknown related field. OPW-5006494 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224509
Italian electronic invoice exports now omit payment details where they should not appear for self-billing documents. Supplier invoice references are also placed in the correct linked-invoice fields, helping businesses stay aligned with Italian tax authority requirements and avoid rejected or incorrect submissions.
Original PR description
1- `<DatiPagamento>` shouldn't be included in autofatture. 2- The supplier's original invoice number and date must be placed in the `<DatiFattureCollegate>`, using `<IdDocumento>` and `<DataDocumento>` fields respectively. Currently `<IdDocumento>` is added to the `<DatiOrdineAcquisto>`. A fix is made to add `<IdDocumento>` and `<DataDocumento>` to `<DatiFattureCollegate>`. references: https://www.agenziaentrate.gov.it/portale/documents/d/guest/guida_compilazione-fe-esterometro-v1-10_aprile_2025 opw-4810326 Forward-Port-Of: odoo/odoo#212989
Linking an employee to an internal user now works even when the employee has a bank account marked for sending money and the user lacks bank access rights. This removes an incorrect permission error and helps HR or administration workflows proceed without unnecessary accounting access.
Original PR description
Steps to reproduce: - Let's consider an employee E with a bank account BA - Let's consider that BA has the option "Send Money" enabled - Let's log to an internal user U without any access right in Bank - Try to link E to any internal user Bug: A user error was raised: You do not have the rights to trust or untrust accounts. opw:4553238 Forward-Port-Of: odoo/odoo#211081 Forward-Port-Of: odoo/odoo#198974
Opening an employee record on mobile and using the gear menu no longer triggers an error. This keeps the HR presence experience stable for mobile users and avoids disruption during employee management tasks.
Original PR description
Opening the Employee form on mobile and tapping the gear icon could crash because `PresenceActionItems` was undefined. Initialize it and guard the template. task-5055564 Forward-Port-Of: odoo/odoo#224942
Fixed an issue where vendor bills created from consolidated inter-company invoices were not connected to the matching purchase orders. This helps users keep bills and purchase records aligned when multiple sales orders are combined into one invoice.
Original PR description
## Issue: In a multi-company setup with Inter-Company Transactions set to Sales Orders and Purchase Orders, after creating two Sales Orders from one company to the other, then generate a Consolidated…
## Issue: In a multi-company setup with Inter-Company Transactions set to Sales Orders and Purchase Orders, after creating two Sales Orders from one company to the other, then generate a Consolidated Invoice for both SO, and import it as Vendor Bill in the client Company, the bill isn't linked to the matching Purchase Order ## Cause: The `invoice_origin` is used to get the references, but it doesn't split causing the purchase's name to search in `_match_purchase_orders()` to be ["P00001, P00002"] instead of ["P00001", "P00002"] https://github.com/odoo/odoo/blob/2718aaa7397e38be0fcd64fe6b5ef5c0be66cfe2/addons/purchase/models/account_invoice.py#L373-L374 ## Steps to reproduce: - Enable Inter-Company Transactions for Sales Orders and Purchase Orders in two Companies - Create and Confirm two Sales Orders from one company to the other one - Create a Consolidated Bill for both S0 - Send the Invoice (Download) - Switch to the second Company - In Purchase, Confirm both RFQ - In Accounting > Vendor > Bills, Upload the downloaded bill - The Smart Button isn't linked to the PO Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4690707) opw-4690707 Forward-Port-Of: odoo/odoo#223398
This fix ensures standalone tests correctly verify that the controlled time mode is active. It helps keep automated testing consistent and reduces the risk of unnoticed timing-related test issues.
Original PR description
Standalone tests don't enter faketime mode. Forward-Port-Of: odoo/odoo#224077
A Spanish point-of-sale validation test was updated so it no longer relies on a fixed order reference from 2025. This keeps automated checks reliable across year changes and date-simulated builds, reducing false build failures without changing user-facing behavior.
Original PR description
The settle account due tour in l10n_es_pos was failing because the order name was hardcoded to "TSJ/2025/00001". This value includes a date-dependent year and sequence number, which vary based on `context_today`. this will ensure that the tour dynamically generates the order name based on the current year, making it correct for faketime builds build_error-230724 <img width="1366" height="768" alt="image" src="https://github.com/user-attachments/assets/2b7d0e04-9cd9-45d9-b5f0-32f39f87dd90" /> Forward-Port-Of: odoo/odoo#222796
The organization chart now loads the correct employee relationships when viewed from user, employee, or public employee forms. This prevents incorrect or missing reporting-line information, improving consistency for HR users viewing employee profiles.
Original PR description
This update ensures that the correct employee and parent IDs are fetched depending on whether the widget is displayed in a `res.users`, `hr.employee` or `hr.employee.public` form. The `onWillStart` was removed since `useRecordObserver` is triggered in `onWillStart`, and both used to have the same logic. task-5039701 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225193 Forward-Port-Of: odoo/odoo#224456
This fix improves how Odoo handles views created with unsupported XML tags. Instead of triggering a low-level error, users now receive a proper validation message, making the issue easier to understand and correct.
Original PR description
When a user tries to save a view with an invalid tag, an error occurs. **Steps to produce:-** 1. Go to Settings > Technical > User Interface > Views. 2. Click on New. 3. Add the view name. In architecture -> add `<template></template>`. 4. Try to save the changes. **Error:-** `ValueError:Wrong value for ir.ui.view.type: 'template'`. **Root cause:-** - The view type in `ir.ui.view` is automatically inferred from the `root tag` of the XML defined in the `arch` field. - In this case, `<template>` becomes the inferred view type, which is not part of the valid selections for the type field in the model `ir.ui.view`. **Solution:-** - Before calling `super().create(vals_list)`, add a validation check to ensure `values['type']` is in the allowed types. If not, raise a ValidationError. sentry-6561028171 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#207219
This update corrects the Spanish Canary Islands tax data to use the field name expected in Odoo 18. It prevents setup or update issues caused by an outdated tax configuration field.
Original PR description
Description of the issue/feature this PR addresses: In version 18 of Canary Islands taxes, the “price_include” field no longer exists. It is now called “price_include_override.” 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#224973 Forward-Port-Of: odoo/odoo#223996
This fixes a crash that could happen when users grouped records by date or date-time custom properties, opened a group, and navigated back. Grouped list views now reopen reliably when date-based properties are involved, improving stability for users working with custom fields.
Original PR description
Steps: - Install a random module with properties (example: crm) - Add a properties to the form view (date or datetime) - Set the field to today - Make sure you have another record with the new properties field unset - Go to list view - Group by -> properties -> year - Open a group which is not False - Via the breadcrumb navigate back to the list view - Traceback When opening_info is set to unfold with datetime properties, web_read_group returns no records, which crashes the web client. To resolve this, we modify the `formatter_property_datetime` to return the date(time) object as a string. This should match the behavior of normal date(time) fields, ensuring the `_open_groups` algorithm can correctly identify and match the appropriate group(s). opw-5016891 Co-authored-by: @ryv-odoo
Corrects the positioning of table menu controls when editing PDF Quote reports in Studio. This prevents the menu button from appearing over the wrong table cell after report layout options are shown or hidden, making report editing more reliable.
Original PR description
Problem: Open "PDF Quote" report in Studio and observe when hovering on the first table cell: the table menu button is always on top of the first cell (with a small offset difference). Cause: In…
Problem: Open "PDF Quote" report in Studio and observe when hovering on the first table cell: the table menu button is always on top of the first cell (with a small offset difference). Cause: In `OverlayPlugin` we get the container on which we later calculate the overlay position during setup. `QWebPlugin` may show/hide elements in reports (CSS `display` controlled by attributes like `data-oe-t-group-active`). The issue: Before commit https://github.com/odoo/odoo/commit/27a85d650dee8345a4ec701bf7456eec07851718 we used to find the scrollable starting from the `iframe`. This always returned the same scrollable outside the `iframe`, even when its content was scrollable. Now, since `QWebPlugin.applyGroupQwebBranching` can change the `iframe` content, the scrollable may differ. Solution: `getScrollContainer` should check the scrollable starting from the `iframe` before `this.editable`. Steps to reproduce: 1. Open "PDF Quote" report in Studio. 2. Hover on the table headers. 3. Observe the menu button is always positioned on top of the first cell. opw-5046779 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Updates the Spanish descriptions for three Argentine IIBB sales perception taxes so they show the full jurisdiction names for San Juan, San Luis, and Santa Fe. This makes tax configuration clearer and more consistent for users working with Argentine accounting localization.
Original PR description
**Description of the issue/feature this PR addresses**: It is needed to ensure that the descriptions for the IIBB perceptions are consistent and correctly reflect the complete name of the…
**Description of the issue/feature this PR addresses**: It is needed to ensure that the descriptions for the IIBB perceptions are consistent and correctly reflect the complete name of the jurisdictions they apply to. **Steps to reproduce**: 1) Go to runbot odoo 18 instance, install l10n_ar module, take position on Argentinean company and activate "Spanish (Latin America)" language. 2) Go to "Accounting / Configuration / Accounting / Taxes", filter by "Sales" Tax Type (type_tax_use) and see that Perc IIBB San Juan, Perc IIBB San Luis and Perc IIBB Santa Fe don`t have the complete description. It is needed to show the complete description. <img width="1825" height="307" alt="image" src="https://github.com/user-attachments/assets/f664e5ec-a4b5-4a8f-bbab-9ba3d824bd2b" /> **Current behavior before PR**: Perc IIBB San Juan, Perc IIBB San Luis and Perc IIBB Santa Fe taxes don`t have the complete description. **Desired behavior after PR is merged**: Perc IIBB San Juan, Perc IIBB San Luis and Perc IIBB Santa Fe taxes have the complete description. <img width="1828" height="425" alt="image" src="https://github.com/user-attachments/assets/dc8ee6dd-23c3-40c1-a973-943971e3cb78" /> **Task Adhoc side**: 53028 **Task latam side**: 1356 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222343 Forward-Port-Of: odoo/odoo#221742
This fix improves the Website editor experience in dark mode by making the font size input and its related badge display with the correct darker styling. Users can now read and distinguish these controls more easily when editing website text.
Original PR description
### Steps to reproduce: **Issue 1:** - Switch the interface to Dark Mode. - Navigate to the website and drag & drop a snippet. - Select any text to open the toolbar. - Observe the font size input…
### Steps to reproduce: **Issue 1:** - Switch the interface to Dark Mode. - Navigate to the website and drag & drop a snippet. - Select any text to open the toolbar. - Observe the font size input field's background color. **Issue 2:** - Enable dark mode - Open the Website module - Drag and drop any text snippet and select the text - Click on font size input in the toolbar and observe badge background color. ### Description of the issue/feature this PR addresses: - The font size input field displayed a white background in Dark Mode. - This occurred because the code used the editor's document for htmlStyle, but in contexts like the website, the element's ownerDocument differs, leading to incorrect style resolution. - The badge shown next to the font size in the dropdown had same background color as the dropdown in dark mode, making it indistinguishable. ### Desired behavior after PR is merged: - Use the correct ownerDocument of the element to access its htmlStyle. - The badge background color is now darker in dark mode. task-5027790 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents missing website link values from being turned into empty links when a CDN is active. It avoids a checkout address page issue where submitting the form could trigger an unwanted refresh and disrupt the order flow.
Original PR description
In QWeb, when using `t-att-href='None'`, the attribute is omitted from the DOM. However, when a CDN is used, `None` is converted to an empty string (`''`) by `get_cdn_url`. This is a follow-up to commit 3e9c953. This fix addresses an issue on the `/shop/address` page where the "Submit" button had `href=''`, causing JavaScript event handling to break due to a race condition triggered by a page refresh during form submission (POST). Forward-Port-Of: odoo/odoo#223252 Forward-Port-Of: odoo/odoo#220166
This fixes a website theme issue where duplicate color palette names could prevent the Theme tab from appearing in the editor. Users can now edit themes such as Anelusia even when a theme reuses a palette name already present in the website module.
Original PR description
This fix prevents duplicate palette names in `t-foreach` by using an object to store palettes by name, which otherwise made theme editing impossible. Steps to reproduce: - Create a website with theme "Anelusia" - Try to change the theme in the editor - The "Theme" tab will not appear This issue occurs because the Anelusia theme from Design-Themes introduces a palette named "default-25", which is already defined in the website module. The same conflict can also arise with other themes. opw-5020952 opw-5040694
This fix restores support for custom rules that let certain users edit only specific website pages, which is important for Odoo.com publishing workflows. A previous change caused those partial editing permissions to stop working in some cases, so the logic was rolled back while the related test is kept disabled for future follow-up.
Original PR description
*: test_website This reverts commit [1]. Indeed, while it fixed the bug as intended while keeping the `_check_user_can_modify` feature, it apparently did not keep that one working in all cases: having partial view edition rights for some website.page (see uses in our Odoo.com customizations). While searching for a solution allowing to keep the fix of [1] and the whole purpose of `_check_user_can_modify`, the logic part of [1] is reverted, keeping the test but disabled. [1]: https://github.com/odoo/odoo/commit/8c41c147a4c6a415e7c5bfdde9297edbf40b4239 Forward-Port-Of: odoo/odoo#225160
Cog menu actions in form, list, and kanban views now use the most current screen context instead of older startup data. This prevents actions from running on outdated record versions, helping users get the expected result after changing options such as an employee version.
Original PR description
In form, list and kanban views, cog menu actions were executed with the context received in props. However, that context may change afterwards, especially with js customizations (js_class, widgets...). As a matter of fact, it is the case in the employee form view, as clicking on the status bar, which represents the versions, adds a key in the context to encode the current version. Before this commit, executing a cog menu action after changing the version of an employee was still executing it on the last version of that employee. With this commit, the correct (up to date) context is correctly given to the action. Needed for task~4997195
This fix makes Indonesian Coretax e-Faktur product codes easier to find when editing product templates. Users can now search by code, description, or the displayed label, reducing lookup friction and selection errors.
Original PR description
Description of the issue/feature this PR addresses: Because `l10n_id_efaktur_coretax.product.code` model does not have a `name` field and does not use` _rec_name`, search record in m2o field or…
Description of the issue/feature this PR addresses: Because `l10n_id_efaktur_coretax.product.code` model does not have a `name` field and does not use` _rec_name`, search record in m2o field or searchview is difficult and not normal. so this uses `_rec_name = "code"` for fixing in searchview, and overrides `_name_search()` to be able to search using field `code` or `description` or like `name_get()` string Current behavior before PR: <img width="821" height="353" alt="Before fixing coretax product code search 1" src="https://github.com/user-attachments/assets/12ca3248-0bea-4ef3-bb04-116d63520517" /> <img width="832" height="432" alt="Before fixing coretax product code search 2" src="https://github.com/user-attachments/assets/ced291b7-c4c6-42e7-a453-7a1f18945637" /> <img width="988" height="568" alt="Before fixing coretax product code search 3" src="https://github.com/user-attachments/assets/bbac4ae1-a31d-49bd-b520-a68a1a945e78" /> Desired behavior after PR is merged: <img width="438" height="314" alt="After fixing coretax product code search 1" src="https://github.com/user-attachments/assets/4469bb5b-0830-49af-af1c-f05b81dcb10c" /> <img width="467" height="331" alt="After fixing coretax product code search 2" src="https://github.com/user-attachments/assets/5528db34-e279-4d2d-98f0-644f7a618ead" /> <img width="991" height="619" alt="After fixing coretax product code search 3" src="https://github.com/user-attachments/assets/fec53a0c-ab29-46c5-b366-46653b51d7e4" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222588 Forward-Port-Of: odoo/odoo#221858
Highlighted text in the website builder now keeps its visual highlight properly aligned when users change a heading or font block type. This prevents design inconsistencies while editing pages and helps content appear as intended.
Original PR description
With the [website builder refactor], the highlight did not resize when user changes the font block type in a parent of a highlighted span. This happens because the parent node is removed to do the…
With the [website builder refactor], the highlight did not resize when user changes the font block type in a parent of a highlighted span. This happens because the parent node is removed to do the replacement of tag, which does not triggers the observers of the interaction. This commit fixes it by removing the optimization that if an element is observed, then it can be ignored during a normalize. Indeed, when a highlight is added on a node, the observers of the interaction do not only track the node itself, but also some other nodes. When the highlighted span is moved between different parents, the set of nodes that should be observed changes (and some observations may have been lost) Steps to reproduce: - Open website builder - Drop a block with a title (for example, "Cover") - Add a highlight inside the title - Change the font (for example from "Header 1" to "Header 5") - Bug: the highlight svg does not resize to follow the highlight span [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-4367641
The Point of Sale tax control button now appears only when relevant settings are enabled, avoiding confusion for cashiers and restaurant staff. The tax selection dialog also now shows a clear title, making it easier for users to understand the action they are taking.
Original PR description
Before this commit: =================== - When only point_of_sale is installed, the tax control button is visible only if `Flexible Tax` is enabled. But with pos_restaurant installed, the button is always visible, even if Flexible Tax is disabled. - Also, the tax selection dialog had an incorrect title: `Please register the voucher number`. After this commit: ================== - In point of sale, the tax control button will be visible if `Flexible Tax` is enabled, and in restaurant mode, the button will be visible if the `Flexible Tax` or `Takeout/Delivery` is enabled. - The tax selection dialog title has been updated to: `Choose the tax you want to apply`. Task: 4937977 Forward-Port-Of: odoo/odoo#224957 Forward-Port-Of: odoo/odoo#218815
The Current Stock button on a warehouse location now shows only stock for that specific location instead of listing all products. This helps inventory users quickly see the relevant stock and avoids confusion when reviewing location details.
Original PR description
From this [commit](https://github.com/odoo/odoo/commit/81acb532a45cf7ab2837634e4d347b216c95f07a), clicking the "Current Stock" button on a location form opened the stock quant list without filtering…
From this [commit](https://github.com/odoo/odoo/commit/81acb532a45cf7ab2837634e4d347b216c95f07a), clicking the "Current Stock" button on a location form opened the stock quant list without filtering by the selected location, showing all products. After this commit, the context `search_default_location_id` is added so that the stock quant list is properly filtered by the active location. **Before fix** <img width="1919" height="951" alt="2025-09-01_12-15" src="https://github.com/user-attachments/assets/93a6034b-0d07-4668-b67d-a84df2285a48" /> **After fix** <img width="1913" height="862" alt="2025-09-01_12-20" src="https://github.com/user-attachments/assets/03eb5b48-0799-4a73-a826-b3c9971b4a85" /> opw-5033643 upg-3117055 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#224923
This fix prevents the hotkey help overlay from accidentally triggering page navigation updates. Users should experience fewer unexpected focus jumps when using keyboard shortcuts, making the interface feel more stable.
Original PR description
This commit fixes an issue where the update of the navigation_hook would trigger for any dom modification (including hotkey overlay) which could cause unwanted re-focus on some elements. Backport of 6939e29b2bf9d943fa82a5969a2472cdc3c81c8a to 18.4 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A failing mobile test in Point of Sale was corrected to restore reliable validation for mobile scenarios. This helps keep the Point of Sale experience stable on mobile devices and reduces the risk of regressions reaching users.
Original PR description
The mobile test was failing due to an issue. opw-5059482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225127
Fixes an issue where refreshing a completed live survey page could crash if a survey question had been deleted in another tab. This keeps the survey experience stable for participants and avoids an error page in this edge case.
Original PR description
Currently, an error occurs when refreshing a live session's `Thank You` page after deleting a survey question. **Steps to reproduce:** - Install the `survey` module. - Create a `new survey`, `add a…
Currently, an error occurs when refreshing a live session's `Thank You` page after deleting a survey question. **Steps to reproduce:** - Install the `survey` module. - Create a `new survey`, `add a question` and click on `Create Live Session`. - Complete the survey and leave it on the `Thank You` page. - Switch back to the `first tab`, delete the question and `save` the survey. - Return to the `Thank You` tab and `refresh` the page. **Error:** `IndexError: list index out of range` **Root Cause:** At [1], the controller assumes the question exists and tries to access `index [0]`, but when the question has been deleted, the recordset is empty, causing an `error`. [1] https://github.com/odoo/odoo/blob/ffd9c0f96bda1bad1ad2059d9be2fae54b60eace/addons/survey/controllers/survey_session_manage.py#L236 This commit prevents a crash when refreshing a live session if the question was deleted. sentry-6736648824 Forward-Port-Of: odoo/odoo#225242 Forward-Port-Of: odoo/odoo#218312
Tax lookup now works with partial or approximate names instead of requiring an exact match. This helps users find the right tax faster, such as matching entries like "21% S" when typing a shorter shortcut like "21s".
Original PR description
Issue: - Searching for a tax by its name is not flexible. - Users have to type the exact name of a tax to find it. Fix: - Allow using the shortcut feature with both `name` and `display_name`. The field `name_searchable` is deprecated as it can be implemented without that field now. Impact: - Improves user experience by allowing tax searches using partial or approximate name inputs. - For example, typing '21s' will return all relevant results like '21% S' and similar matches. Task: 5046098 Forward-Port-Of: odoo/odoo#224618
This fix prevents settings pages from showing an error when a header is intentionally left without a label. It makes the settings interface more reliable for configurations where a label is optional.
Original PR description
Before this commit, an error would occur if a header setting did not contain an attribute string or field. This was because the code tried to infer the label. However, the label should be optional. 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#225119 Forward-Port-Of: odoo/odoo#225080
Users can once again swipe left to unpin conversations from the messaging menu on mobile. This restores the expected mobile interaction and avoids frustration when managing pinned threads.
Original PR description
Before this commit, swiping left to unpin threads in the messaging menu was not working. This issue was introduced by [1] (which is a backport of [2]), and it stems from trying to acccess the message_unread_counter on the thread instead of the self channel member. This commit fixes the issue by accessing the property correctly from the self channel member. [1] https://github.com/odoo/odoo/pull/212793 [2] https://github.com/odoo/odoo/pull/212793 task-5058496 Forward-Port-Of: odoo/odoo#225083
Saving the document layout wizard no longer tries to update a company's bank account number when it has not been changed. This prevents unnecessary errors for trusted bank accounts while keeping the displayed bank account field available.
Original PR description
Description of the issue/feature this PR addresses: The document layout wizard (base.document.layout) attempts to write the partner’s bank account number even if it has not been changed. If the first…
Description of the issue/feature this PR addresses: The document layout wizard (base.document.layout) attempts to write the partner’s bank account number even if it has not been changed. If the first bank account is marked as trusted, Odoo blocks the write and raises an error. This PR prevents that error by only writing the account number when it has actually changed. Current behavior before PR: - The wizard shows the account_number field. - On saving, _inverse_account_number always writes to the first partner bank account. - Trusted bank accounts trigger an error: “You cannot change the account number or partner of a trusted bank account.” Desired behavior after PR is merged: - The wizard still shows the account_number field. - On saving, _inverse_account_number only writes if the value changed. - Trusted bank accounts that are not modified do not cause an error. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#224905
The signature dialog now avoids showing drawn and auto-generated signatures on top of each other. This makes signing documents clearer for users and prevents confusion when choosing or drawing a signature.
Original PR description
Fixed an issue where both the auto-generated and drawn signatures overlapped in the signature dialog. This was caused by the system automatically setting the user's default signature to the drawn one when opening the dialog. Now, the dialog no longer defaults to the drawn signature, preventing visual overlap and ensuring a cleaner user experience. Forward-Port-Of: odoo/enterprise#93750
This fix ensures available rental planning time slots are no longer accidentally overwritten while being prepared. Customers and staff should see more reliable slot availability when booking rental products online.
This fix ensures the website generator stops its background checks reliably when users leave or the page flow is cancelled. It prevents repeated hidden requests that could cause crashes and improves stability during website creation.
Original PR description
In a component lifecycle, it may happen that onWillStart is called but not onWillUnmount. Indeed, if the component is destroyed before being mounted (because the current rendering has been cancelled), onWillUnmount isn't called. As a consequence, in the WebsiteGenerator component, the setInverval might never been called, thus producing an orm call every 10 seconds, when the component is destroyed. These calls lead to crashes ("Component is destroyed").
The solution is to use the onWillDestroy hook instead, which is always called.
Forward-Port-Of: odoo/enterprise#93679Commission reports now use the correct database access mode when preparing report data. This avoids warnings or errors when reports need temporary data during display, improving reliability for sales commission users.
Original PR description
Since https://github.com/odoo/enterprise/pull/88646 a temporary table is created to speed up computation of commission report. As dislayng the report is creating and dropping the temporary table, it is not compatible anymore with a read only cursor. This commit ensure that a read write cursor is used to prevent warning and errors. task-4982555 Forward-Port-Of: odoo/enterprise#91352
The Malaysia Statement of Account PDF now applies the proper currency conversion when invoices use a currency different from the company's main currency. This prevents customer balances from showing the right currency symbol with an unconverted amount, improving accuracy in financial reporting.
Original PR description
## Short functional explanation of the error When we create an invoice with a different currency than the main one, the Statement of Account PDF report in aged receivable has an error. The amount for…
## Short functional explanation of the error When we create an invoice with a different currency than the main one, the Statement of Account PDF report in aged receivable has an error. The amount for each line is displayed as the main currency, but the conversion isn't done. For instance, if we create an invoice line of 3.5$ but our main currency is the Euro, in the report, it will show 3.5€ instead of 2.99€ ## Reproduction Steps 1. In a db without demo data, Download the app l10n_my. 2. In the general settings, click on Currencies. Activate a second currency and set its currency rate (relative to the main currency of the company) different of 1. 3. In accounting > settings, click on -> Currencies. Activate this second currency. 4. Click on configuration > journals and activate the debug mode. In the Journal Entries tab, as Currency, select a different currency than your main one (set in the general settings). 5. Create an invoice. Set a customer and select the journal for which you set an additional currency. Select this additional currency. Finally, add a product and click confirm. 6. Click on Reporting > Aged Receivable. Then, click on the line corresponding to your partner on Statement of Account. A PDF should download. ### Expected behavior The lines under Balance should be displayed as the main currency of the company, with the correct currency rates applying. ### Unexpected behavior The lines under Balance are displayed as the main currency of the company but the currency rates are not applying. ## Origin of the issue In the code, the currency rate isn't used to generate this line of the report: https://github.com/odoo/enterprise/blob/79c1ba68d48e7e068104d867e186610dd5110cc4/l10n_my_reports/report/statement_account_templates.xml#L52 __ opw-4975540 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#93096
Restaurant table bookings linked to appointment resources are now loaded correctly in the Point of Sale when restaurant mode is enabled. This helps staff see relevant reservations on the floor plan and improves reliability of appointment labels in related tests.
Original PR description
Issue: The calendar envents that have a restaurant table ressource are not loaded in the pos if the config is in restaurant mode. Fix: If the config is a restaurant the calendar_event pos domain will return a domain containing the appointment_ressources linked to the config restaurant tables. This commit also fixes the test that checks for the appointment-label on the floor plan. Task-id: 4970986 Forward-Port-Of: odoo/enterprise#90809