Thursday, November 27, 2025
32 changes · saas-18.4
Resolved issues and error corrections
This update resolves an issue where CFDI invoices generated in Mexico were producing incorrect rounding values. The fix involves a refined process for calculating tax amounts and aggregating line items, ensuring accurate CFDI generation and compliance. This improves the reliability of financial reporting for Mexican businesses using Odoo.
Original PR description
- Refactor the CFDI generation using the EDI tax helpers to prevent rounding issues by spreading the amounts according a tolerance of 0.000001. - Aggregate lines before computing the global invoice CFDI. That way, we avoid creating new rounding issues by post-processing the created CFDI. task_id: 5096249 Forward-Port-Of: odoo/enterprise#99395
This update fixes an issue where selecting a document in the list view in dark mode resulted in a white background and unreadable text. The fix dynamically adjusts the background color based on the user's theme setting, ensuring clear visibility.
Original PR description
**Steps:** - open documents in list view in dark mode - select and deselect a record **Observation:** - the selected record's background becomes white and text was already white - hence nothing can…
**Steps:** - open documents in list view in dark mode - select and deselect a record **Observation:** - the selected record's background becomes white and text was already white - hence nothing can be seen clearly **Cause:** - Commit [1] introduces a scss change for list view, but used hardcoded values for color, which works well for light mode but not in dark mode https://github.com/odoo/enterprise/blob/f73626fa778fd96de213a0fae61ced6fd5012d36/documents/static/src/scss/documents_views.scss#L29-L36 [1]: https://github.com/odoo/enterprise/commit/009fddcd20b0e7b81b8959f73e39d840d96167c7 **Fix:** - instead of hardcoding color, we use already available variable, which adjust the color, according to theme. **Before:** <img width="1150" height="176" alt="image" src="https://github.com/user-attachments/assets/33d0688c-d9cd-4266-bcc8-189e830bc391" /> <img width="1319" height="203" alt="image" src="https://github.com/user-attachments/assets/cd8fa68e-76ff-411d-8d37-4e61e2ce99e8" /> <br><br> **After:** <img width="1028" height="141" alt="image" src="https://github.com/user-attachments/assets/470365b0-c18f-497d-b3b2-11cd8fea371a" /> <img width="996" height="164" alt="image" src="https://github.com/user-attachments/assets/74d6b71b-852e-41ee-acb3-4b58d8eace9e" /> opw-5261669 Forward-Port-Of: odoo/enterprise#100114
This update resolves an issue where a technical error (traceback) occurred when adding tips after payment in the Point of Sale system. The fix ensures that the Tip Screen correctly uses a payment line if available, or falls back to the first payment line, preventing the error and improving the user experience.
Original PR description
Steps: --- - Enable Tips and "Add tip after payment" in restaurant. - Open a session and add any product(s). - Go to payment and add two card lines (first with full amount, second with 0). - Click on "Close Tab". Issue: --- - After redirecting to the Tip Screen, a traceback appears. Cause: --- - Clicking "Close Tab" clears all 0-amount payment lines. This can leave no selected payment line, but the Tip Screen still tries to access it. Fix: --- - Use the selected payment line if available, otherwise fallback to the first payment line. task-5095825 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237124 Forward-Port-Of: odoo/odoo#227797
This update fixes a bug where signature fields added to Studio views didn't display the correct widget option. Now, when adding a signature field, Studio automatically includes the signature widget in the selection list, ensuring users can properly configure these fields. This improves usability for signature-based workflows.
Original PR description
Before this commit: ------------------- When a user added an existing signature field to a view, Studio automatically assigned the default binary widget. The expected signature widget did not appear…
Before this commit: ------------------- When a user added an existing signature field to a view, Studio automatically assigned the default binary widget. The expected signature widget did not appear in the widget selection list. As a result, users could not configure the field as a signature input. <img width="1920" height="938" alt="image" src="https://github.com/user-attachments/assets/35893235-2541-4bd5-a7a5-4feab562acb2" /> Cause: ----- Studio builds the dropdown of available widgets by computing a [widgetKey](https://github.com/odoo/enterprise/blob/17.0/web_studio/static/src/client_action/view_editor/editors/utils.js#L132) based on the field type. Because the signature widget did not declare binary as a supported field type, it was always filtered out for fields of type binary. Thus Studio treated the field like any normal binary field and excluded the signature option. After this commit: ------------------ The signature widget is correctly exposed as a supported widget for fields of type binary. When adding an existing signature field to the view (with developer mode enabled), Studio now shows signature in the widget list. <img width="1917" height="934" alt="image" src="https://github.com/user-attachments/assets/079e0a17-ff5a-4dc6-a12d-e02b9cad013e" /> Why this fix is needed: ---------------------- Signature fields are stored as binary, but they require the dedicated signature widget to render correctly. By marking binary as a supported field type for the signature widget, Studio can properly detect and offer the widget during field configuration. Given that this widget is very domain-specific and not intended for general binary fields, it was not added to [web_studio/static/src/client_action/view_editor/editors/sidebar_safe_fields.js](https://github.com/odoo/enterprise/blob/17.0/web_studio/static/src/client_action/view_editor/editors/sidebar_safe_fields.js) though this may be reconsidered after this fix the option is accessible only when the debugger mode is on, if want to show this widget to all the binary type fields even when the debugger mode is off the we'll have to add it to this file. OPW : 5260188 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237287
This update ensures the kiosk payment system only uses payment methods explicitly configured for that specific kiosk setup. Previously, the kiosk would incorrectly prompt for online payment options even if none were set up. This change prevents errors and improves the kiosk's functionality.
Original PR description
pos_self_order*: pos_online_paymnet_self_order, pos_self_order_razorpay, pos_self_order_stripe Ensure the kiosk only uses payment methods that are explicitly configured. **Steps to reproduce:** - Set up an online payment method (do not assign it to the kiosk) - Open a kiosk session. - Try to validate an order. **Issue:** - The kiosk prompts for an online payment method, even though none are configured. **Fix:** - Restrict the kiosk to use only the payment methods explicitly configured in its settings. - Prevent loading of any unconfigured payment methods to the kiosk. Task: 4911495 Related: https://github.com/odoo/enterprise/pull/89490 Forward-Port-Of: odoo/odoo#237452 Forward-Port-Of: odoo/odoo#217467
This update prevents kiosks from requesting unavailable payment methods, ensuring a smoother customer experience. Previously, kiosks would incorrectly prompt for online payments that weren't configured. Now, the kiosk is restricted to only using payment methods explicitly set up for self-order operations.
Original PR description
Ensure the kiosk only uses payment methods that are explicitly configured. **Steps to reproduce:** - Set up an online payment method (do not assign it to the kiosk) - Open a kiosk session. - Try to validate an order. **Issue:** - The kiosk prompts for an online payment method, even though none are configured. **Fix:** - Prevent loading of any unconfigured payment methods to the kiosk. Task: 4911495 Related: https://github.com/odoo/odoo/pull/217467 Forward-Port-Of: odoo/enterprise#100547 Forward-Port-Of: odoo/enterprise#89490
This update fixes an issue where the hint and power buttons incorrectly appeared in the HTML editor when a block contained a tab. The change ensures these buttons are only visible when a block contains formatting tags, improving the user experience and consistency of the editor. This resolves a minor visual inconsistency.
Original PR description
Description of the issue this PR addresses: - Hint and power buttons are incorrectly shown or hidden in empty blocks when the block contains a Tab or only empty formatting tags (`<strong>, <em>, <u>, <s>`). Current behavior before PR: - Pressing Tab in an empty block leaves the hint and buttons visible. - Empty paragraphs containing only formatting tags do not show the hint and buttons. Desired behavior after PR is merged: - Hint and power buttons are not shown when a block contains a Tab. - Hint and power buttons are correctly visible when a block contains only empty formatting tags. task-5062294 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237279 Forward-Port-Of: odoo/odoo#230979
This update ensures Odoo correctly formats invoice data for Hungarian Electronic Data Interchange (EDI) transactions. Previously, the system incorrectly included state names instead of the required province codes as defined by Hungarian tax regulations. This change aligns with the latest EDI documentation, improving data accuracy and compliance.
Original PR description
Purpose: According to documentation, in region tag in address details, we need to send that county's province code as per the ISO 3166-2 alpha 2 standard. E.g. 'HU-BU'. But we were sending state's name E.g. 'Budapest'. But since region tag is not mandatory for edi, we choose not to send that. Before this commit: In region tag, state's name was sent. After this commit: We stopped sending region tag. EDI Documentation(page-87): https://onlineszamla.nav.gov.hu/files/container/download/2025.10.09.%20EN_Online%20Invoice%20System%203.0%20Interface%20Specification%20.pdf task-5270199 Forward-Port-Of: odoo/odoo#236218
This update resolves an issue that caused payslips to fail to generate due to missing data within the system. The fix ensures data retrieval is more robust by using a 'get' function with a default value, preventing errors and improving the reliability of payroll processing. This ensures consistent and accurate payslip generation.
Original PR description
Bug: When generating payslips, there is a traceback with keyerror. Cause: We were getting info from a dict but keys could be not present. Fix: Use get instead, with a default value. Forward-Port-Of: odoo/enterprise#99245
This update resolves an issue where alerts added to field descriptions during the checkout process couldn't be edited. The fix utilizes the editor's built-in insert command to ensure alerts are correctly placed within editable text fields, improving the user experience for adding feedback.
Original PR description
Problem: When adding an alert inside a field description in the Extra Step page of the checkout process, the inner content of the alert cannot be modified. Cause: In…
Problem:
When adding an alert inside a field description in the Extra Step page of the checkout process, the inner content of the alert cannot be modified.
Cause:
In
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js#L784-L789 the logic determines the block using:
`this.closestElement(range.endContainer, 'p, div, ol, ul, cl, h1, h2, h3, h4, h5, h6');` Since the field description template is:
```html
<div class="s_website_form_field_description small form-text text-muted"
contenteditable="true">
text
</div>
```
and the selection occurs within the text (direct child of the editable `div`), the computed `block` becomes the editable area itself. As a result, the cloned alert is inserted *after* the editable area: `block.after($clonedBody[0]);`, making it non-editable.
Solution:
Use the editor’s built-in `insert` command instead of manually inserting clones. This ensures the alert is correctly inserted within the editable region.
Steps to reproduce:
1. Enable "Extra Step During Checkout" in Settings.
2. Open Website → add a product to the cart → proceed to checkout.
3. In the "Extra info" step, open the editor.
4. Select the "Give us your feedback" field.
5. Enable "Field" → "Description".
6. Run the "/alert" command in the description. → The alert content cannot be edited.
opw-5184309
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#234905
Forward-Port-Of: odoo/odoo#232910This update corrects a bug where archived users were incorrectly sending out automated follow-up emails related to invoices and partners. The fix ensures that follow-up emails are only sent by active users, preventing confusion and ensuring accurate communication. This improves the reliability of our automated customer outreach.
Original PR description
### Issue: If an archived user is set as the Sales person on an invoice or as the followup responsible on a partner, it will be the one sending the automatic followups. ### Steps to reproduce: - Create a partner and an overdue invoice for this partner - Change the "Salesperson" of the invoice to another user - Archive this user - Accounting > Customer > Followup Reports - Click on the partner created earlier - Click the actions and "Process Automatic Follow-ups" - [17.0] Traceback - [18.0+] The sent message is from the user that was archived ### Cause: `_get_followup_responsible()` does not check is the users it returns are active or not. ### Solution: Create an iterable with all the possibilities and iterate on it to return the first active user in the list. Fallback on `self.env.user`. opw-5153159 Forward-Port-Of: odoo/enterprise#100465 Forward-Port-Of: odoo/enterprise#98807
This update resolves a recurring problem where the website tour wasn't consistently displaying correctly. The previous fix only reduced the frequency of the issue, but this commit addresses the underlying cause of the problem – a race condition related to the website builder. This ensures the tour functions reliably for all users.
Original PR description
Tour added in that [commit], was previously failing and the earlier [fix] only reduced the frequency of failures. However, it still occasionally fails due to race conditions of the iframe becoming ready and the moment the builder opens the block tab after the iframe has been reloaded. This commit aims to fix it. [commit]: https://github.com/odoo/odoo/commit/a5455bf [fix]: https://github.com/odoo/odoo/commit/0a9522792cc0e18a895c0589f34977123d091d1a runbot-233438
This update ensures the Sign app meets legal requirements for U.S. companies. It now alerts users when the sender is based in the U.S., offering the option to request a paper copy of signed documents – a necessary step for ESIGN Act compliance. This update strengthens our legal protections and user trust.
Original PR description
Previously, the Sign app did not comply with the ESIGN Act. It now notifies users when the sender company is U.S.-based that they can request a paper copy of a signed document, ensuring ESIGN Act compliance. task-5166918 Forward-Port-Of: odoo/enterprise#100618 Forward-Port-Of: odoo/enterprise#97163
This update resolves issues with Viva Wallet integrations, specifically preventing duplicate notifications and late processing of payment information. By switching to a direct websocket connection and filtering webhook events, the system now handles concurrent requests more reliably, ensuring smoother transactions.
Original PR description
When using many Viva terminals linked to the same DB, there could be many serialization errors due to concurrent writes to the DB. This is because the webhook controller writes to the…
When using many Viva terminals linked to the same DB, there could be many serialization errors due to concurrent writes to the DB. This is because the webhook controller writes to the `viva_wallet_latest_response` field of the payment method. The webhook request would be automatically retried later, but this could result in duplicate notifications being sent to the POS, or notifications being handled too late. This commit stops using the `viva_wallet_latest_response` field, instead sending the information directly via the websocket to the POS. Only the required information is sent to reduce the size of the message. In addition, there are two other minor fixes: - In the event that the initial payment request to Viva failed, the POS will no longer poll the payment status (this resulted in a Session ID not found error). - The webhook controller will now check the event type it receives, and only process the 'Transaction Payment Created' events. This should prevent any unintended behaviour if other webhooks are set up in Viva. opw-5226966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237411 Forward-Port-Of: odoo/odoo#236454
This update corrects a bug in the demo kiosk feature of the Odoo Point of Sale system. Previously, the kiosk incorrectly displayed the payment screen, causing issues with the ordering process. This change ensures the demo kiosk always uses the correct 'each' payment mode when in kiosk mode, resolving this unexpected behavior.
Original PR description
The field `self_ordering_pay_after` should always be `each` when the `self_ordering_mode` is set to `kiosk`. This is enforced in the `write` method. However, the demo kiosk is created with a `self_ordering_pay_after` value of `meal`, until the `write` method is run. This results in behaviour such as the payment screen being skipped when it is not expected to. This commit sets the correct `self_ordering_pay_after` value of `each` when creating the demo kiosk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237521
This update resolves a usability issue in the annual corporate tax return reports by adding 'reviewed bubble' and 'Mark as completed' buttons. These additions streamline the reporting process for users, ensuring accurate and timely completion of tax returns. This improves the overall efficiency of the financial reporting workflow.
Original PR description
Missing: - reviewed bubble - Mark as completed button Forward-Port-Of: odoo/enterprise#100039
This update corrects a display issue where the 'Due Date' column disappeared in the phone view of invoices. The problem stemmed from conflicting CSS styles, which caused incorrect column titles. This ensures the 'Due Date' is consistently visible and correctly labeled across all device views.
Original PR description
****Behavior:****
When switching to phone view, the 'Due Date' column name dissapears but the values stay, which causes every further column of the table to have the wrong title.
The removal of the Due Date column is intended, the issue happens beacause the 't-att-class' specifying the condition to make values red was overriding the initial 'class' specifying the behavior in phone view.
**Steps to reproduce:**
- Create an Invoice for the current user
- Go to Website -> User -> My Account -> Your Invoices
- switch to phone view (reduce to less than 768px if not initially the case)
- You'll see the 'Due Date' column name dissapear and the value shift to the next column name ('Amount Due')
opw-5239794
Forward-Port-Of: odoo/odoo#235474This update resolves an issue preventing the successful installation of the UK Construction Industry Scheme (l10n_uk_reports_cis) when using branch companies. The fix prevents the creation of duplicate account codes, ensuring proper installation and functionality for UK businesses with branches.
Original PR description
Before this commit: Steps 1) Create a UK localization company 2) Create a branch for that company 3) Try to install UK - Construction Industry Scheme (l10n_uk_reports_cis) => A Validation Error is raised with the message `Account codes must be unique. You can't create accounts with these duplicate codes: 220001, 220101, 220201`, This occurs because the `_l10n_uk_reports_cis_post_init()` method is creating accounts for each UK company even if they aren't root companies (branch). After this commit: UK - Construction Industry Scheme (l10n_uk_reports_cis) is installed successfully with UK companies that have branches. opw-5326079 Forward-Port-Of: odoo/enterprise#99901
This update fixes an issue where documents and moves were incorrectly linked across companies in a multi-company setup. By adding the company ID during attachment creation and searches, the system now accurately assigns documents to the correct company, preventing errors and ensuring data integrity. This improves the reliability of our multi-company functionality.
Original PR description
Behavior before: In a multi-company setup, fetching documents could include records from different companies based on VAT numbers. When creating attachments or searching for existing moves, the company ID was not properly considered, leading to incorrect company assignments and failed move creation. Behavior after: Documents and moves are now created and searched within the correct company context by explicitly including the company ID. Root Cause: The company ID was missing in both the attachment creation and the domain used to search for existing moves, causing cross-company mismatches. opw-4929985 Forward-Port-Of: odoo/enterprise#99192
This update resolves an issue where exporting invoices that hadn't been sent resulted in blank ZIP files. The fix limits the Export ZIP option to the list view, streamlining the process. Further improvements are being considered to handle non-sent invoices more effectively, such as generating PDFs on demand or displaying a helpful error message.
Original PR description
- Earlier, when downloading an invoice, invoices that were never sent didn’t have a generated PDF. This happened because the method _get_invoice_legal_documents_all had allow_fallback=False by…
- Earlier, when downloading an invoice, invoices that were never sent didn’t have a generated PDF. This happened because the method _get_invoice_legal_documents_all had allow_fallback=False by default. As a result, those invoices returned no attachments, leading to blank pages or missing files in the ZIP download — since the invoices weren’t sent and no fallback was allowed. **Steps to reproduce:** **1:** Go to Invoices **2:** Try to use Export ZIP for any non-sent invoice → you’ll see a blank page **What this patch does:** - It limits the Export ZIP option to the list view only. This doesn’t fix the missing PDF issue, but it makes sense — having “Export ZIP” on every single invoice form view isn’t useful. **Possible improvements to consider:** **1:** Restrict Export ZIP so it’s only available for sent invoices. This would improve performance since sent invoices already have PDFs stored in the filestore. **2:** Allow a fallback for invoices that haven’t been sent, so their PDFs are generated when exporting — but this may cause performance issues if too many non-sent invoices are processed at once. **3:** Instead of showing a blank page for non-sent invoices, show a user-friendly error message. (I noticed this was in the original commit odoo/odoo@c81ab09d0404cc57f48c202360361a1700f060db where this was introduced but was later removed — not sure why.) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where the PDF report title for DIAN support documents was incorrectly displayed after the document was stamped by the DIAN. The change reordered a key condition to ensure the correct 'Documento Soporte' title is consistently used, aligning with DIAN requirements. This ensures accurate reporting for Colombian tax filings.
Original PR description
Steps: - Create and confirm a vendor bill with 'DIAN Support Documents' journal - Print the PDF — it display 'Documento Soporte' as document title - Send the document to the DIAN and print it again -> the returned PDF with the DIAN stamp now shows 'Factura Electrónica de Venta', it should still be 'Documento Soporte' Cause: In `AccountMove._get_name_invoice_report` we return the name of the report depending on specific conditions, but the order of the conditions prevent to get the right report name as soon as the document has been accepted by DIAN. Fix: Modifying the order of the condition, to redirect to the right report, even when the support document has been accepted by DIAN opw-5119858 Forward-Port-Of: odoo/enterprise#99028
This update fixes an issue where long participant names in the call sidebar would cause the layout to break, leading to a distorted view. Now, participant names are handled safely, ensuring the call sidebar remains properly formatted and functional. This improves the user experience and prevents visual disruptions.
Original PR description
**Description of the issue this PR addresses:** Prevent call participant name overflow **Current behavior before PR:** Before this PR, long participant names in the call sidebar could overflow their container, distorting the layout and causing the call action icons to shift incorrectly. **Desired behavior after PR is merged:** This PR ensures long names are now handled safely, preventing any layout breakage in the call participants sidebar. Before: <img width="302" height="125" alt="image" src="https://github.com/user-attachments/assets/309d3a0e-8304-43ee-ab22-0d7ee2883fc1" /> After: <img width="289" height="119" alt="image" src="https://github.com/user-attachments/assets/6c838fff-70d2-443a-b651-b985afe9cea6" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237327
This update resolves a technical issue that previously caused crashes when creating binary files within the Web Studio module. The fix prevents a problem with parallel field creation, ensuring stable operation of this key feature. This improves the reliability of the Web Studio interface for users.
Original PR description
Before this commit and subsequently to commit odoo/enterprise@75db3379655dc889b31ad34c66332f5a21f8cff4 creating a related binary field crashed because of the parallel creation of the filename related field. After this commit, this is fixed. opw-5237866
This update fixes a translation error in the Netherlands (l10n_nl) module, specifically regarding the description of the 9% ST tax. The incorrect translation 'TVA' was corrected to the accurate 'ST tax' description, ensuring proper reporting and compliance with Dutch tax regulations. This ensures accurate financial reporting for Dutch customers.
Original PR description
The traduction of te description of the 9% ST tax was wrong and was TVA to get back on a sale tax task-5217323 Forward-Port-Of: odoo/odoo#237467 Forward-Port-Of: odoo/odoo#236655
This update fixes a bug where the 'Late,' 'Today,' and 'Future' filters in the Activity Menu didn't correctly display Approval requests. The fix adds necessary filters to the Approvals search view, ensuring these filters now function consistently and align with other Odoo modules.
Original PR description
Issue: - In the Activity Menu, clicking "Late", "Today", or "Future" did not filter Approval requests and always returned all records. - The Approvals search view lacked the activity filters that these context defaults rely on. Fix: - Added the invisible activity filters (overdue, today, upcoming_all) to the Approvals search view. - Filters use `my_activity_date_deadline` to match Odoo's standard deadline-based activity filtering. Impact: - Activity Menu filtering now works correctly for Approvals and aligns with behavior in other modules. Task: 5261406 Forward-Port-Of: odoo/enterprise#100514 Forward-Port-Of: odoo/enterprise#99632
This update resolves a visual issue where the course search dropdown was incorrectly positioned above the search input on the homepage. The fix ensures the dropdown appears correctly within the search form layout, improving the user experience.
Original PR description
Scenario: go to homepage > Courses > one "View all" > type in search Result: dropdown with result is shown over the search input Issue: search form is in flex layout, but the dropdown is displayed in absolute so it is outside of flex flow and is positionned at the top-right of the form container. History: - before bootstrap 4 (odoo 15): the search form had a flex layout, but bootstrap dropdown used "top:100%" so were positionned at the bottom of it. - as of bootstrap 5 (odoo 16): the form kept a flex layout, but bootstrap dropdown now used "position: absolute" with unset top putting them below the search item in a block container, but over it in a flex layout. Fix: when the search bar is displayed, display it as block. opw-4735257 Forward-Port-Of: odoo/odoo#206909
This update adjusts the spacing between message text and reactions in notifications, resolving a previous issue where the UI appeared cramped. By removing a negative margin, the notification design is now cleaner and more visually comfortable for users. This improves the overall user experience.
Original PR description
Before this commit, the spacing between the text content of a message of type notification and the reactions was too small and resulted in the UI feeling cramped. This commit fixes the issue by removing the negative top margin in message reactions for messages that don't have enough padding. | Before | After | | ------------- | ------------- | | <img width="207" height="223" alt="Pasted image 20251124144956" src="https://github.com/user-attachments/assets/f23c070c-6253-440a-8b93-7b546daabda3" /> | <img width="202" height="236" alt="image" src="https://github.com/user-attachments/assets/e366a2ba-f851-4676-b108-bebf2fb12ec8" /> | task-5344759 Forward-Port-Of: odoo/odoo#237120
This update fixes an issue where search results on the website were not displaying correctly when the number of results exceeded the page limit. The system now automatically redirects users to the last page of results, ensuring all relevant information is shown. This improves the user experience and prevents missed data.
Original PR description
Scenario: - enable website_studio - go to contact -> open studio -> website - add a listing and open it on website - go to page 2 and search a specific terms with less than 20 results Result: we see "5 results" in the search bar, but no result are shown and the pager is hidden. Cause: the pager is hidden since there is only one page, and we are currently displaying the records of page 2 that do not exist. Fix: if we detect that we are on a page over the last page, redirect to the last page. Eg. if there is 2 pages and we are in page 500, redirect to page 2. opw-5008556 Forward-Port-Of: odoo/odoo#236600 Forward-Port-Of: odoo/odoo#223447
This update fixes an issue where Shift + Click within a table cell didn't correctly select text, resulting in an incorrect selection range. The fix ensures Shift + Click behaves like a standard browser, providing a consistent and expected text selection experience. Additionally, the issue of selection flickering during table resizing has been resolved.
Original PR description
**Current behaviour before PR:** Steps to reproduce: - Create a table - Write a sentence in one of the cell - Put your caret somewhere in your sentence (e.g. "He[]llo wold") - Shift + click in the same sentence (e.g. "Hello wor[]ld") The expect result should be "He[llo wor]ld", but it's "[Hello wor]ld". This issue happens because in `onMousedown` method of table_plugin, cursor is set to the starting of `anchorNode`, which leads to wrong selection on shift + click. **Desired behaviour after PR:** This PR ensures that Shift + Click sets the selection in the same way as the default browser behavior. task-5152807 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237168 Forward-Port-Of: odoo/odoo#230716
This update corrects a technical issue that prevented users from sending E-Factura (SPV) invoices in the Romanian localization (l10n_ro_edi) module. The problem stemmed from a mismatch in how bank information was accessed, leading to an error. This fix ensures smooth E-Factura processing for Romanian invoices.
Original PR description
Same issue already fixed for 18.4+ here: https://github.com/odoo/odoo/pull/231399 Issue: When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an…
Same issue already fixed for 18.4+ here: https://github.com/odoo/odoo/pull/231399 Issue: When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an exception: state_id not defined for res.bank. Repro Steps: 1- Create invoice for romanian localization. 2- Link payment account to invoice. 3- Add bank to payment account. 4- Confirm and send invoice with "Send E-Factura SPV" checked. Cause: The state field is defined differently for res.bank and res.partner. res.partner uses state_id, while res.bank uses state. The code that retrieves addresses assumes the same field for both, leading to an exception when accessing state for res.bank. Fix: The fix checks the type of the input and selects the appropriate field (state or state_id) accordingly. opw-5362000 (cherry picked from commit a2af8d434bfc7f77008959c8179e8f158bcf9e93) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237615
This update adds a warning message to bank statement lines when an analytic distribution is required. Previously, users weren't alerted to this requirement, potentially leading to errors. Now, users will receive a clear warning, guiding them to set up the necessary analytic distribution plan.
Original PR description
When setting the account on a bank statement line, analytic distribution might be required due to a mandatory plan. Before this commit, the user had no idea if the analytic is required or not. After this commit, lines that required analytic distribution will have a warning directing the user to set it. task-5055351 This is a backport of: https://github.com/odoo/odoo/commit/c337d97a3e06db37a316c4020261a797df4c6a1d Enterprise PR: https://github.com/odoo/enterprise/pull/100494 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237368
This update adds a warning to bank statement lines when an analytic distribution is required. Previously, users weren't alerted to this requirement, potentially leading to incorrect accounting. Now, users will receive a clear warning, guiding them to set up the necessary analytic distribution plan.
Original PR description
When setting the account on a bank statement line, analytic distribution might be required due to a mandatory plan. Before this commit, the user had no idea if the analytic is required or not. After this commit, lines that required analytic distribution will have a warning directing the user to set it. task-5055351 This is a backport of: https://github.com/odoo/enterprise/commit/00396d24114b8747ff73ae60f032b630ce88c7a4 Community PR: https://github.com/odoo/odoo/pull/237368 Forward-Port-Of: odoo/enterprise#100494