Tuesday, June 2, 2026
41 changes · saas-19.3
Resolved issues and error corrections
This update fixes an issue where project Kanban status colors were not rendering correctly due to a mismatch between the frontend and stylesheet. The fix ensures that high project IDs are correctly processed, resulting in accurate color display for project updates within the Kanban view.
Original PR description
### The Issue: The frontend Kanban view enforces a strict 12-color limit using a modulo 12 mathematical rule (which calculates the remainder after dividing by 12). When the frontend receives our high backend IDs (20-24), it runs this modulo math (e.g., 23 % 12) to force them into the allowed limit, converting them into the remainders: IDs 8, 9, 10, 11 and 0. Because stylesheet was still searching for the original high numbers (20-24) instead of these modulo results, the custom colors were completely ignored by the browser. ### The Fix: Updated the stylesheet to target the actual modulo-computed classes (.oe_kanban_color_8 through 11 and 0). Mapped these classes to their correct variables (-success, -info, -warning, -danger, -primary) and fixed the left border styling so the colors render properly. task-6064106 Forward-Port-Of: odoo/odoo#266693 Forward-Port-Of: odoo/odoo#256023
This update fixes a visual issue where alternating row colors were incorrectly applied, often resulting in the table header and first row having the same background color. The change ensures consistent and correct alternating row coloring for improved readability and a better user experience.
Original PR description
### Purpose of this PR: Previously, alternating row colors were applied on even rows. When a table header was enabled, the header row and first body row could end up sharing the same background color. This PR updates the alternating row logic to apply colors on odd rows instead. task-6204622 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263497
The WIP report now displays accurate information when using analytic items tracked only with projects, preventing misleading demo data from appearing. This change ensures users see the correct report preview, particularly when working with project-based analytics. The fix maintains the report editor's preview functionality.
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 adds a direct link within the Timesheets Assistant interface to the official documentation. This makes it easier for users to quickly find answers to their questions and understand how to use the Timesheets Assistant feature effectively. It's a small change intended to improve user support and knowledge.
Original PR description
This commit adds documentation link in Timesheets Assistant to redirect the user to the documentation of Timesheets Assistant. task-6095833 Forward-Port-Of: odoo/enterprise#118754
This update clarifies the 'invalid_scope' error message, which previously wasn't clear enough for users. The change ensures users understand why consent is being denied, specifically related to legal rights for their company. This improves the user experience and helps with compliance.
Original PR description
The invalid_scope error message means the user doesn't hav the legal rights to give consent for the given company. But the error message is not clear enough. This commit improve the error message clarity. task-6144883 Forward-Port-Of: odoo/enterprise#115650
This update fixes a minor error in the DMFA report where the 'Calculation Basis' and 'Contribution Type' headers were incorrectly switched. The headers have now been corrected to their proper order, ensuring accurate reporting for payroll calculations. This ensures compliance and reliable financial data.
Original PR description
DMFA report had "Calculation Basis" and "Contribution Type" header switched. Got switched back correctly. task-6227590 Forward-Port-Of: odoo/enterprise#117740
This update resolves a potential instability in the testing of one2many fields within the Odoo web application. The fix prevents a test from failing intermittently due to a duplicate record creation. This ensures more reliable test results and improves the overall stability of the Odoo system.
Original PR description
This commit fixes a non deterministic one2many field test by ensuring that we don't quick create the record twice.
Before this commit, it might sometimes happen that the validation of the input ("Enter", by default) produced a second name_create. Note that in practice this is highly unlikely to happen as if the user presses Enter, the "Quick create" item in the dropdown only appears during a single frame, thus making impossible for the user to click on it.
It's the exact same issue as the one fixed by odoo/odoo#256582.
runbot error~242443
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#267224
Forward-Port-Of: odoo/odoo#266344This update optimizes the way Odoo calculates the appearance of work orders, specifically when resizing windows or scrolling through large tables. By using a more targeted approach, it reduces the time Odoo spends re-evaluating styles, leading to a smoother user experience.
Original PR description
Avoid using the :has() selector and use a specific class on the body instead to replicate the same behavior, this reduces work during the "Recalculate Style" phase. It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. Forward-Port-Of: odoo/enterprise#118618
This update corrects a bug that prevented the system from correctly parsing time entries when using the German language. Specifically, the system failed to recognize time formats with capital letters for units like 'minutes' or 'hours'. This change ensures accurate time input and processing for German users.
Original PR description
Issue: ---------------------------------------- In German, using a time field with minutes breaks the parser and only the hours are taken into account. Steps to reproduce:…
Issue:
----------------------------------------
In German, using a time field with minutes breaks the parser and only the hours are taken into account.
Steps to reproduce:
----------------------------------------
- Install Timesheet and Project
- Change language to German
- Open a task, page "Timesheets"
- Create a new record
- Write "2:30" to set the time, it will work
- It won't work if you add an UoM, i.e. "2h30m", "2h 30 Min."
Cause:
----------------------------------------
In German all common nouns begin with a capital letter so their UoMs too.
In the parser we call `durationUnitsRegex` which uses a library to get the UoMs in the local language.
https://github.com/odoo/odoo/blob/2e2d4752bd12210be4b30bddaf8c9fc1861ec0e4/addons/web/static/src/core/l10n/time.js#L289-L298
For Germany, the abbreviations will have capital letters ("Min.", "Sek.", etc.). So there will be upper case letters in the regex.
But the string on which we call the regex is only lower case:
https://github.com/odoo/odoo/blob/2e2d4752bd12210be4b30bddaf8c9fc1861ec0e4/addons/web/static/src/views/fields/parsers.js#L185-L189
https://github.com/odoo/odoo/blob/2e2d4752bd12210be4b30bddaf8c9fc1861ec0e4/addons/web/static/src/core/l10n/time.js#L271-L277
So the regex returns no match.
Solution:
----------------------------------------
When building the regex, we call `RegExp()` constructor with "i" to ignore cases.
opw-6236787
Forward-Port-Of: odoo/odoo#266451This update ensures that the l10n_id_reports module is properly configured within Odoo's translation management system (Weblate). Adding the module to the .weblate.json file allows translators to manage and update the module's translations effectively, improving localization accuracy and supporting our users in the ID region.
Original PR description
Enable translation management by adding the module entry to .weblate.json. task-6239169 Forward-Port-Of: odoo/enterprise#118931
This update corrects a technical oversight where a new module for the Hungarian language reports (l10n_hu_reports_a60) was not properly integrated into Weblate. This ensures that translators can accurately begin working on the Hungarian translations, improving the quality and availability of the Enterprise software for Hungarian-speaking users.
Original PR description
We added a new module here 379c5e9611f1f1c242027c1c134219966474de16 but forgot to add it to weblate.json for translation. no-task Forward-Port-Of: odoo/enterprise#118932
This update resolves an issue where employees with overlapping contracts would incorrectly receive a 'Duplicate Payslip' warning. The change restricts duplicate checks to payslips sharing the same version, ensuring more accurate payroll processing and reducing unnecessary alerts for users. This improves the user experience and data accuracy.
Original PR description
If an employee has a contract that ends in the middle of the month and another contract starts in the same month, the two payslips that are created for the month trigger the "Duplicate Payslip" warning, even though they use different version IDs. This commit limits the search domain for the duplicate payslips to only consider payslips with the same version ID. task-6226391 Forward-Port-Of: odoo/enterprise#118652
This update resolves a recurring issue in a key test for our web interface related to autocomplete functionality. Previously, the test would sometimes fail due to timing problems. By ensuring all timers are run, this fix guarantees the autocomplete process completes correctly and is reliably verified, improving the overall stability of the system.
Original PR description
This test was sometimes failing, when the debounce delay (250ms) of the autocomplete ended before the end of the test, resulting in an unexepected "web_name_search" step. With this commit, we run all timers, thus ensuring the web_name_search to be always done, and we assert it. runbot error~937794 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267407
This update removes a confusing placeholder in the accounting module that encouraged users to create specific ledger types. The change simplifies the setup by removing the suggestion and acknowledging the existing 'Local GAAP' option. This ensures users can easily configure their accounting ledgers.
Original PR description
The placeholder 'e.g. GAAP, IFRS, ...' is confusing for the users as it encourages them to create a GAAP ledger, or there is already an implicit ledger for that called 'Local GAAP'. task-6260588 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#267399
This update corrects a reporting issue that occurred when all company journals were assigned to a single ledger. The fix removes the 'Local GAAP' implicit ledger from report selections, ensuring accurate reporting regardless of ledger configurations. This improves the consistency and reliability of financial reports.
Original PR description
When all journals of the company are in a ledger, the implicit ledger 'Local GAAP' is empty, so we remove it from the ledger selection in the reports. task-6260588 Forward-Port-Of: odoo/enterprise#118927
This update ensures that invoices generated from point-of-sale orders now correctly include the product's internal reference (like 'E-COM11') alongside the product name. Previously, invoices lacked this key detail, which is now resolved to provide more accurate and complete invoice information for customers.
Original PR description
Currently invoices generated from pos orders do not show the product referense alongside the product name. Steps to reproduce: ------------------- * Open shop and select Cabinet with doors * Add…
Currently invoices generated from pos orders do not show the product referense alongside the product name. Steps to reproduce: ------------------- * Open shop and select Cabinet with doors * Add customer to order * Pay the order * Wether you selected to invoice or you didn't, does not matter, you can invoice from the backend > Observe on the invoice that the product does not show the internal reference "Cabinet with Doors" * Create a sale order for the same product, deliver and invoice > Observe the invoice, the product shows reference "[E-COM11] Cabinet with Doors" Why the fix: ------------ After this commit: https://github.com/odoo/odoo/commit/aff477805577cb7ed00fb94440dda5cf2f29cb44 we're using `full_product_name` to set the name on move line name. We could simply add the reference when computing the product name but the logiq used to computed the display name is a bit more complex than simply adding it always. Instead we use both display_name and full_product_name to build the final name. This way it has the reference if any and all information about variants are kept as well. opw-5950016 Forward-Port-Of: odoo/odoo#266797 Forward-Port-Of: odoo/odoo#253540
This update fixes a potential error in the VeriFactu integration that occurred when sequence numbers included letters (prefixes/suffixes). The fix prevents the system from crashing and provides a helpful message to users, instructing them to remove any non-numeric characters from the sequence configuration. This ensures invoices are correctly generated and sent to VeriFactu.
Original PR description
**Steps to reproduce:** 1. Install l10n_es_edi_verifactu. 2. Switch to a ES company. 3. Create a customer invoice and send it to VeriFactu. 4. Enable Developer Mode. 5. Go to Settings > Technical >…
**Steps to reproduce:** 1. Install l10n_es_edi_verifactu. 2. Switch to a ES company. 3. Create a customer invoice and send it to VeriFactu. 4. Enable Developer Mode. 5. Go to Settings > Technical > Sequences & Identifiers > Sequences. 6. Search for the `Sequence Code: l10n_es_edi_verifactu` and open it. 7. Set a prefix or suffix using any alphabetical character. 8. Create a new invoice and send it to VeriFactu **Issue:** Traceback on sending Veri*Factu: `ValueError: invalid literal for int() with base 10: 'F260001'` **Cause:** The value returned by `ir.sequence.next_by_id()` may contain alphabetical characters (due to prefix/suffix), while the field `chain_index` expects an integer. The raw sequence value was directly assigned, causing the conversion to fail. **Fix:** Catch the ValueError raised by int() when the sequence value contains non-numeric characters (e.g. due to a prefix/suffix). Instead of crashing, surface a user-friendly error on the document telling the user to remove the prefix/suffix from the sequence configuration. **opw-6037528** Forward-Port-Of: odoo/odoo#255473
This update fixes an issue where the 'l10n_co_edi_type' field for Dian bills wasn't correctly imported during XML imports. Previously, it was limited to 'DIAN Support Documents' journals. Now, bills imported through the Purchase journal will maintain their original EDI type, ensuring accurate reporting and compliance.
Original PR description
In l10n_co_edi on bills, the field l10n_co_edi_type can only be changed when the journal is DIAN Support Documents and not purchase. However when importing a XML, the field is not imported and is instead always computed to type 01. It should be possible to have imported bills using the Purchase journal and maintain their original type. (Take the xml on the ticket to reproduce the issue) opw-6203930 Forward-Port-Of: odoo/enterprise#118533
This update resolves an issue where a color filter applied to a video background in the website editor would disappear after navigating to a different block. The fix ensures the color filter remains consistent when switching back to the video block, improving the visual consistency of website designs. This enhancement contributes to a better user experience for website customization.
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
This update enhances the import of vendor invoices from UBL documents by refining how purchase order references are identified. Previously, all words in item descriptions were used as potential references, leading to potential inaccuracies. Now, the system uses a defined sequence pattern from the purchase order model to ensure more precise matching and reliable PO identification.
Original PR description
[FIX] *: improve invoice origin keywords selection modules: account_edi_ubl_cii, purchase_edi_ubl_bis3 In UBL when importing a vendor bill, if the purchase order reference is not in the right node (OrderReference), we're used to take every word in the items descriptions as potential reference without applying any filter This commit apply a filter using the ir.sequence related to the purchase.order model With this, we only consider words following the sequence naming pattern to search for a related PO no-task Forward-Port-Of: odoo/odoo#266998 Forward-Port-Of: odoo/odoo#262678
A recent update to the Manufacturing BoM report caused the header to overlap with the product details on the second page. This fix reverts a style change that was disrupting the report's pagination, ensuring the header and component information are displayed correctly. This resolves a visual issue impacting report readability.
Original PR description
Steps to reproduce: 1- Install Manufacturing 2- Create a test product and create a BoM for that product 3- Add many components (>12) to the BoM and download the BoM Overview Issue: The BoM Header line (Product - Quantity - Cost) overlaps with the actual components of the BoM in the second page Why this happens:I Part of the commit 193302b272bbd49a1addb5b8135ef23498d2d8e9 changed the div style for the report which causes this overlap. The root cause is likely `overflow-auto` creating a block formatting context that confuses wkhtmltopdf's pagination, causing the header to not repeat correctly on page 2. It does not have any effect on the rest of the layout, so can be reverted to the previous style. opw-6214362 Forward-Port-Of: odoo/odoo#264374
This update resolves an issue where the 'Translate' button was hidden in the mobile toolbar. The fix involved adjusting the size of the SVG icon used for the button, ensuring it's correctly displayed on mobile devices. This improves the user experience for mobile users.
Original PR description
**Description of the issue:** - Translate button was not visible in the mobile toolbar. Cause: - The SVG icon used for the translate button had 0px width and height in the mobile toolbar layout, causing it to be invisible. Solution: - Set proper width and height for the SVG icon so the translate button is correctly rendered in the mobile toolbar on mobile devices. task-6201171
This update fixes an issue where customer avatar images were not stretching to fill their containers. The change removes a SCSS rule that was preventing this and instead applies a standard styling method to ensure avatars display correctly across different devices and resolutions. This improves the visual consistency of customer profiles.
Original PR description
*: base, point_of_sale, product, sales_team A SCSS file was removed in commit dc8f38b targetting the `contact_image` widget. This file contained `object-fit:contain` which prevented avatar images from stretching. Similarly, the `oe_avatar` class was removed from `image` widgets which had the same impact. We fixed that by placing the `object-fit-contain` class onto the widget itself. Border styles were added for visual alignment with similar views. task-6176729 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where combo product prices were incorrectly duplicated in sales orders when all component products had a zero list price. The fix ensures the combo price is accurately distributed across its items, preventing double-billing and improving order accuracy. This improves the user experience and financial reporting.
Original PR description
**Problem:** When a combo product has a price but all of its combo components have a zero list price, the quotation shows the combo's price twice: once on the combo line itself and once on the last…
**Problem:** When a combo product has a price but all of its combo components have a zero list price, the quotation shows the combo's price twice: once on the combo line itself and once on the last combo item line. **Steps to reproduce:** 1. Create a combo product with a non-zero price and two or more combo groups whose component products have a zero list price. 2. Create a sale order, add the combo, pick one item per group. 3. Look at the quotation/order: the combo line total and the last combo-item line both show the full combo price. **Current behavior:** The full combo price ends up on the last combo item line; the other combo items show 0. The combo line then displays the same total via `_get_combo_totals`, so the same amount appears twice. **Expected behavior:** The combo's price is spread across its combo items so no single line duplicates the combo total. **Cause of the issue:** `_get_combo_item_display_price` prorates the combo price by each combo's base price. When every base price is 0, every prorated price is 0, so `combo_price_delta` equals the full combo price and is added to the last combo as a rounding correction, concentrating the whole price there instead of spreading it. **Fix:** Treat an all-zero base case as "no proration signal" and split the combo price evenly across combos before the delta adjustment runs. The delta correction then only handles rounding, as intended. opw-6217945 Forward-Port-Of: odoo/odoo#265829 Forward-Port-Of: odoo/odoo#265010
This update fixes minor bugs in the tests for our Point of Sale (POS) system, specifically within the checkTicketData() helper function. The changes ensure accurate test results by correctly handling empty data and preventing unexpected type conversions, ultimately improving the stability and reliability of our POS testing.
Original PR description
..., l10n_es_pos, l10n_jo_edi_pos, l10n_br_edi_pos
---
Fix two bugs in the checkTicketData() test helper:
- Replace falsy check `!statement` with `!statement.length` to
correctly handle empty NodeList results from querySelectorAll,
as an empty NodeList is still truthy.
- Replace loose equality `ruleFound == rule.negation` with strict
equality `ruleFound === (rule.negation || false)` to avoid
unintended type coercion when `rule.negation` is undefined.
---
Task: https://www.odoo.com/odoo/project/1737/tasks/6147566
Forward-Port-Of: odoo/odoo#262041
Forward-Port-Of: odoo/odoo#260431This update fixes a minor bug in the point-of-sale test function, ensuring accurate results when handling empty data. The changes improve the reliability of the tests related to tax and invoicing features for various international POS implementations (e.g., Spain, Jordan, Brazil).
Original PR description
..., l10n_es_pos, l10n_jo_edi_pos, l10n_br_edi_pos
---
Fix two bugs in the checkTicketData() test helper:
- Replace falsy check `!statement` with `!statement.length` to
correctly handle empty NodeList results from querySelectorAll,
as an empty NodeList is still truthy.
- Replace loose equality `ruleFound == rule.negation` with strict
equality `ruleFound === (rule.negation || false)` to avoid
unintended type coercion when `rule.negation` is undefined.
---
Task: https://www.odoo.com/odoo/project/1737/tasks/6147566
Forward-Port-Of: odoo/enterprise#115676
Forward-Port-Of: odoo/enterprise#114581A test was failing due to a limitation in how the POS system loads partner data. This update corrects the test to ensure the fiscal position functionality works correctly, particularly when searching for US partners. This resolves a potential issue with the POS experience.
Original PR description
**Issue:** `test_pos_fiscal_position_without_pos_avatax` test is failing with demo data because a US partner is created and searched for in the tour, but only the first 100 partners (alphabetically ordered) are loaded in the POS. Therefore, he's not found. runbot-938983 Forward-Port-Of: odoo/enterprise#118345
This update resolves an issue where marking workorders as done would generate a traceback when no workorders were open. The fix ensures the system handles empty recordsets gracefully, preventing errors and improving stability. This ensures the workorder completion process functions correctly even when there are no active workorders.
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#118718 Forward-Port-Of: odoo/enterprise#118403
A recent test failed due to an error in how the system searched for short URLs. This update corrects a logic flaw that caused duplicate links to be returned when similar code patterns were present. This ensures more accurate and reliable link searching within the system.
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
This update fixes a bug where removing formatting from text within uneditable areas could incorrectly change the user's selection. The fix ensures the HTML editor accurately handles selections within contenteditable blocks, regardless of nested editable regions. This improves the overall stability and usability of the HTML editor.
Original PR description
Description of the issue/feature this PR addresses: Before this PR, removing formatting from a partially selected text nested inside a contenteditable="false" block could incorrectly alter the selection. This happened because selectAroundNonEditable checked for the presence of a closest uneditable ancestor instead of verifying whether the closest element itself was editable. As a result, selections inside nested contenteditable="true" regions were mistakenly treated as uneditable. This PR fixes the issue by checking the editability of the closest element directly. task-6201120 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#264548
This update resolves a bug where resetting font colors in the To-Do creation process didn't correctly remove the applied color. The fix ensures the system now accurately targets and removes the intended color, regardless of nested styling, improving the user experience.
Original PR description
### Steps to Reproduce : - Go to To-Do → Create New - Type something - Apply font color → then background color. - Try to remove the font color. - You will not be able to remove the font color. ###…
### Steps to Reproduce :
- Go to To-Do → Create New
- Type something
- Apply font color → then background color.
- Try to remove the font color.
- You will not be able to remove the font color.
### Description of the issue/feature this PR addresses:
- In getFonts, the closestElement predicate was used to find the nearest `<font>` element.
For nested structures like:
```html
<font style='color: ...'>
<font style='background-color: ...'>test</font>
</font>
```
predicate would return inner `<font>` (background-color) since it is closest.
- As a result, when resetting the text color, the operation targeted the wrong element, and the outer color was not removed.
### Desired behavior after PR is merged:
- When resetting (i.e. mode is used), find the closest node that matches the specific mode. Then we apply or reset the color on that node.
task-6124432
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#262203This update fixes minor layout issues on the customer portal, specifically addressing misalignment of alert content and Knowledge cards. While a temporary SCSS fix was implemented, the core issue – related to how content is structured – will be resolved in a future update to the main Odoo codebase.
Original PR description
The alert content is vertically misaligned due to the mb-1. The Knowledge / Document cards are not inserted inside a `row` which misaligns them due to the missing margin and padding. This is to be reworked on master forwardport since here we're dealing with nested rows withouth intermediary columns. SCSS only fix for stable. task-5262108 <img width="663" height="553" alt="image" src="https://github.com/user-attachments/assets/18dd6c2f-47f0-4ba8-91cb-f9c5a2e0fda4" /> > [!NOTE] > On the master forwardport I'll review the DOM to avoid the nested row and unnecessary margin instead of the scss fix here. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249313
This update enhances Odoo's upgrade process by allowing it to partially load module rules during upgrades when not all modules are immediately available. This prevents upgrade failures and improves the overall stability of the system, especially during initial deployments or when modules are not fully installed.
Original PR description
Allow partial loading of the registry during upgrade when not all modules are available.
This update resolves an issue where attachments added to emails sent via the 'Send by Email' action were disappearing after refreshing the chatter window. The fix restricts attachment saving to the full composer view, ensuring consistent behavior across different email composer types. This improves the reliability of sending emails with attachments.
Original PR description
**Steps to reproduce:** - Install Sales app - Create a Sales Order - Click on the 'Send by Email' action - Add an attachment and send it - Open the chatter to create a log note - Attachment is…
**Steps to reproduce:** - Install Sales app - Create a Sales Order - Click on the 'Send by Email' action - Add an attachment and send it - Open the chatter to create a log note - Attachment is attached to the new message - It disappears on refresh **Issue:** Attachment upload widget was moved to the toolbar of the composer with [1], which split it into `mail_composer_attachment_selector` and `mail_composer_attachment_list`. Then with [2] the selector logic was changed to use `FileUploader` instead of `FileInput` to get the attachment synced when switching back and forth between full and normal chatter composers. But this should not impact action composers created with `'mail.email_compose_message_wizard_form'`. **Fix:** Restrict the attachment save to the full composer using context. [1] https://github.com/odoo/odoo/commit/cee3c8146863300242f9f2d109743a50c2b91027 [2] https://github.com/odoo/odoo/commit/9f7249a141b618fc8640a65d1f7fc20023156ce3 opw-5164504 Forward-Port-Of: odoo/odoo#266994 Forward-Port-Of: odoo/odoo#265736
This update fixes an issue where the payment link wizard's copy button would overflow on smaller mobile screens due to a long label. The change ensures the button fits properly within the available space, providing a better user experience on mobile devices.
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 update corrects a bug where the 'Reset Selected Work Entries' function in the payroll module would unexpectedly delete work entries. The issue stemmed from a timezone mismatch between how work entries were calculated and displayed. The fix ensures accurate work entry handling regardless of user timezone settings.
Original PR description
Setup: Set the work entry source to attendance for an employee with active contract and change his timezone so that it differs from the working schedule one. Reset previous/next day delete Work Entry (payroll) - Step to reproduce: after an attendance was created, go to "Work Entries" in payroll, select the previous/next day and hit "Reset Selected Work Entries". The Work Entry will disappear. - Cause: reset window computed with calendar tz and work entry computed with user tz - Solution: localize work entries using calendar or user tz - Test: testing positive ans negative tz in hr_work_entry_attendance (enterprise) Task: 6072325 Forward-Port-Of: odoo/odoo#266777 Forward-Port-Of: odoo/odoo#257309
This update resolves a bug where the 'Reset Selected Work Entries' function in payroll was unexpectedly deleting work entries due to incorrect time zone handling. The fix adjusts the system's time zone settings to ensure accurate work entry management, preventing data loss and improving payroll processing reliability.
Original PR description
Setup: Set the work entry source to attendance for an employee with active contract and change his timezone so that it differs from the working schedule one. Reset previous/next day delete Work Entry (payroll) - Step to reproduce: after an attendance was created, go to "Work Entries" in payroll, select the previous/next day and hit "Reset Selected Work Entries". The Work Entry will disappear. - Cause: domain to nullify using wrong tz - Solution: adjust domain to use calendar tz - Test: testing positive ans negative tz in hr_work_entry_attendance (enterprise) Task: 6072325 Forward-Port-Of: odoo/enterprise#118563 Forward-Port-Of: odoo/enterprise#114148
This update resolves an issue where users couldn't remove prompt banners after inserting them using the `/prompt` command. The fix ensures that undo functionality correctly handles the creation and removal of these banners, improving user workflow within the AI editor. This prevents frustration and ensures consistent editing capabilities.
Original PR description
Problem: After inserting a prompt banner, undo does not remove it. Cause: History commands were ignored when the selection was inside the prompt banner, preventing undo from handling banner insertion. Solution: Handle history commands even when the selection is inside the prompt banner. Steps to reproduce: - Insert a prompt banner using `/prompt` + Enter. - Press Ctrl + Z. - Observe that the banner is not removed. task-6230530 Forward-Port-Of: odoo/enterprise#118248 Forward-Port-Of: odoo/enterprise#117845
This update resolves a technical issue preventing the Instagram snippet on our website from displaying correctly in iOS Chrome browsers. The problem stemmed from a change in how Chrome on iOS sends data, requiring a simple adjustment to our code to handle the data format. This ensures a consistent user experience across different browsers.
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#254664This update resolves an issue where Odoo was incorrectly flagging the absence of an Incoterm on service invoices (specifically export invoices) when exporting to the tax agency. The fix ensures that service products, which don't require Incoterm information, are processed correctly, preventing unnecessary alerts. This improves invoice export reliability for GT EDI users.
Original PR description
With l10n_gt_edi: - Create an invoice with a partner without a country (in l10n_gt this is considered an export invoice) and a service product. When trying to export the invoice to the tax agency, the following alert is triggered: Incoterm is required on export invoice with goods product but it's currently missing However, service products do not require incoterm configuration. opw-6170409 Forward-Port-Of: odoo/enterprise#115833
This update optimizes how Odoo recalculates styles, particularly in large tables like the Accounting > Balances Sheets. By using a specific class instead of a complex selector, the system now responds faster to actions like hovering or resizing the window, leading to a smoother user experience.
Original PR description
Avoid using the :has() selector and use a specific class on the body instead to replicate the same behavior. This reduces work during the "Recalculate Style" phase (for example when hovering rows in large tables such as the Accounting > Balances Sheets). It lowers recalculation time during window resizes, heavy scrolling, and table sorting by preventing broad selector matches and limiting style checks to elements with the specific class. 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#267602 Forward-Port-Of: odoo/odoo#267170