Friday, April 3, 2026
50 changes · master
Resolved issues and error corrections
This fixes PDF attachment handling so files are recognized even when their MIME type includes extra parameters. It prevents valid PDFs from being incorrectly rejected or mishandled after a stricter previous check.
Original PR description
The structure of a MIME type commonly consists of just two parts: a type and a subtype, separated by a slash (`/`), but optionally it can also contains parameters to provide additional details (`type/subtype;parameter=value`). This commit restores this nuance in the PDF mimetype check that was made stricter in the commit odoo/odoo@b048078971f4f12307740a8b382b762a35983059. Reference: - https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/MIME_types runbot-241165 Forward-Port-Of: odoo/odoo#256804
Creating a toggle list from a heading in the HTML editor now preserves that heading as the toggle title. This keeps document formatting consistent and avoids unexpected style changes for users editing content.
Original PR description
**Current behavior before PR:** If current block is heading and a toggle list is created from powerbox, newly created toggle list has baseContainer as title element, even though the anchor block was heading. **Desired behavior after PR:** This PR ensures that if toggle list is created from heading then title element of toggle list will be same is heading. task-5975804 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251386
The Swedish accounting setup now correctly labels sales of services outside the EU as non-EU and assigns them to the right VAT reporting grid. This helps businesses avoid misclassified VAT reporting for these transactions.
Original PR description
Currently, the tax for "VAT Sale of service outside EU 0%" has the 0% EU RS name and is associated with the se_39 grid. Since it is for outside the EU, it's name should be 0% EX RS and the grid should be se_40 opw-5798152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256659 Forward-Port-Of: odoo/odoo#251750
Searching the chart of accounts by account code now correctly includes archived accounts when the inactive accounts filter is used. This helps accounting users locate archived records reliably without needing workarounds.
Original PR description
# How to reproduce - Go to the chart of account - Archive any record (e.g. Code 101401) - Search with the filters : - Inactive Accounts - Account: 101401 (the code of the record) # The problem The…
# How to reproduce
- Go to the chart of account
- Archive any record (e.g. Code 101401)
- Search with the filters :
- Inactive Accounts
- Account: 101401 (the code of the record)
# The problem
The record that we searched for is not shown
# Cause
The domain for the "Account" filter is the following : https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L147
And this is the domain for "Inactive Accounts":
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L159
This is correct and the search should return what we wanted, but the code's search is overriden by:
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/models/account_account.py#L383-L384
And the search with the `code_store` domain only explicitely looks for accounts that are active, so our "[('active', '=', False)]" is essentialy ignored
This is fixed in 19.1 because this commit (https://github.com/odoo/odoo/commit/de959adf7c806e09864b52fec78d981e66804280) replaced the custom search by a `compute_sql`
# Proposed solution
We change the search with the `code_store` to look for records that are both active and inactive, since the active value will be handled by the parent search
opw-6059404
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#256939
Forward-Port-Of: odoo/odoo#256060Sales orders now calculate the original, pre-discount amount more accurately by using non-rounded amounts and ignoring discount lines. This helps customers and staff see reliable undiscounted totals, especially when discounts or rounding could previously distort the displayed value.
Original PR description
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#245246
This fixes an issue where Czech-language amounts could not be converted into words because an underlying library used the wrong language code. Czech users can now see monetary amounts written out correctly in documents and workflows that rely on this feature.
Original PR description
The `num2words` library has a bug in the language code they used for Czech (`cz` instead of `cs`). This commit adds a monkey patch to map the correct language code to the existing converter class, allowing the amount in words to work in Czech. The issue was fixed in version 0.5.14 of the library, so this patch can be removed once we use Ubuntu >= 25.10 (Python >= 3.13), that contains the fixed version of the library. [opw-6088697](https://www.odoo.com/odoo/project.task/6088697) Forward-Port-Of: odoo/odoo#257232 Forward-Port-Of: odoo/odoo#257031
This fixes an issue where some website page links that looked vaguely like phone numbers were automatically converted into phone call links. Editors can now link buttons to pages such as /3-14 without the system changing them to a telephone link.
Original PR description
# How to reproduce - Add a new website page with a title that ressembles a phone number (3-14 does the trick even though it does not really look like a phone number) - Go to another page in edit mode…
# How to reproduce
- Add a new website page with a title that ressembles a phone number (3-14 does the trick even though it does not really look like a phone number)
- Go to another page in edit mode
- Select a button
- In the "Enter URL, /page, or #anchor" input, write the url to your page (/3-14)
- Click on Apply
# The problem
Instead of a link to our page, the button has a link with a tel: protocol.
# Cause
When clicking on the Apply button, the `applyDeducedUrl()` function will be run.
https://github.com/odoo/odoo/blob/892b15963625acc89b7ed7b1c6f94392111df6be/addons/html_editor/static/src/main/link/link_popover.js#L294
That function will change the selected url with the URL deduced from `deduceURLfromText()` if any is found. In our case "/3-14" matches the `PHONE_REGEX` pattern so the url is prefixed with the tel: protocol.
https://github.com/odoo/odoo/blob/892b15963625acc89b7ed7b1c6f94392111df6be/addons/html_editor/static/src/main/link/utils.js#L71
https://github.com/odoo/odoo/blob/892b15963625acc89b7ed7b1c6f94392111df6be/addons/html_editor/static/src/main/link/utils.js#L34
That regex is a bit too permissive and allows our "/3-14" to be matched even though it starts with "/".
Side note : cases like "( )", "...", "--)" are also a match, which is not really an issue because they do not really represent anyting but it shows that the regex is not strict enough.
# Proposed solutin
We edit the regex to make it so it only matches strings that have atleast a digit and where the first character (after "+") is a digit or "("
opw-6047571
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#255877This update makes automated Point of Sale test flows more precise so they behave consistently. It helps reduce random test failures, improving confidence when changes are made to the Point of Sale area.
Original PR description
Fix undeterministic tours by making some triggers more precise in a few steps. 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
The Kanban card menu will no longer appear when users are viewing records in read-only contexts, such as selection dialogs. This removes confusing extra dots that could open an empty or unusable menu, making the interface cleaner and easier to understand.
Original PR description
**Purpose** Currently, the Kanban record menu (the ellipsis dropdown) is displayed even when the Kanban view is in read-only mode. This occurs frequently in `SelectCreateDialog` or when specific conditions on the menu items result in an empty dropdown. This leads to a poor UX where users see "extra dots" that either do nothing or show actions that are restricted in the current context. **Specification** - Modified `KanbanRecordMenu` to check for `props.readonly`. - The menu will now only be rendered if `showMenu` is true AND the view is not in readonly mode. - This ensures that in selection dialogs or read-only kanban views, the unnecessary UI element is removed. **Task-6026033**
VAT validation error messages now use the correct local tax label for each country instead of showing the generic term "VAT". This makes errors clearer for users working with country-specific tax identifiers and reduces confusion during partner setup or validation.
Original PR description
Before this **PR**, instead of the VAT label of each country, 'VAT' appeared in the error message. This was due to a mismatch in the matching of country codes. Forward-Port-Of: odoo/odoo#257030
Fixed an issue where creating a task from a template could fail after refreshing the page while navigating project tasks. This improves reliability for users resuming work after a reload and prevents an unexpected error during task creation.
Original PR description
Steps to reproduce: - Open a project - Create a task and convert it into a template - Open another task (task A) - Reload the page - Create a task from the newly created template Refreshing the page causes `loadState` to rebuild the controller stack from the URL to represent the breadcrumb history. In this case, a virtual form controller is injected for the opened task A, due to the lack of context in the URL to reconstruct it fully. When creating the task from the template, a `switchView` to the new task's form view is triggered. However, only the controller for this new form view is fully populated with the relevant metadata, as the preceding ones are virtual (due to the above). This commit ensures that virtual controllers are excluded from the check on the `multiRecord` field, preventing an error since the `view` is undefined for virtual controllers. task-5876607 Forward-Port-Of: odoo/odoo#246346
This update stabilizes an automated test for the HTML editor color selector, which could previously fail unpredictably because of how the toolbar is displayed. It helps keep release validation reliable without changing the user-facing editing experience.
Original PR description
The toolbar is a popover and is therefore affected by [1]. runbot-242071 [1] 54da715 Forward-Port-Of: odoo/odoo#256783
When warehouse staff manually add a product to an existing picking, the new line is now placed after the existing products instead of being inserted in the middle. This keeps delivery and stock operation lines in the expected order, reducing confusion during fulfillment.
Original PR description
Steps to reproduce - Create three storable products: P1, P2 and P3 - Create a sale order with 1 unit of P1 and 1 unit of P2 - Confirm the sale order - Open the generated picking - Manually add 1 unit…
Steps to reproduce - Create three storable products: P1, P2 and P3 - Create a sale order with 1 unit of P1 and 1 unit of P2 - Confirm the sale order - Open the generated picking - Manually add 1 unit of P3 Problem: After adding the new line manually, the sequence becomes: - P1 → P3 → P2 instead of: - P1 → P2 → P3 Explanation The sale order line view uses the "handle" widget on the `sequence` field: https://github.com/odoo/odoo/blob/57132f17bd15b593d16c68732a7cfd01c371ac0c/addons/sale/views/sale_order_views.xml#L381 Because of this, the first line starts with the default value defined in Python (`sequence = 10`), and each new line increments the sequence by 1: - P1 → sequence = 10 - P2 → sequence = 11 When the sale order is confirmed, the `stock moves` are created with the same sequence values (10 and 11): https://github.com/odoo/odoo/blob/b9fefd44cb7b9fe6245797416063df7930e7aca0/addons/sale_stock/models/sale_order_line.py#L250 However, the stock move tree view does NOT use the "handle" widget. As a result, when a new move line is added manually, it always receives the default value (`sequence = 10`) instead of the next logical value (12). https://github.com/odoo/odoo/blob/cb486d7eb6353a66eea2cb3610141b4f3a778791/addons/stock/models/stock_move.py#L27 This causes the new line (P3) to appear between the existing lines instead of being added at the end. opw-6061307
This update corrects a small issue in spreadsheet-related chart components that could prevent the intended data or actions from being referenced properly. It helps keep spreadsheet charts and dashboard chart menus working consistently for users.
Original PR description
This commit adds the missing `this` since a9cef05b2311e6f620cee3fed7cee34b6c6cad79. Task: 5998915 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents the empty editor hint from briefly disappearing and reappearing when users update nearby content, such as a Todo title. It makes the editing experience smoother and avoids distracting visual flicker.
Original PR description
Problem: When the selection is updating, the hint is blinking in the editable. Cause: After 9df2662cc79c2d8277211f7ce0bdb389f783f933, `triggerDebouncedUpdateHints` clears the hint immediately and adds it back using a debounced version of `updateHints` which runs after a few seconds, thus causing this blink. Solution: We only update hint if the selection inside the editable. Steps to reproduce: - Create a new Todo. - Keep the editable empty. - Update the Todo title. - Observe the editable hint blinking. task-6025534 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253846
This fixes an issue where applying formatting such as bold, italic, underline, or strikethrough at an empty cursor position could fail on Safari for iOS. The change ensures newly typed text keeps the selected formatting, improving reliability for users editing content on mobile Apple devices.
Original PR description
Before this commit: when we applying format on collapsed cursor, we create a formatted element with ZWS, and set the cursor before the ZWS After this commit: we set the cursor after the ZWS, cause otherwise safari doesn't update the cursor properly leading to unformatted input task-4243977 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#257161 Forward-Port-Of: odoo/odoo#249253
A broken invoice report configuration in the Chilean localization module has been corrected. This prevents upgrade and release issues caused by an invalid report view, reducing manual database cleanup for teams using the module.
Original PR description
There is a broken xpath in l10n_cl.report_invoice_document When the l10n_cl module is installed, it results in the faulty view being applied to v18 and later versions. This is particularly annoying because some rolling releases fail because a view with invalid locator is found. The view won't be disabled after a rolling release upgrade and many developers will be spared from checking the databases manually. Forward-Port-Of: odoo/odoo#254369 Forward-Port-Of: odoo/odoo#253588
This fixes an issue where tracker numbers entered after a self-order kiosk purchase were not saved correctly on the order. Businesses using table-service kiosks can now reliably see the tracker information in the order details, helping staff identify and manage orders more accurately.
Original PR description
Step to reproduce: - install "pos_self_order" - have a kiosk type pos, with "service at" = "table" - start kiosk and fulfill a order - on confirmation page, add a tracker number for that order. - go to backend and open that order Observation: - check "order name" in "Extra info" page, we do not get tracker number Cause: - After this commit [1], the tracker data is overridden by next if blocks - hence the data is lost. Fix: - fix the condition. [1] https://github.com/odoo/odoo/commit/c3ea329f1dce44c668e4907fa98cb5104ed11741 opw-5975717 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253304
Restarted chatbot conversations no longer carry over messages from the earlier session when creating a ticket or lead. This keeps customer records cleaner and prevents outdated chat history from being included in new follow-ups.
Original PR description
Before this commit: When a chatbot conversation is restarted and the script creates a new ticket/lead, the description also includes messages from the previous session. After this commit: Only the messages sent after the chatbot conversation is restarted are included in the ticket/lead description. Task-5118966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256595 Forward-Port-Of: odoo/odoo#253566
Website popups without buttons or links can now be closed using the Escape key. This improves visitor experience by ensuring popups behave consistently and are easy to dismiss in all configurations.
Original PR description
Steps to reproduce: =================== - Add a Popup snippet to a page - Remove all links/buttons inside the popup - Save and wait for the popup to appear - Press ESC -> Nothing happens. Cause:…
Steps to reproduce:
===================
- Add a Popup snippet to a page
- Remove all links/buttons inside the popup
- Save and wait for the popup to appear
- Press ESC
-> Nothing happens.
Cause:
======
https://github.com/odoo/odoo/blob/a922c31fa7ccd1107b31287ab1f75697fae874f8/addons/website/static/src/snippets/s_popup/000.js#L219-L226 when the popup contains no tabbable elements, `this.el.focus()` was called. `this.el` refers to the `.s_popup` div, not the `.modal` element that Bootstrap monitors for keyboard events. As a result, the ESC keydown event never reached Bootstrap's handler and the modal stayed open.
When focusable elements (links, buttons) were present, `tabableEls[0].focus()` correctly focused an element inside `.modal`, so ESC worked fine in that case.
Solution:
=========
Replace `this.el.focus()` with `this.el.querySelector(".modal").focus()` so focus lands on the `.modal` element allowing Bootstrap's built-in ESC handler to fire correctly in all cases
opw-5891054
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#256922
Forward-Port-Of: odoo/odoo#250050The email marketing onboarding tour now displays the right guidance after a template is chosen and works when users select different themes. This helps new users complete the setup flow without getting stuck or missing instructions.
Original PR description
## [FIX] mass_mailing: fix broken tour This commit fixes issues with the mass_mailing onboarding tour. The resolved issues are: * Tour steps when template is selected not shown: updated the trigger so that they are displayed. * Adapted the tour to handle selecting any theme task-5974184 Forward-Port-Of: odoo/odoo#253033
This fix prevents errors when processing Peppol invoice data where the invoice period field was left empty. It helps ensure electronic invoices can be generated and exchanged reliably without manual correction.
Original PR description
When mapping the Invoice period extra field and updating the xml nodes, if the invoice period was originally empty, it would be initialized to an empty list not a dict which was breaking the mapping. task-6076624 Forward-Port-Of: odoo/odoo#256594
This fixes how activity types are handled on automated server actions so the system uses the intended value instead of inherited behavior. It helps prevent incorrect activity configuration and keeps automated activity setup more reliable.
Original PR description
The field ``ir.actions.server.activity_type_id`` is still a related field with ``_compute_related`` and ``_inverse_related`` even if we specify its compute methods as ``_compute_activity_type_id`` The base field of the field ``ir.actions.server.activity_type_id`` is in the model ``mail.activity.mixin``. It is a non-stored related field. When overriding the field with a customized compute method, we have to explicitly override the ``field.related`` attribute to prevent the orm populates attributes for related fields. Also since the field ``ir.actions.server.activity_type_id`` is stored, it doesn't need a search method. 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#253004
When a public holiday is changed or removed, Odoo now recreates timesheet entries only for time off requests that are valid and approved. This prevents refused or draft requests from incorrectly generating timesheets, keeping records cleaner and more accurate.
Original PR description
…d leaves Description of the issue/feature this PR addresses: When a public holiday is edited or deleted, the timesheet re-creation is erroneously done for *all* leaves, even those which are canceled or still in draft. Steps to Reproduce: 1. Create a Time Off request for a timesheet-creating leave type (i.e. `timesheet_generate = True`) that overlaps with a public holiday. 2. Refuse the Time Off request. 3. Delete the public holiday the request overlaps with. Current behavior before PR: The deletion of the holiday causes timesheet entries to be created, even though it's a refused request. Desired behavior after PR is merged: The deletion or editing of the public holiday only re-creates the timesheets for the leaves that are actually valid and thus need timesheet entries. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255155 Forward-Port-Of: odoo/odoo#250372
A flaky automated test for the HTML editor was corrected so it waits properly when switching between tabs. This helps reduce false failures in Odoo's validation pipeline, making releases and fixes more dependable without changing user-facing behavior.
Original PR description
Since [1], switching between notebook pages is asynchronous. This test did not wait for the switch and dit not identify which button it used to click on either, relying on a simple toggle. When the runbot was slow, the test ended up clicking on the same tab twice, thus never returning to the one with the editor. runbot-241941 runbot-241258 [1]: https://github.com/odoo/odoo/commit/968dd2cd5d11ce9b39fbacfb60c37bc1bfaa1d9e Forward-Port-Of: odoo/odoo#257391 Forward-Port-Of: odoo/odoo#256782
This fixes an issue where the editor toolbar did not appear after selecting text with Cmd+Shift+Arrow on macOS. Mac users can now use standard keyboard shortcuts to select text and access formatting options reliably.
Original PR description
Problem: The toolbar does not open when using Cmd+Shift+Arrow to select text on macOS. Cause: On macOS, when the Cmd key is held down, the `keyup` event is never fired for other keys. The toolbar…
Problem:
The toolbar does not open when using Cmd+Shift+Arrow to select text on macOS.
Cause:
On macOS, when the Cmd key is held down, the `keyup` event is never fired for other keys. The toolbar relies on `keyup` for Arrow keys to re-enable `onSelectionChangeActive` and trigger the toolbar update, so it never opens.
See section ("Issue 3 - keyup event put on hold for other keys"): https://web.archive.org/web/20160304022453/http://bitspushedaround.com/on-a-few-things-you-may-not-know-about-the-hellish-command-key-and-javascript-events/
Solution:
Track when an Arrow key is pressed while Cmd is held (`pendingArrowKey`) and use a `selectionchange` listener as a fallback to re-enable the toolbar. The `selectionchange` event fires reliably on macOS even when `keyup` is suppressed. A `isMouseDown` guard ensures the listener does not interfere with the existing mousedown/mouseup flow.
Steps to reproduce:
1- Type some text
2- Use Cmd+Shift+Arrow (left or right) to select text 3- Observe the toolbar does not appear
task-6013408
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#257377
Forward-Port-Of: odoo/odoo#253293Deleting a custom field that had been used in a website form could crash the system because website content was checked too strictly. This fix makes the check handle website form content correctly, so administrators can manage fields without triggering an error.
Original PR description
Steps to reproduce ================== tl;dr: html fields are parsed as xml - Go to Helpdesk > Tickets > Warranty - Open studio - Add a new text field named "TEST" - Remove it from the view - Exit studio - Go to the website - Click on new - Add a new blogpost - Set a title and save - Click on "Contact & Forms" - Click on the first block - Click on the form - Change the form action to "Create a ticket" - Click on "+ Field" - Change the Type selection to "TEST" - Click on save - Enable debug mode - Go to "Settings / Technical / Database Structure / Fields" - Type x_ in the search bar and press enter - Delete the field => lxml.etree.XMLSyntaxError Cause of the issue ================== When deleting a field, `_check_if_used_in_website_form` is called to prevent the deletion if a field is used in an html field. The html fields were parsed with an xml parser.. opw-5946029 Forward-Port-Of: odoo/odoo#257245 Forward-Port-Of: odoo/odoo#256066
This update adjusts the default behavior for sickness relapse calculations. Due to a change in the maximum sickness period to 56 days, the system now automatically prevents relapse unless explicitly checked. This ensures accurate payroll processing based on the new policy.
Original PR description
Because the sickness period is now 56 days, the heuristic has switched to "mostly always a no," so the relapse checkbox is unchecked by default. Task: 6081595 Forward-Port-Of: odoo/enterprise#112507
This update resolves a bug where the 'Reconcile' button was incorrectly displayed on mobile devices after a bank reconciliation was completed, causing errors. The fix ensures that the button is hidden when a line is fully reconciled, improving the mobile user experience and preventing errors. This change improves the usability of the mobile accounting application.
Original PR description
Currently, when a line is fully reconciled, we display all the moves, name of the reconciliation, and we hide the `Reconcile`, `Set Partner`, ... buttons, has the line is reconciled, we don't need the buttons. But in mobile, we still display the buttons (like `Reconcile`), leading to a traceback when clicking on it. Furthermore, instead of showing the moves name, we show a `[object Object]`. This bug was probably introduced here: https://github.com/odoo/enterprise/pull/101692 task-6058911 Forward-Port-Of: odoo/enterprise#111605
This update resolves a bug where removing an EPD line in the bank rec widget incorrectly removed associated tax lines. Now, only the EPD line and its corresponding tax line are properly removed, ensuring accurate bank reconciliation reporting. This improves data integrity and prevents errors related to tax calculations.
Original PR description
When removing an EPD line in the bank rec widget, if the invoice line added to the statement line contained a tax, the invoice line was removed aswell. Now, only the EPD line and its tax line are removed. no-task Forward-Port-Of: odoo/enterprise#112020 Forward-Port-Of: odoo/enterprise#110514
This update resolves a technical issue in the Odoo Enterprise payroll analytics testing process. The previous test was failing due to relying on non-existent data, which has now been corrected by directly defining the necessary analytic accounts within the test itself. This ensures the tests run reliably and accurately.
Original PR description
The test that was introduced in the following PR (https://github.com/odoo/enterprise/pull/111140), under some circumstances, was causing problems due to some records not being present. Indeed it was bad practice to use records not defined in the test, so we fix it here by defining the analytic accounts and their plan directly in the test instead of searching for them. Runbot Error: 242151 Forward-Port-Of: odoo/enterprise#112134
This update resolves a duplicate shortcut issue within the Assets view in Odoo. Previously, pressing ALT+P triggered a double action. This fix ensures the shortcut functions as intended, improving user experience and efficiency when managing assets.
Original PR description
This PR (https://github.com/odoo/enterprise/pull/109022) fixed the duplicate ALT + P shortcut in the Assets view. A new one was added in 19.2. opw-5948523 Forward-Port-Of: odoo/enterprise#112588
This update resolves an issue where users were incorrectly added as followers of chatter threads, leading to unwanted notifications. The fix ensures the correct user ID is used, preventing this unintended behavior. Additionally, a cron job optimization was implemented to prevent data clearing during processing, ensuring consistent and reliable execution.
Original PR description
The method call that is supposed to subscribe the current user to the closing entry when posting XBLR used the User id as a Contact id. This caused random contacts to be added as followers of the chatter thread and as a result receiving notifications for it. The fix is simply using the id of the User's Contact instead. Also, as discussed with prro on Discord, fixed the cron clearing its dictionary each loop. opw-5886621 Forward-Port-Of: odoo/enterprise#112709 Forward-Port-Of: odoo/enterprise#107843
A bug was causing partner names in approval reports to be cut off when they exceeded a certain length. This update adds a fix to prevent this overflow, ensuring all partner information is displayed correctly in the report. This improves the report's accuracy and usability.
Original PR description
step to reproduce: - install "approval" with demo data - have a partner with name length > 63 - open one of the approvals and change its type to "general approval" - add this partner in contact field - print approval request report Observation: - the partner overflows out of report Fix: - we limit the partner field with `col-9`. For a safe measure i have added `col-9` for `request_owner_id` and `approver_ids` **Before** <img width="1057" height="326" alt="image" src="https://github.com/user-attachments/assets/a8eea789-5cc7-4658-88b5-78751759d043" /> **After** <img width="994" height="330" alt="image" src="https://github.com/user-attachments/assets/bfbc061b-a6e0-4593-a3cc-c85cb81db6e2" /> opw-6005752 Forward-Port-Of: odoo/enterprise#112361 Forward-Port-Of: odoo/enterprise#111130
A bug in a test for creating articles was causing it to fail due to how sequence numbers were calculated, particularly when demo data was enabled. This update dynamically determines the expected sequence number, ensuring consistent test results regardless of demo data presence. This improves test reliability.
Original PR description
In the `test_article_create` test, a new article is created without specifying a parent and sequence number. The test then asserts the sequence number assigned to this article using a constant. When…
In the `test_article_create` test, a new article is created without specifying a parent and sequence number. The test then asserts the sequence number assigned to this article using a constant. When no sequence number is provided, the system automatically assigns one by taking the highest existing sequence among articles with the same parent and incrementing it by 1. When demo data is enabled, additional users are created along with their corresponding onboarding articles. As the onboarding articles does not have any parent, the onboarding article are included in the computation of the sequence number of the new article we create in the test. These extra articles impacts the sequence number of the new article, causing the test assertion to fail. To resolve this, the test computes the expected sequence number dynamically based on the current state of the data. This ensures consistent behavior regardless of whether demo data is present. runbot-error-id~231695 Forward-Port-Of: odoo/enterprise#106326
This update resolves an issue where the billing period wasn't shown for subscription products within product snippets on the website. The fix ensures that subscription product cards accurately display the billing period, matching the display on the main shop page. This improves the user experience and provides clearer product information.
Original PR description
Steps to reproduce: 1) Go to the Website app. 2) Add a product snippet to any page using the editor. 3) See product card of any subscription product. Issue: - The billing period is not displayed for subscription products in the product snippet, unlike on the shop page. Cause: - `temporal_unit_display` is not included in the `combination_info`which is passed in data used by the product snippet. Fix: - Include `temporal_unit_display` in `combination_info`. opw-6070943 Forward-Port-Of: odoo/enterprise#112787 Forward-Port-Of: odoo/enterprise#112171
This update resolves an issue where platform order flow tests would fail when the test environment didn't have active POS printers. The fix prevents a ValueError from occurring and allows the tests to complete successfully, ensuring consistent test results.
Original PR description
When running platform order flow tests, calling `mark_platform_prep_order_as_printed` raises a ValueError because the test environment lacks active POS printers (they are unlinked during setup). This commit patches the method to catch the ValueError and return False, allowing the POS tours to complete successfully without crashing. build_error-241260 Forward-Port-Of: odoo/enterprise#111076
This update resolves issues with inconsistent tour behavior by refining the triggers used to initiate tours. The changes make the tours more reliable and predictable, leading to a smoother user experience. This fix focuses on internal development and testing.
Original PR description
Fix undeterministic tours by making some triggers more precise in a few steps.
This update corrects a display issue in the accounting dashboard where the 'Reconnect Bank' button was incorrectly shown for synchronizations without an expiration date. The change ensures the button only appears when a synchronization has a defined expiration period, improving clarity and usability.
Original PR description
The aim of this commit is fixing the behavior of Reconnect bank button in accounting dashboard. Before this commit, a synchronization without any expiring date will always show the Reconnect bank button in the accounting dashboard because the expiring due days is set to 0 by default. The sync can only be expired or expiring soon if there is an expiring date. opw-6052451 Forward-Port-Of: odoo/enterprise#112195
This update resolves an issue that prevented users from clicking the AI icon within the email composer when working with multiple CRM records. The fix corrects a data parsing error that occurred when handling multiple record selections, preventing a 'TypeError' and ensuring the AI feature functions correctly across all record types.
Original PR description
Currently an exception is generated when the user tries to click the AI icon in the email composer with multiple records. Steps to produce an error: - Install the `crm` module with the demo data - Go…
Currently an exception is generated when the user tries to click the AI icon in the email composer with multiple records. Steps to produce an error: - Install the `crm` module with the demo data - Go to the CRM list view and select multiple records - Click in `Email` from action > click the `AI` icon on the email composer. Error: `TypeError: int() argument must be a string, a bytes-like object or a real ...` This error is generated because when retrieving the `originalRecordId` from the line [1], the code attempts to remove the first and last characters of a string representation of a list. In the single-selection case, the value is "[4]", so slicing off `[` and `]` correctly yields "4". However, when the user selects multiple records, the value becomes "[4, 5]". Slicing the first and last characters in this case produces "4, 5", and passing this string to Number() results in NaN. As a result, `record_id` becomes `None` when calling `create_ai_draft_channel` method, and passing this None value to int() subsequently raises an error. This commit fixes the issue by assigning `recordId` and `recordModel` only when a single record exists. The record IDs are parsed from their string representation using `JSON.parse`, and the first ID is returned when the list contains exactly one element, or false otherwise. sentry-7201070069 Forward-Port-Of: odoo/enterprise#112713 Forward-Port-Of: odoo/enterprise#104873
This update resolves an issue where subscription discounts were causing errors during data import from the Sales module. The change modifies a key method to correctly handle subscription discounts, ensuring smooth data flow and preventing potential disruptions to sales processes. This improves data accuracy and reliability.
Original PR description
This is a test for the related community fix and an override of the **isSaleOrderLineNote** method to add the subscription specific **subscription_discount** lines to be treated as a note when importing it from the Sales module. https://github.com/odoo/odoo/pull/247846 opw-5582448 Forward-Port-Of: odoo/enterprise#112326 Forward-Port-Of: odoo/enterprise#107002
This update resolves a bug where rejected orders were causing duplicate kitchen tickets to be printed. The fix prevents a double-triggering of printing processes, ensuring accurate order management. It improves the reliability of the platform's order fulfillment workflow.
Original PR description
Bug fix: - Prevent duplicate kitchen ticket printing on order rejection. When a user rejects an order, the reject RPC triggers a webhook that calls _fetchPlatformOrder on all devices. This led to deleteOrders being called twice (once by the reject flow, once by the webhook). Fix: claim the print token via mark_platform_prep_order_as_printed in _rejectOrder before sending the reject RPC, so no device gets isReadyToPrint=true from the webhook. - Preparation needs to be sent after PoS accepts the order. ticket-6071740 Forward-Port-Of: odoo/enterprise#112277
This update resolves an issue in Odoo's Web Studio where field visibility settings (based on user groups) were not consistently applied. Previously, toggling the 'Show invisible Elements' checkbox didn't always retain the intended invisible state. This fix ensures that field visibility based on user access is accurately reflected within the Web Studio interface.
Original PR description
Steps to reproduce ================== - Install contacts,web_studio - Login as admin - Go to contacts - Open any record - Open studio - Click on any field - Add the "Role / Portal" group - Toggle the…
Steps to reproduce ================== - Install contacts,web_studio - Login as admin - Go to contacts - Open any record - Open studio - Click on any field - Add the "Role / Portal" group - Toggle the "Show invisible Elements" checkbox - Click on the same field => The field is marked as invisible - Add an invisible condition => The invisible condition is lost (but still applied on the view) Cause of the issue ================== In studio, when fetching the view, the invisible attribute is set to True when the user does not have access to the field (when he is not part of the groups). The goal is to make the field invisible in studio unless the "Show invisible Elements" is toggled. But this causes the actual value of the invisible attribute to be lost. Note that this also applies to the column_invisible attribute. Solution ======== If an invisible/column_invisible attribute is present on the nodes with missing access, we copy the actual value to the `actual_invisible` attribute. We then use that value in the editor, when present. opw-6026971 Forward-Port-Of: odoo/enterprise#112084 Forward-Port-Of: odoo/enterprise#111299
This update resolves a technical issue within the Odoo Enterprise spreadsheet module. Specifically, a missing 'this' keyword was identified and corrected. This ensures the module functions correctly and prevents potential errors without impacting the user experience.
Original PR description
This commit adds the missing `this` since a9cef05b2311e6f620cee3fed7cee34b6c6cad79. Task: 5998915
This update removes the automatic assignment of a VoIP provider to new users. Previously, users were linked to the first provider found, which wasn't ideal for systems with multiple providers. This change ensures a more appropriate 'no provider' default, simplifying setup and avoiding potential issues.
Original PR description
Following this Pull Request, users will not be linked to any VoIP provider by default. Prior to this Pull Request, users were linked to the first `voip.provider` record found. The rationale behind this behavior has been forgotten, but it was likely implemented to spare admins with a single provider from having to assign one. However, for databases with more than one provider, "nothing" is usually the relevant default. See also: [task-6023412](https://www.odoo.com/odoo/project.task/6023412) Forward-Port-Of: odoo/enterprise#111758
This update ensures that when identifying callers during incoming calls, the system now only searches for extensions within the same provider as the person receiving the call. Previously, it could incorrectly identify users from other providers, leading to potential confusion. This change improves accuracy and streamlines the call routing process.
Original PR description
## Context When an incoming call is received, the `get_contact_info` method attempts to identify the caller by resolving the phone number. Among other things, this method searches internal users for an extension matching the phone number. ## Problem In a multi-provider context, this search may return users belonging to a different provider than the callee. However, extensions are only meaningful within the context of their own provider. ## After this commit Extension resolution is now limited to the callee's provider.
This update resolves a technical issue causing excessive memory usage in the account reports module. The fix ensures that report preloading stops when the component is destroyed, preventing a memory buildup that could impact performance. This improves the stability and responsiveness of the account reporting feature.
Original PR description
The preloading of sections would never stop, this is an issue since this would prevent the garbage collector from collecting this big class and all it's objects. We fix this by making sure to stop the reploading when the component is destroyed. It's important to do it this way rather than clearing the timeout as the destruction could happened when the report is loading so the timeout would be unset and a new one would be started. Forward-Port-Of: odoo/enterprise#112810 Forward-Port-Of: odoo/enterprise#112628
This update corrects a bug where the Provident Fund benefit was incorrectly displayed in the Salary Configurator even when it was disabled. The change ensures that PF is hidden when disabled, preventing potential errors and improving the accuracy of salary calculations. This resolves a previous crash risk.
Original PR description
Before: - PF toggle disabled in payroll settings, but “Provident Fund” could still appear in Salary Configurator (Extra Benefits). - Hiding PF from displayed values could make `/salary_package/update_salary` crash with missing `l10n_in_pf_employee_amount`. After: - When `l10n_in_provident_fund` is disabled, PF benefit is filtered out from `_get_benefits_values`. - Empty benefit types are removed, so “Extra Benefits” no longer shows if it only contained PF. - PF initial value is dropped from payload values. - Missing PF value is defaulted to `0.0` in `_get_new_version_values`, preventing update/submit errors. task-6008086 Forward-Port-Of: odoo/enterprise#110275
This update corrects a bug where planning slots were incorrectly created for rental orders, even when the 'Plan Services' feature was disabled. The fix ensures that slots are only generated when 'Plan Services' is active, streamlining the planning process and preventing redundant entries. This improves the efficiency of rental order management.
Original PR description
Steps to reproduce: ------------------- 1. Install `sale_renting_planning`. 2. Create a rental service product with: - "Can be Sold" enabled - "Plan Services" disabled - UoM set to "Units" 3. Create and confirm a rental order with this product. 4. Go to Planning and check for slots related to this order. (no slots at this stage) 5. Update the quantity of the rental order. 6. Check Planning again for slots related to this order. Issue: ------ Planning slots are created after updating the quantity of the sale order, even when "Plan Services" is not enabled. Cause: ------ Slot records are created without checking whether "Plan Services" is enabled, which leads to unwanted planning entries. related commit: 74eef70 Solution: --------- Add a condition to ensure planning slots are created only when "Plan Services" is enabled. opw-6051012 Forward-Port-Of: odoo/enterprise#112355 Forward-Port-Of: odoo/enterprise#112278
This update clarifies the description of the `esg.activity.type` model to explicitly state its use within the ESG reporting framework. Previously, the description was identical to the general `activity.type` model, which could cause confusion. This change ensures clarity and proper tracking of ESG-related activities.
Original PR description
Before this commit, the description of `esg.activity.type` model is the same than the `activity.type` one defined model which could be confusing. This commit updates the description of `esg.activity.type` model to set Activity Type ESG to explicitly mention that model is used in ESG. Forward-Port-Of: odoo/enterprise#112680