Tuesday, June 2, 2026
43 changes · 19.0
Resolved issues and error corrections
This update stabilizes an automated test for Odoo's web interface by ensuring a delayed autocomplete lookup is consistently completed and checked. It reduces intermittent test failures, helping maintain confidence in the release process without changing user-facing functionality.
Original PR description
This test was sometimes failing, when the debounce delay (250ms) of the autocomplete ended before the end of the test, resulting in an unexepected "web_name_search" step. With this commit, we run all timers, thus ensuring the web_name_search to be always done, and we assert it. runbot error~937794 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Project app's template dropdown now displays with proper spacing for demo and onboarding users. This makes template choices easier to read and avoids showing an empty manager-only control to users who cannot use it.
Original PR description
Steps to reproduce: == - Login as demo/onboarding user - Open Project app - Click on New - Observe the template dropdown list Issue: == The template dropdown items are rendered with collapsed row height and poor vertical spacing in demo mode, making the list hard to read. Cause: == The template dropdown items utilized the `pe-0` utility class, which removed the padding at the end of the element. For non-admin users this caused the template name to touch the right edge of the container. Fix: == Removed the `pe-0` from the `DropdownItem` to restore standard right-side padding, and ensure consistent and readable row heights for both Admin and Demo users. task-5338191
The Work in Progress report now leaves product and reference fields blank when no real values were entered, instead of showing demo laptop data. Demo values remain available only in the report editor preview, reducing confusion for users reviewing project-based analytic items.
Original PR description
Currently, when printing the WIP report, demo data is displayed if no product or references are provided on the analytic item. ## Steps to produce: - Install Manufacturing and Accounting - Go to…
Currently, when printing the WIP report, demo data is displayed if no product or references are provided on the analytic item. ## Steps to produce: - Install Manufacturing and Accounting - Go to settings and Enable Analytic Accounting - Search Analytic items and create a new Analytic Item by providing a description and amount. - Gear Icon > print and open the WIP report ## Observed Behavior: The report displays a product (laptop) with a demo reference. This becomes problematic when an analytic item is tracked only with a project, as it still causes product and reference data to appear on the analytic item. This can mislead the user. ## Root cause: After this [commit](https://github.com/odoo/odoo/commit/967ac550e38bab915180647dea6eccb2ae1b3b31), demo data values were added to the report to support report editor previews in the web studio. This helps users understand how the report will look while they are editing it. However, although an account analytic line is defined at [1], no values for fields such as products and references are specified on the form. As a result, the template falls back to the preview values provided. [1]- https://github.com/odoo/odoo/blob/d66bb0d7b550b11876dbc7b9d87f5b2adc17dd74/addons/mrp_account/report/report_mrp_templates.xml#L32-L53 ## Solution: Using `data-oe-demo` instead of removing the fallback data appears to be the best approach, as it allows the report editor to continue using demo values for the report preview, as shown at [2] **Before:** <img width="871" height="340" alt="image" src="https://github.com/user-attachments/assets/91897dbd-65d8-4f70-8f22-ea38b42ba28d" /> **After:** <img width="815" height="380" alt="image" src="https://github.com/user-attachments/assets/ffcf509b-f534-47a8-be1d-53a798995443" /> [2]: https://github.com/odoo/enterprise/blob/a739c6c03c6629bad80f3fe61b1035ce156d59c6/web_studio/static/src/client_action/report_editor/report_iframe.scss#L65-L75 opw-6151563 Forward-Port-Of: odoo/odoo#262517
This update fixes an internal test for link tracking so it checks exact short link codes instead of partial matches that can overlap. It helps keep automated testing reliable without changing customer-facing behavior.
Original PR description
Problem ------ The test was trying to search for links that has specific code patterns in their short_url and distinguish links using this logic. However, it did not consider the case where the same code pattern might exist in two different urls. i.e `example/r/AbC` and `example/r/DbE` both contains `b`, so when searching for `b`, both urls will be returned. FIX ------ Testing the search on different code combinations for the short_url is not the subject of that unit test, it is sufficient to search for the exact codes and see if there are conflicting results. task-6254039 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266709
When a user starts uploading a file through the link popover and then cancels, the upload is now stopped immediately. This prevents unwanted links from appearing later and avoids unnecessary background activity.
Original PR description
**Current behavior before PR:** Steps to reproduce the issue: - Go to Todo, In the network tab switch to "Slow 4G" so that file upload can take few seconds to upload. - Upload a file using link popover. - While the file upload is in progress, hit the discard button of the link popover. - Notice that the upload continues in the background and when it completes successfully, link is inserted. **Desired behavior after PR is merged:** Discarding the link popover during file upload should cancel the upload request and prevent inserting the link. task-6199113 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263463
This fixes an editor issue where bold, italic, or underline formatting could not be removed when the selected text included inline code. Users can now reliably toggle formatting on and off in notes and other HTML editor content, avoiding confusing editing behavior.
Original PR description
Problem: When selecting text containing `o_inline_code` and applying formatting such as bold, italic, or underline, the formatting cannot be removed. Cause: When applying formatting, nodes matching…
Problem: When selecting text containing `o_inline_code` and applying formatting such as bold, italic, or underline, the formatting cannot be removed. Cause: When applying formatting, nodes matching `is_formattable_node_predicates` are ignored. However, when checking whether the selection is already formatted, those nodes are not ignored, so the selection is erroneously considered to be only partially formatted. Solution: Take `is_formattable_node_predicates` into account when checking whether a selection is formatted. Steps to reproduce: - Go to To-Do → Create New. - Type some text and add inline code on the same line. - Select all content using Ctrl + A. - Apply formatting such as bold, italic, or underline using keyboard shortcuts (Ctrl + B / Ctrl + I / Ctrl + U). - Press the same shortcut again to remove the formatting. - Observe that the formatting is not removed. task-6229228 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267174 Forward-Port-Of: odoo/odoo#265183
The editor now refreshes an existing table of contents even when a heading is merged back into regular text. This prevents outdated table of contents entries from remaining visible after users edit their document structure.
Original PR description
Steps to Reproduce : - Go to To-Do → Create New and add a Table of Content block - Type text → in new line create /h1 → it appears in ToC - Place cursor before /h1 and press Backspace → it merges with paragraph Description of the issue: Table of Content block does not update accordingly Cause: After the heading is merged with the previous paragraph, `delayedUpdateTableOfContents` is triggered, but at that time no heading is available in the editable area. As a result, instead of updating the Table of Contents, it returns without making any changes. Solution: If Table of content already contains heading, then update regardless of whether editable contains heading elements or not. task-6150579 Forward-Port-Of: odoo/odoo#264161 Forward-Port-Of: odoo/odoo#261675
Project update cards now show the intended status colors in the Kanban view. This makes project statuses easier to recognize at a glance and avoids confusing missing or incorrect color indicators.
Original PR description
### The Issue: The frontend Kanban view enforces a strict 12-color limit using a modulo 12 mathematical rule (which calculates the remainder after dividing by 12). When the frontend receives our high backend IDs (20-24), it runs this modulo math (e.g., 23 % 12) to force them into the allowed limit, converting them into the remainders: IDs 8, 9, 10, 11 and 0. Because stylesheet was still searching for the original high numbers (20-24) instead of these modulo results, the custom colors were completely ignored by the browser. ### The Fix: Updated the stylesheet to target the actual modulo-computed classes (.oe_kanban_color_8 through 11 and 0). Mapped these classes to their correct variables (-success, -info, -warning, -danger, -primary) and fixed the left border styling so the colors render properly. task-6064106 Forward-Port-Of: odoo/odoo#266693 Forward-Port-Of: odoo/odoo#256023
This fix ensures users can select a single table cell in the HTML editor even after applying formatting such as bold or italic to the text inside it. It removes a frustrating editing issue and helps toolbar formatting and table interactions behave consistently.
Original PR description
### Steps to reproduce: - create a table (e.g. /table) - type something in any cell and select that cell. - apply formatting through toolbar (bold, italic, etc.) - now select that single cell through…
### Steps to reproduce: - create a table (e.g. /table) - type something in any cell and select that cell. - apply formatting through toolbar (bold, italic, etc.) - now select that single cell through mouse. - observe that it is not selected ### Description of the issue/feature this PR addresses: - The single-cell selection logic relied on getTargetedNodes(), which collects descendants of the selection’s common ancestor. When selecting text inside inline formatting tag (e.g. `<i>`), the text node became the common ancestor, so the parent `<i>` tag was excluded from selectedNodes. As a result, check ensuring all cell elements were selected failed, preventing from being selected. ### Desired behavior after PR is merged: - Cell selection was simplified using areNodeContentsFullySelected(startTd) directly instead of manually matching targeted descendants. This relies on DOM Range to verify whether the cell boundaries are fully selected. task-6207941 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263742
Portal users now see invoices sorted by their actual payment status when choosing Status sorting. This makes invoice lists easier to review and prevents confusion from ordering by internal invoice workflow states instead.
Original PR description
Steps to produce: --- - Install the `Accounting` module. - Create several invoices for a portal user with different payment states (e.g., In Payment, Not Paid, Paid). - Log in as the portal user. -…
Steps to produce: --- - Install the `Accounting` module. - Create several invoices for a portal user with different payment states (e.g., In Payment, Not Paid, Paid). - Log in as the portal user. - Navigate to the invoices list and attempt to sort by **Status**. Issue:- --- - Sorting by **Status** does not reflect the actual invoice payment status, resulting in incorrect ordering. Root cause: --- - At [1], the sorting field for Status is set to state, which corresponds to invoice states (Draft, Posted, Cancelled). However, the portal displays and expects sorting based on payment_state. Fix: --- - Update the sorting configuration to use payment_state instead of state, ensuring that invoices are sorted correctly according to their payment status on the portal. [1]https://github.com/odoo/odoo/blob/5b85287ec4ea9f1b51e0f33402900777dfeeb725/addons/account/controllers/portal.py#L46-L52 opw-6128998 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#262976
Spanish VeriFactu invoice sending now handles incorrectly configured sequence prefixes or suffixes without crashing. Users see a clear message explaining that alphabetic prefixes or suffixes must be removed, helping them fix the setup and continue processing invoices.
Original PR description
**Steps to reproduce:** 1. Install l10n_es_edi_verifactu. 2. Switch to a ES company. 3. Create a customer invoice and send it to VeriFactu. 4. Enable Developer Mode. 5. Go to Settings > Technical >…
**Steps to reproduce:** 1. Install l10n_es_edi_verifactu. 2. Switch to a ES company. 3. Create a customer invoice and send it to VeriFactu. 4. Enable Developer Mode. 5. Go to Settings > Technical > Sequences & Identifiers > Sequences. 6. Search for the `Sequence Code: l10n_es_edi_verifactu` and open it. 7. Set a prefix or suffix using any alphabetical character. 8. Create a new invoice and send it to VeriFactu **Issue:** Traceback on sending Veri*Factu: `ValueError: invalid literal for int() with base 10: 'F260001'` **Cause:** The value returned by `ir.sequence.next_by_id()` may contain alphabetical characters (due to prefix/suffix), while the field `chain_index` expects an integer. The raw sequence value was directly assigned, causing the conversion to fail. **Fix:** Catch the ValueError raised by int() when the sequence value contains non-numeric characters (e.g. due to a prefix/suffix). Instead of crashing, surface a user-friendly error on the document telling the user to remove the prefix/suffix from the sequence configuration. **opw-6037528** Forward-Port-Of: odoo/odoo#255473
Website search results now show the same product label used elsewhere in the shop, including internal references when enabled. This makes autocomplete and search result pages clearer and more consistent for shoppers and sales teams.
Original PR description
**Description of the issue/feature this PR addresses:** In `product.template._search_get_detail`, the `name` mapping used to render the search result title points to the raw `name` field. The shop…
**Description of the issue/feature this PR addresses:** In `product.template._search_get_detail`, the `name` mapping used to render the search result title points to the raw `name` field. The shop grid and the product page instead use `display_name`, which includes the internal reference (`[default_code] Name`) when `display_default_code` is enabled. This makes the website search (autocomplete + /website/search) the only place that hides the product reference, even though it is already searched (`search_fields` contains `default_code` and `variants_default_code`). #### Change - `fetch_fields`: add `display_name`. - `mapping['name']`: render `display_name` instead of `name`. **Current behavior before PR:** On a category/shop with products that have an internal reference: - the search dropdown and /website/search show only the product name. **Desired behavior after PR is merged:** On a category/shop with products that have an internal reference: - they show `[REF] Product name`, consistent with the shop grid and the product page. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents custom color filters on website video backgrounds from disappearing when a user reselects the block in the editor. It helps website editors keep the intended visual styling without needing to reapply filters.
Original PR description
The color filter applied to a video background would disappear after selecting the block. Commit [1] fixed this problem, but only when the color filter is a gradient, but it didn't take into account just a plain color. This commit fixes it. Steps to reproduce: 1. Enter Edit mode on the website. 2. Drag and drop a snippet (e.g., "Intro"). 3. Set a video background for the block and apply a color filter with a custom color. 4. Click on another block then click back on the block with the video. -> The color filter is removed. [1]: https://github.com/odoo/odoo/commit/bd105a168df64c35ff09b9e51bcf83868fcfb378 task-6102345 Forward-Port-Of: odoo/odoo#264348
Date references in stock valuation filters now follow the date format configured in Odoo instead of each user's device settings. This keeps reports and screens consistent for all users, reducing confusion across regions and devices.
Original PR description
Why this Commit: --- toLocaleString() relies on the device's local format instead of the Odoo-configured format. Since Odoo already defines a standard date format,the toLocaleString() usages should be replaced to ensure consistency. After this commit: --- <img width="1884" height="363" alt="image" src="https://github.com/user-attachments/assets/8cee2d86-10dc-48d7-8c3a-369ec257c101" /> date references consistently use the Odoo-configured date format. OPW: 6087341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The French PDP configuration screen no longer mentions "Peppol" where it was not appropriate. This avoids potential confusion for users setting up French e-invoicing options and keeps the wording aligned with the intended service.
Original PR description
task-None
This fixes a display issue in Chatter where an activity could appear without a title if its summary was empty. Odoo now keeps the activity's fallback display name available, so users still see the correct activity label.
Original PR description
Before this commit: --- - Chatter activity display used [`summary`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L42) to get…
Before this commit: --- - Chatter activity display used [`summary`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L42) to get the display name. - If `summary` was empty, it fell back to [`display_name`](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/static/src/core/web/activity.js#L44). - However, `_to_store` only [stored](https://github.com/odoo/odoo/blob/4ba8950c25452cfe3310d40c26bd359c27f6c576/addons/mail/models/mail_activity.py#L680) `summary`. - As a result, nothing was shown when `summary` was empty, even though `display_name` was set. Steps to reproduce: --- - Create an activity in chatter - Remove the default summary if set. - Observer the title. https://github.com/user-attachments/assets/1684feb7-02d0-4ac1-9c00-d2aaae88e045 After this commit: --- - Added `display_name` to `_to_store` along with `summary`. - Chatter activity now correctly falls back to `display_name`. - Users can now see the correct activity label in chatter. OPW: 6212976 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266706
When users adjust the end time while quickly creating a calendar event, the full event form now keeps the updated duration. This prevents confusing or incorrect meeting lengths when moving from quick creation to the detailed form.
Original PR description
When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the…
When creating a calendar event by dragging on the calendar view, modifying the end time in the quick-create popover, and then clicking "More Options", the duration shown in the full form is the original drag value instead of the value implied by the user's updated stop. calendar's makeContextDefaults seeds default_start, default_stop, default_duration, and default_allday from the drag extent. In the quick-create popover, changing stop triggers _compute_duration on that record so its duration becomes correct. On "More Options", goToFullEvent extracts a whitelist of fields from the quick-create record as default_X and merges them with the original drag context. https://github.com/odoo/odoo/blob/c82341c503ac/addons/calendar/static/src/views/calendar_form/calendar_quick_create.js#L9-L19 duration is missing from that whitelist, so the merged context still carries the stale default_duration from the drag. In the full form, that default is applied to the duration field and _compute_duration does not run because a default was provided for a stored, writable field. Adding duration to the whitelist forwards the quick-create's recomputed value as default_duration so the full form opens with the correct duration. Steps to reproduce: 1. Open Calendar, drag to create a 2-hour event (e.g. 10:00-12:00) 2. In the quick-create popover, change the end time to 14:00 3. Click "More Options" 4. Check the Duration field in the full form => Duration shows the original drag value (02:00) instead of 04:00 opw-6087449 Forward-Port-Of: odoo/odoo#257294
This fix ensures negative currency amounts keep the expected order when Accounting is viewed in right-to-left languages such as Arabic. It prevents confusing displays like the minus sign appearing after the currency symbol, improving readability and accuracy on dashboards and payment/tax amount fields.
Original PR description
Steps to reproduce 1. Create a company with Egypt localization, currency EGP 2. On a bank journal, set Outstanding Receipt and Outstanding Payment accounts 3. Register a customer payment so the…
Steps to reproduce 1. Create a company with Egypt localization, currency EGP 2. On a bank journal, set Outstanding Receipt and Outstanding Payment accounts 3. Register a customer payment so the journal dashboard shows the Payments row with a negative amount 4. Switch the user language to Arabic 5. Open the Accounting dashboard Issue The Payments amount renders as "LE 5,000.00-" instead of "-5,000.00 LE". formatCurrency returns the string "-5,000.00 LE". In an Arabic page the leading "-" has no intrinsic direction, so the browser attaches it to the surrounding right-to-left Arabic text and visually moves it past the symbol. Sibling rows on the same dashboard render correctly because they already wrap the amount in dir="ltr", see https://github.com/odoo/odoo/blob/d0424f2ffcf99ee59befe288150f1643b3fa0112/addons/account/views/account_journal_dashboard_view.xml#L252 opw-6183749 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266742
Clicking a file field in a list now downloads the file without also opening the related record. This avoids an unexpected navigation step and makes file downloads in lists behave more predictably for users.
Original PR description
If a list view contains a field (column) with binary widget, on click it will download the content of the field. This is the intended behavior but at the same time it will, by default, open the record of which it is part, which is strange since the user only wants to download the content. With this PR we make use of .stop on the t-on-click to detach the execution of the function from the opening of the record. We also add unit tests for this. Task: 6260266
Point of Sale receipts and sales reports now use the date format configured in Odoo instead of each device's local settings. This keeps printed and displayed dates consistent across stores, terminals, and users.
Original PR description
Why this commit: --- There are two instances in version 17.0 where dates use toLocaleString(), which relies on the device's local format instead of the Odoo-configured format. Since Odoo already…
Why this commit: --- There are two instances in version 17.0 where dates use toLocaleString(), which relies on the device's local format instead of the Odoo-configured format. Since Odoo already defines a standard date format, all toLocaleString() usages in pos should be replaced to ensure consistency. Starting from version 17.0, cash in/out receipts and the sales report use the local device time format. This commit updates those references and aligns them with the Odoo-configured date format. During forwardporting the fix in version 19.0 needs to be added to [base.js](https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/point_of_sale/static/src/app/models/related_models/base.js#L64-L69). As formatDateOrTime function is used in the [reciept header](https://github.com/odoo/odoo/blob/0352c5e8543b75083cf555c3d5b4f164f949b465/addons/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml#L13) printing date on all reciepts. After this commit: --- <img width="947" height="982" alt="image" src="https://github.com/user-attachments/assets/2d9e4199-75dd-40ea-aeb1-27401c9022f3" /> All date references consistently use the Odoo-configured date format. OPW: 6087341 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266106 Forward-Port-Of: odoo/odoo#259112
Livechat visitors will no longer see mention suggestions when typing @, since those suggestions only showed themselves or OdooBot and added unnecessary clutter. Internal operators can still use mentions normally, keeping useful team communication unchanged.
Original PR description
**Description of the issue this PR addresses:** ---------------------------------------------- Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer.…
**Description of the issue this PR addresses:** ---------------------------------------------- Visitors in livechat can trigger partner mention suggestions by typing the @ delimiter in the composer. However, visitors can only mention themselves or odoobot, which does not provide meaningful functionality in the context of a livechat conversation. **Current behavior before PR:** ---------------------------------------------- - Visitors can type @ in the livechat composer and trigger partner mention suggestions. - The suggestions only include the visitor themselves or odoobot. **Desired behavior after PR is merged:** ---------------------------------------------- - The @ delimiter is disabled for visitors in livechat threads. - Partner mention suggestions are no longer triggered for visitors. - Internal users (operators) can still use @ mentions normally. Task-5119068 ---------------------------------------------- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267219 Forward-Port-Of: odoo/odoo#253551
The website link tracker now prevents users from creating tracking links with empty or invalid codes, avoiding broken entries in tracker lists. Once a tracker is generated, the target link field is locked so users are not misled into changing a value that would no longer take effect.
Original PR description
1. Remove the possibility to create link tracker with an empty code. Empty code tracker do not work, but still appear in the tracker list. Only accept alphanumerical chars in the tracker code. 2. Set the target link input as disabled after generating the tracker, since editing the target link at this point would have no impact. task-4531974 Forward-Port-Of: odoo/odoo#266733
This fix keeps the cursor or selected text in the expected position after content is moved in the HTML editor. It prevents confusion when moving tables or paragraphs, making editing smoother and more predictable for users.
Original PR description
#### Description of the issue/feature this PR addresses: - MoveNode restores the cursor at the container end position - After moving a table, the cursor ends outside the table body #### Desired behavior after PR is merged: - Preserve the selection if it was inside the moved node - Otherwise place the cursor at the start of the moved node #### Steps to reproduce: - Create a table in the editor - Move the table using Movenode - Drop the table and check the cursor position - The cursor ends outside the moved table body - Select some text in a paragraph - Move that paragraph using Movenode - The selection is placed at the end of the moved node task-6215743 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267393 Forward-Port-Of: odoo/odoo#264264
The payment link wizard now keeps its copy button within the available screen width on mobile devices. This prevents the button from being cut off, making the payment link easier to copy for users on small screens.
Original PR description
Description of the issue/feature this PR addresses: The payment link wizard copy button can overflow horizontally on small screens because of its long label. Current behavior before PR: On mobile view, the copy button may appear partially hidden. Desired behavior after PR is merged: The payment link wizard copy button properly fits within the available width on mobile view. Before: <img width="514" height="667" alt="image" src="https://github.com/user-attachments/assets/9060bf5a-9590-47a6-b322-220ed0a871be" /> After: <img width="514" height="667" alt="image" src="https://github.com/user-attachments/assets/3b257e73-3744-4236-b28c-bad1a46ca92d" /> @Tecnativa TT58871 @CarlosRoca13 please review --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#266303
This fix ensures chat messages correctly identify whether the sender is a registered user or a guest. It reduces occasional message attribution errors in live chat and portal discussions, improving reliability for customer conversations.
Original PR description
A message's author is identified by one of two fields depending on its model: `author_id` (for partners) or `author_guest_id` (for guests). Previously in `changeThread`, the value of `thread.effectiveSelf` (which can be either a Partner or a Guest) was provided as the `author_id` regardless of its actual model. This commit explicitly uses `store.self_partner` as the `author_id` and `store.self_guest` as the `author_guest_id` to resolve the occasional mismatch.
The Instagram Page block on websites now avoids showing error messages when viewed in Chrome on iOS. This prevents confusing tracebacks for logged-in users or debug visitors and keeps the page experience clean.
Original PR description
Scenario:
- insert Instagram Page snippet
- using iOS chrome browser (reproduced in iOS 26.3, google chrome 146)
visit that page logged in as a internal user or in ?debug=assets (so
traceback are shown)
Result: 3 tracebacks errors are shown with error "Uncaught Promise >
JSON Parse error: Unexpeced identifier "object".
Cause: probably since this change:
https://chromium.googlesource.com/chromium/src/+/9629a16a7ab0b91c59ecaa9fc8934db3d6c83ba3%5E%21/
chrome on iOS is sending message with this object as data:
{ "command": "registerAsChildFrameAck", "remoteFrameId": "d905013d…" }
but the instagram code is expecting a stringified JSON.
Fix: ignore message data that are object.
opw-5930717
Forward-Port-Of: odoo/odoo#267027
Forward-Port-Of: odoo/odoo#254664German DIN 5008 invoice PDFs now keep all columns properly aligned when a section hides its composition details. This prevents confusing or shifted invoice layouts when businesses print invoices with the position column enabled.
Original PR description
| Before | After | |--------|--------| | <img width="1573" height="830" alt="image" src="https://github.com/user-attachments/assets/1960b51b-5c3e-4560-bd09-a20adfe2b381" /> | <img width="1573" height="830" alt="image" src="https://github.com/user-attachments/assets/565d0238-a295-44b7-bdaa-e7c6dd1200cf" /> | Steps to reproduce ================== - Install l10n_din5008,l10n_de - Use a german company - Go to settings - Enable "Show Position Column in Reports" - Go to Invoicing > Sales > New - Add a new section - Click on the three dots - Check "Hide composition" - Add a new line with a product - Confirm the Journal Entry - Print the Invoice PDF => Every column after the description is offset by one opw-5427590
Vendor credit note lines now show the related purchase order, matching the information already available on vendor invoices. This helps users quickly identify which purchase order each credited line belongs to when reviewing refunds linked to one or more purchase orders.
Original PR description
The purchase_order_id column in invoice lines was hidden for vendor credit notes (in_refund), while it was visible for vendor invoices (in_invoice). This prevented users from identifying which purchase order each line belonged to when a credit note was linked to one or more POs. Include 'in_refund' in the column_invisible condition so the purchase order column is also available on vendor credit note lines. 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 update resolves an issue where employees with overlapping contracts would incorrectly trigger a 'Duplicate Payslip' warning. The change limits the warning check to only consider payslips with the same version, ensuring accurate payroll processing for employees with multiple contracts within the same month.
Original PR description
If an employee has a contract that ends in the middle of the month and another contract starts in the same month, the two payslips that are created for the month trigger the "Duplicate Payslip" warning, even though they use different version IDs. This commit limits the search domain for the duplicate payslips to only consider payslips with the same version ID. task-6226391
This update resolves an issue where custom POS modules could unexpectedly block login. By introducing a new check within the POS system, we ensure that login only fails when a cashier is intentionally set to prevent access, providing a smoother and more reliable user experience for POS operations.
Original PR description
When a custom module patches `setCashier` without returning a value, the login check in `select_cashier_mixin` received `undefined` (falsy), causing the login flow to abort even though the cashier was set correctly. Introduce a dedicated `canLoginCashier` hook on `PosStore` that controls whether a login attempt should proceed. The mixin now calls this method before `setCashier`, decoupling the login guard from `setCashier`'s return value entirely. Custom modules that need to block login should override `canLoginCashier` instead of relying on `setCashier` returning `false`. opw-6247190
This update ensures that the l10n_id_reports module can be properly translated within Odoo. By adding the module to the Weblate configuration file, the system now recognizes and supports translation workflows for this specific reporting module, improving localization capabilities.
Original PR description
Enable translation management by adding the module entry to .weblate.json. task-6239169
This update resolves a test failure that occurred when the demo data was installed. The fix ensures that simulation offers are hidden by applying a filter, preventing errors during testing and improving the stability of the salary payroll module. This ensures accurate simulation runs.
Original PR description
**Problem**: The test fails when demo data is installed because some steps expect an empty list view. **Fix**: Ensure the simulation offer is hidden by applying a custom filter on the simulation employee Task: 6246575
A test was failing due to a limitation in how the POS system loads partner data. This update corrects the test to ensure it functions correctly with demo data, preventing a disruption in the POS functionality. This ensures the POS system operates as expected for all users.
Original PR description
**Issue:** `test_pos_fiscal_position_without_pos_avatax` test is failing with demo data because a US partner is created and searched for in the tour, but only the first 100 partners (alphabetically ordered) are loaded in the POS. Therefore, he's not found. runbot-938983
This update fixes an issue where the project template dropdown in demo mode had a poorly designed layout, making it difficult to read. The fix removes a styling element that caused text to overlap, ensuring a consistent and user-friendly experience for all users, including demo users.
Original PR description
Steps to reproduce: == Login as demo/onboarding user Open Project app Click on New Observe the template dropdown list Issue: == The template dropdown items are rendered with collapsed row height and poor vertical spacing in demo mode, making the list hard to read. Cause: == The template dropdown items utilized the `pe-0` utility class, which removed the padding at the end of the element. For non-admin users this caused the template name to touch the right edge of the container. Fix: == Removed the `pe-0` from the `DropdownItem` to restore standard right-side padding, and ensure consistent and readable row heights for both Admin and Demo users. task-5338191
This update enhances the usability of asset analytics by enabling multi-editing of the analytics distribution field, mirroring the functionality available for journal items. This change simplifies the process of updating asset analytics data, improving efficiency for users.
Original PR description
This commit fixes the multi-edit of analytics distribution field in assets form view. The multi-edit option was added to the analytics distribution widget, same as in the journal items. task-6218188
This update fixes a technical issue that caused a traceback when attempting to mark workorders as done in certain scenarios, specifically when no workorders were open. The fix ensures the system handles empty recordsets gracefully, preventing errors and maintaining stability.
Original PR description
When calling on a empty recordset action_mark_as_done, it creates a traceback. **Observation** When calling action_mark_as_done, the method first loops over each workorder to perform various safety…
When calling on a empty recordset action_mark_as_done, it creates a traceback. **Observation** When calling action_mark_as_done, the method first loops over each workorder to perform various safety checks, and then calls button_finish to close all workorders: https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L881-L888 Inside button_finish, it retrieves all open workorders and marks them as done: - Retrieve open workorders: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L659 - mark them as done: https://github.com/odoo/odoo/blob/36a1c6300f52f408b6af3f769e26686e07810e5a/addons/mrp/models/mrp_workorder.py#L675-L678 Returning to action_mark_as_done, it attempts to set the state to 'done' on the last workorder outside of the loop, referencing the loop variable: https://github.com/odoo/enterprise/blob/24008b550c5e7cf04cde2028c40f8a32d5b0e504/mrp_workorder/models/mrp_workorder.py#L894 -> If self is empty, the loop never executes. This leaves the loop variable empty, which ultimately triggers a traceback. opw-6239910 Forward-Port-Of: odoo/enterprise#118403
This update resolves an issue where Odoo was incorrectly flagging service invoices as requiring an Incoterm, even though this requirement doesn't apply to service products. The fix ensures that service invoices are processed correctly when exporting to the tax agency, preventing export errors.
Original PR description
With l10n_gt_edi: - Create an invoice with a partner without a country (in l10n_gt this is considered an export invoice) and a service product. When trying to export the invoice to the tax agency, the following alert is triggered: Incoterm is required on export invoice with goods product but it's currently missing However, service products do not require incoterm configuration. opw-6170409
This update corrects a minor visual issue where an unnecessary space appeared at the top of payslips. This ensures a cleaner and more professional appearance for payroll documents, improving the user experience. The fix was implemented to maintain consistent formatting and readability.
Original PR description
There was an extra space useless on top of payslips because there was an extra field "issue" that should'nt be there Task: 6268680
This update resolves an issue where reports downloaded in Safari (specifically with the German language setting) were generating incorrect filenames. The problem stemmed from a formatting error in the date-based filename generation process, which failed to handle certain date formats. This change ensures reports download with the correct, intended filenames.
Original PR description
**STEP TO REPRODUCE** 1. On safari 2. Switch language to German. 3. On the general Ledger, select a custom date range. 4. Download the pdf/xslx 5. Notice the file have the name `example.com` instead of the intented name. **CAUSE** Since 19.0, we use the date to generate the file name. There is a regex used to format the date range, but it doesn't catch some date format like `DD.MM.YYYY`, which some localisation used. In such case, we use a string which contains a `\n` character to build the filename. This doesn't work on safari, leading to the file defaulting to `example.com` opw-6194841
This update fixes an issue where automation rules using dotted field paths for user assignment in activity creation failed to display the correct user information. The change utilizes a mapping approach, mirroring a previous fix in the mail module, to correctly handle relational field chains and ensure accurate user assignment.
Original PR description
Steps to reproduce: ------------------------------------ 1. Install `ai` and `contacts` modules 2. Create an automation rule on Contact model: * Trigger: On Creation * Action To Do: Execute AI Action…
Steps to reproduce:
------------------------------------
1. Install `ai` and `contacts` modules
2. Create an automation rule on Contact model:
* Trigger: On Creation
* Action To Do: Execute AI Action
* Add a server action tool with 'Create Next Activity' action
* Set Activity User Type to Dynamic
* Set User Field to a dotted path (e.g., user_ids or partner_id.user_id)
3. Create a contact with a linked user
Observation:
------------------------------------
The activity description in the toast message fails to retrieve the user when using dotted field paths
Issue:
------------------------------------
The direct field access `record[self.activity_user_field_name]` in `_ai_get_action_description` method doesn't support dotted paths like 'partner_id.user_id'. This causes the same issue as in the mail module where relational field chains cannot be traversed
Solution:
------------------------------------
Use `record.mapped()` to support dotted paths by traversing the relational chain, consistent with the fix applied to the mail module
opw-6191715
Related Community PR: https://github.com/odoo/odoo/pull/263530This update resolves a bug in the general ledger report within Odoo 19.0 that could cause errors when expanding collapsed lines based on a threshold setting. The change ensures the report functions correctly by adjusting how data is filtered, preventing index errors. This fix only applies to Odoo 19.0.
Original PR description
Before this commit, when expanding a line collapsed by the `prefix_groups_threshold` setting could cause an index error when in the case where `lines == []` here https://github.com/odoo/enterprise/blob/ebcbea05bf5e43c9940c32cb0140c3e5cb1ba39e/account_reports/models/account_general_ledger.py#L381 This commit changes the forced_domain such that it uses `display_name` instead of `name` at https://github.com/odoo-dev/enterprise/blob/f4a5d104c479d00101f1381e9cdc31cb1a8d7bf7/account_reports/models/account_report.py#L6023 Steps to reproduce: New 19.0 DB Install accountant Create a journal entry for a few different accounts Activate developer mode Go to the general ledger and click the settings/gear icon Lower the threshold to something small, like 2 Go back to the report and attempt to open the now collapsed line and see error **Only affects 19.0, `prefix_groups_threshold` does not exist in higher versions** opw-6231127
This update fixes a bug in the helpdesk rating dashboard. Previously, ratings created late in the day weren't accurately reflected in search results. Now, the system uses the current date and time for searches, ensuring ratings from the last seven days are correctly displayed.
Original PR description
Before this commit, the ratings created the current date at 23h will not been taken into account in helpdesk rating dashboard. This commit uses datetime.now() instead of date.today() to search the ratings in the last 7 seven days. runbot-error-230905
This update optimizes the visual styling of the Odoo Enterprise home menu to improve website loading speed. By replacing complex CSS selectors with CSS variables, the system now performs more efficiently, leading to a faster and smoother user experience. This change focuses on performance enhancements.
Original PR description
Avoid selectors after `:hover` and `:active`, as they can impact performance. CSS variables are now used instead. Replace hex color values with "0 0 0" RGB syntax to ensure compatibility with CSS variable usage.