Daily updates from Odoo
Thursday, November 27, 2025
162 changes
22 changes
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
20 changes
Resolved issues and error corrections
This update resolves a technical issue that caused errors when users closed payment tabs in the Point of Sale (POS) system. Specifically, clearing payment lines resulted in a system error. The fix ensures the system gracefully handles scenarios with no selected payment line, defaulting to the first payment line if needed, improving the overall POS 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 an issue where signature fields added to views within Odoo's Studio were not correctly configured. The signature widget was missing from the available options. Now, signature fields added to views will correctly display the signature widget, ensuring accurate field configuration and functionality.
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 Odoo correctly formats invoices for Hungarian e-invoicing (l10n_hu_edi) by removing unnecessary state information. According to regulations, only the province code (HU-BU) is required, and this change aligns Odoo with the latest Hungarian tax authority specifications.
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 correctly due to missing data within a configuration dictionary. The fix uses a safer method to access dictionary values, preventing errors when keys are absent. This ensures more reliable and consistent payroll processing.
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 insertion command to ensure alerts are correctly placed within editable text areas, 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 resolves an issue where invoices weren't being created for alternative sale orders generated from upsells. The fix ensures the correct invoice date is calculated by copying the previous upsell order's invoice date, now allowing invoices to be created successfully after confirming the alternative order.
Original PR description
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the…
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued. Steps to reproduce: - Create an upsell order of a subscription. - Click Create Alternative to generate an alternative SO. - Confirm the SO and click on Create Invoice to make the invoice - This will throw an error of defferred end date Cause: - The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO. - Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error. Fix: - Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation. Impact: Invoices for alternative upsell sale orders can now be created successfully without errors. task-5241150 Forward-Port-Of: odoo/enterprise#99831 Forward-Port-Of: odoo/enterprise#98983
This update corrects a bug where archived users were incorrectly sending out automated follow-up emails for invoices. 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 fixes a translation error in the Netherlands (l10n_nl) module. The description for the 9% ST tax was previously incorrectly translated as 'TVA' (Value Added Tax). This change ensures accurate tax reporting and compliance for Dutch businesses using Odoo.
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#236907 Forward-Port-Of: odoo/odoo#236655
This update resolves an issue where the colorpicker wasn't correctly displaying custom background colors set within Odoo. The fix ensures that all color selections, including background colors, are accurately reflected in the colorpicker interface. This improves the user experience when customizing website content.
Original PR description
Before this commit, the colorpalette for the background color would not display custom colors already on the page. The issue appeared in 17.0 and worked in 16.0 before the conversion of wysiwyg to owl. github.com/https://github.com/odoo/odoo/pull/118966 The "getEditableCustomColors" method was not forwarded and therefore we used the default function, returning nothing. Steps to reproduce the issue: - Add a snippet - Set the background / font color of the snippet to a custom color - Add another snippet - Open the colorpicker for the text color (The colorpicker have access to the custom color set above) - Open the colorpicker for the background color (The colorpicker does not have access to the custom color set above) task-3806989 Forward-Port-Of: odoo/odoo#237173 Forward-Port-Of: odoo/odoo#180335
This update corrects a bug where the search function on the recent and contacts tabs in the VoIP module wasn't properly filtering results. The fix ensures that search terms are now accurately reflected in the displayed contacts, improving user efficiency and data accuracy. This resolves a previous issue impacting contact search.
Original PR description
On recent/contacts tab, search rpc didn't take search term into account. Fix it. Task-5262162
This update fixes an issue where the PDF report title for DIAN support documents was incorrectly displaying 'Factura Electrónica de Venta' after the DIAN stamp was applied. The change adjusts the report naming logic to ensure the correct 'Documento Soporte' title is consistently used, aligning with DIAN requirements.
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 corrects a bug in the demo kiosk's payment process. Previously, the kiosk incorrectly used a 'meal' payment mode, causing the payment screen to be skipped. This change ensures the kiosk always uses the 'each' payment mode, guaranteeing the payment screen appears as expected.
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 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 the column title to be incorrectly overridden. This ensures the 'Due Date' column is always visible and correctly labeled when viewing invoices on smaller screens.
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 a previous issue that prevented the UK Construction Industry Scheme from installing correctly when used with company branches. The fix prevents the creation of duplicate account codes, ensuring successful installation and proper reporting functionality for UK businesses.
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 financial reporting and move management.
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 fixes a delay in receiving payment notifications for online PoS transactions. Previously, if a customer closed the payment page before confirmation, the PoS would wait up to 10 minutes. The fix triggers a process to ensure immediate notification, improving the order processing flow and preventing delays.
Original PR description
When paying online with the PoS if for some reason the client closes the web page before receiving the payment confirmation, the PoS would not be notified that the payment was successful. Steps to…
When paying online with the PoS if for some reason the client closes the web page before receiving the payment confirmation, the PoS would not be notified that the payment was successful. Steps to reproduce: ------------------- * Setup any online payment method in the PoS. * Open the PoS and create an order. * Proceed to payment and choose the online payment method. * Scan the QR code and close the page before receiving the payment confirmation. > Observation: The PoS will need to wait atleast 10 minutes to receive the payment notification. Why the fix: ------------ When using the online payment method, the user that scans the QR code will open a web page to complete the payment. This webpage is also responsible to poll the status of the payment. When polling the status of the payment, if the payment is successful, the server will send a notification to the PoS to update the order status. If the user closes the web page before the payment is confirmed, the PoS will not receive the notification. We will need to wait for the payment transaction `_cron_post_process` to be executed, which happens every 10 minutes. So the solution is to trigger the cron when the payment is set as done to ensure that the PoS receives the payment notification as soon as possible. opw-4925349
This update resolves an issue preventing users from creating bank statements when the chart of accounts wasn't properly configured. The fix ensures the system correctly identifies related accounts before generating statements, improving the reliability of bank reconciliation processes.
Original PR description
**Steps to Reproduce:** 1. Install the **Accounting** module without demo data. 2. In "**Chart of Accounts**", change the type of all accounts (e.g.; Expenses). 3. In "**Bank**" Journal, create a new bank statement line and try to save it. **Error:** ``` SyntaxError - syntax error at or near ")" LINE 19: AND aml.account_id IN () ``` **Cause:** A **IN** condition is evaluated with an empty tuple `AND aml.account_id IN ()`. This is due to that there are no `account_ids`. **Fix:** This commit only executes the SQL query when there are valid accounts to consider. sentry-7059353053
This update fixes a visual issue where long participant names in the call sidebar would cause the layout to break and icons to shift. The change ensures that participant names are handled correctly, maintaining a clean and functional call sidebar experience.
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 adjusts the spacing around message type notifications to improve the user interface. Previously, notifications felt cramped due to insufficient spacing between the message text and reactions. This fix removes a negative margin, creating a cleaner and more comfortable viewing 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 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, providing a better user experience for finding courses.
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
3 changes
Resolved issues and error corrections
This update resolves an issue that caused payslips to fail to generate due to missing data within the system. The fix ensures that the system gracefully handles potentially absent keys when retrieving payroll information, improving the reliability of payslip generation. This prevents disruptions to payroll processing.
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 fixes an issue where credit notes (resulting in negative amounts) weren't being included in the XBRL export of the EC Sales List report. The change ensures that all non-zero amounts, including negative ones, are now correctly generated for the report, improving data accuracy for VAT reporting.
Original PR description
To replicate: 1. Install l10n_nl_reports_sbr_icp 2. Create an european partner with a VAT number 3. Create a credit note for this partner 4. Go to Accounting > Reporting > EC Sales List 5. The negative line appears in the report 6. Click on XBRL to export the report The negative line is not included in the exported report Only non-negative positive lines are added to the report in `_generate_codes_values()`. This commit changes that to include non-zero values. opw-5220622 Forward-Port-Of: odoo/enterprise#100009
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 adjusts the report naming logic to ensure the correct 'Documento Soporte' title is consistently used, regardless of DIAN acceptance.
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
9 changes
Resolved issues and error corrections
This update fixes a bug that occurred when a user deleted a specific partner record (Collection Center - Advance Payment Service) and then attempted to install a new language. The fix ensures the system handles the scenario where a referenced record is no longer present, preventing an error and allowing users to continue operating.
Original PR description
This error occurs when the user deletes the partner and then tries to install the new language. Steps to reproduce: --- - Install `l10n_be_reports` and switch to `BE company COA`. - Open `res.partner` and delete `Collection Center - Advance Payment Service`. - Try to install another language. Traceback: --- `ValueError: External ID not found in the system: l10n_be_reports.partner_centre_de_perception_belgium` This error appears after this [commit] because it references `partner_centre_de_perception_belgium`. If that record is deleted, an error is raised.. [commit]: https://github.com/odoo/enterprise/commit/b5a935add7090d7da8daee28618f08981de24613 sentry-7039699174 Forward-Port-Of: odoo/enterprise#99872
This update fixes an issue where the 'Out of Contract' duration was incorrectly calculated, leading to inaccurate reporting. The change ensures that contract dates align with the payslip period, providing more reliable payroll data and reducing potential discrepancies. This improves the accuracy of employee time and cost tracking.
Original PR description
### Steps to Reproduce 1. Create a contract ending early in the year (e.g., February). 2. Compute a payslip for a much later period (e.g., November). 3. The "Out of Contract" line shows an excessive number of days (counting from Feb to Nov). ### Reason The previous logic calculated the start/end dates based solely on the contract boundaries (`version.date_end + 1`), ignoring whether those dates actually fell within the current payslip's period. ### Solution Constrain the calculated "Out of Contract" dates using `max()` and `min()` to ensure they never exceed the payslip's `date_from` and `date_to`. Task: 5245301
This update fixes an issue where table numbers were difficult to see in dark mode due to similar background and table colors. The change ensures table numbers are now displayed in black, significantly improving readability and the user experience.
Original PR description
Before this commit: - In dark mode, the table number was not clearly visible because the background color and table color were too similar. After this commit: - The table number is now displayed in black for better visibility. task-5103925 Forward-Port-Of: odoo/enterprise#95446
This update resolves an issue where incoming emails weren't correctly associating with company records, leading to errors. By enforcing a company ID on quality alerts, the system now properly handles email processing and prevents data inconsistencies. This ensures accurate tracking of quality alerts based on the correct company.
Original PR description
Not having a company on the quality alert team is making incoming emails sent to the alias having a 'company_id' false, defined by the default values. If manually created, a quality alert should have…
Not having a company on the quality alert team is making incoming emails sent to the alias having a 'company_id' false, defined by the default values. If manually created, a quality alert should have a company. In order to avoid company_id issue, enforcing it to the team will add it to the default values of the alias and to the quality alert created by emails. To reproduce: 1. install `quality` 2. add a second company 3. Create 2 mail.lias.domains: company1.com company2.com And assign them to distinct company records by selecting them on the companies menu. 4. On the configuration of the quality team, add a localpart to the alias (like alias_c1, to make the address alias_c1@company1.com). Don't set a company (this field is not required anyway) 5. Send an email using the send-mail script: odoo/addons/mail/static/scripts/odoo-mailgate.py And using the `MAIL_TEMPLATE` defined in odoo/addons/test_mail/data/test_mail_data.py after setting the to the alias of the company: alias_c1@company1.com And giving a value to the following headers: - Return-path, - From, And deleting the following headers: - Cc, - Message-id 6. Error: ``` The operation cannot be completed: - Create/update: a mandatory field is not set. - Delete: another model requires the record being deleted. If possible, archive it instead. Model: Quality Alert (quality.alert) Field: Company (company_id) ``` As the company is not mandatory on the step 4. completing 159309e7c17e0ef8274d89d90bcab1b97b40023b opw-4866977
This update prevents users from attempting to record calls when the system is in demo mode. Previously, users could trigger a recording attempt even without a valid SIP session, leading to a non-functional 'record' button. This change ensures a smoother user experience and avoids unnecessary actions.
Original PR description
Follow-up of https://github.com/odoo/enterprise/commit/7832c1d72abf7e2f59fbb97df06afa0ab062da5f (see https://github.com/odoo/enterprise/pull/99428#pullrequestreview-3471602481). Instead of having a factory method for the session recorders, we now give some more responsibility to the SessionRecorder constructor itself.
This update fixes an issue where tax return amounts were incorrectly calculated for section reports, specifically in the LU tax return. The change ensures the correct return periodicity is used by retrieving the return type from the section source, resolving a discrepancy between report types. This ensures accurate tax reporting.
Original PR description
We have some reports with sections, like l10n_lu generic tax return.
Since account.return are born, when submitting the lu tax return, the periodicity is wrongly
computed, because of the self in `_init_options_return_periodicity` is the section report, not the main,
but the account.return.type is set with report_id = main report
Step to reproduce:
With a LU company:
1. Create a journal entry for a previous period
2. Submit the tax return for the same period
3. The amount shown is the amount of the current month
Solution: use options['sections_source_id'] to fetch the return_type instead of self.return_type_ids
opw-5163352
Forward-Port-Of: odoo/enterprise#100353
Forward-Port-Of: odoo/enterprise#100063This update fixes a warning appearing in the work entry planning module due to group access issues. The fix involves restructuring the module's dependencies to avoid conflicts when other modules (like hr_work_entry_enterprise) are removed or reinstalled. This ensures the work entry planning functionality continues to operate correctly.
Original PR description
purpose: solving the runbot warning happening here because of group access for `work_entry_source` field: https://runbot.odoo.com/odoo/runbot.build.error/233332 steps to reproduce: - install hr_payroll and hr_work_entry_planning - uninstall hr_work_entry_enterprise or hr_gantt -reinstall hr_work_entry_enterprise or hr_gantt fix: made the module `hr_work_entry_planning` dependant on `hr_work_entry` instead of `hr_work_entry_enterprise` so it doesn't get affected by removing `hr_work_entry_enterprise` or `hr_gantt` (it doesn't depend on anything from these modules) task-id: 5177289
This update fixes an issue where the EC Sales List report menu was incorrectly located. The menu has been moved to the data folder, ensuring it appears correctly within the Odoo Enterprise application. This improves the user experience for reporting on EC sales data.
Original PR description
The menu record was wrongly stored under views. It is now moved to the data folder.
This update fixes an issue where archived users were incorrectly sending automatic follow-up emails for invoices. The code has been updated to ensure that only active users are designated as the sender for these follow-ups, improving email reliability and preventing confusion. This change ensures that follow-up emails are sent by the correct, active user.
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
21 changes
Resolved issues and error corrections
This update resolves a technical issue that caused errors when users closed payment tabs in the Point of Sale (POS) system. Specifically, clearing zero-amount payment lines triggered a problem. The fix ensures the system gracefully handles scenarios with no selected payment line, defaulting to the first payment line if needed, improving stability and preventing errors.
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 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 resolves an issue where the OSS Tax mapping feature would fail if a tax group was missing. The fix ensures the system correctly handles scenarios where tax group information is incomplete, preventing errors and improving the reliability of the tax calculation process. It updates the system to account for both payable and receivable tax accounts when searching for tax groups.
Original PR description
**Steps to Reproduce:** 1. Install the "**Belgium - Accounting**" (`l10n_be`) module with demo data. 2. Switch to the company - **BE Company CoA**. 3. Remove the "**Tax Payable Account**" from all…
**Steps to Reproduce:** 1. Install the "**Belgium - Accounting**" (`l10n_be`) module with demo data. 2. Switch to the company - **BE Company CoA**. 3. Remove the "**Tax Payable Account**" from all the tax groups. 4. In setting, under _EU Intra-community Distance Selling_ section, click on "**OSS Tax mapping**". **Error:** `ValueError - External ID not found in the system: account.1_oss_tax_group_20_0_SK` **Note:** If only the "**Tax Receivable Account**" is removed from all tax groups. The following error occurs; `TypeError: expected string or bytes-like object` **Cause:** At [1], the system searches for a tax group with a defined `tax_payable_account_id`. Also, at [2], the `oss_tax_group_local_xml_id` is created only when the tax group (tg) exists. However, when no tax group is found, the code tries to fetch the missing xml id at [3], resulting in a ValueError. Similarly, when the receivable account is missing, the execution also fails, leading to a TypeError. **Fix:** This commit updated the tax group search condition to include both `tax_payable_account_id` and `tax_receivable_account_id`. Also, added skipping further processing if the related tax group is not found. [1] - https://github.com/odoo/odoo/blob/fb30a9b12667f6b1195e6bd6f8db69f44ad5ca2a/addons/l10n_eu_oss/models/res_company.py#L47-L49 [2] - https://github.com/odoo/odoo/blob/fb30a9b12667f6b1195e6bd6f8db69f44ad5ca2a/addons/l10n_eu_oss/models/res_company.py#L115-L146 [3] - https://github.com/odoo/odoo/blob/fb30a9b12667f6b1195e6bd6f8db69f44ad5ca2a/addons/l10n_eu_oss/models/res_company.py#L164 sentry-6932155430
This update ensures that signature fields added to views within Odoo's Studio correctly display the signature widget. Previously, Studio incorrectly defaulted to a standard binary widget for signature fields. This fix allows users to properly configure signature fields within Studio, improving usability and functionality.
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 resolves an issue where the 'Export ZIP' function on customer invoices was failing when the invoice hadn't been sent. The fix ensures that this button is only available for invoices that have been successfully processed and prepared for sending, improving the user experience.
Original PR description
**Steps to reproduce:** * Install the *Accounting* module. * Create a customer invoice. * Post the invoice. * Click the *gear* icon → **Print** → **Export ZIP**. * Observe that the invoice opens a blank page. **Issue:** * Clicking **Export ZIP** on an unsent invoice opens a blank page. **Cause:** * The `account.move.send` model returns an empty dataset when the invoice is not sent, leading to an empty export result. **Fix:** * Add a condition to display **Export ZIP** only when the invoice has been sent. --- opw-5245483 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#235934
This update resolves an issue where creating annotations in the Arabic language resulted in a system error. The problem stemmed from how Luxon was formatting dates, specifically using Arabic numerals which are not recognized by PostgreSQL. The fix ensures dates are formatted with the standard Latin numeral system, allowing annotation creation to function correctly for users in Arabic locales.
Original PR description
Steps to reproduce: ------------------- 1. Install `account_reports` 2. Switch the user language to Arabic 3. Go to Accounting > Reporting > General Ledger 4. Click on the 3-dots > Annotate 5. Create a new annotation Issue: ------ A traceback occurs: ```python psycopg2.errors.InvalidDatetimeFormat: invalid input syntax for type date: "٢٠٢٥-١١-٣٠" LINE 1: ... '2025-11-14 07:05:06.400902', 2, '٢٠٢٥-١١-٣٠', ... ``` Cause: ------ In Arabic locale, Luxon formats dates using the Arabic numbering system, which is not a valid date literal for PostgreSQL, leading to an invalid date syntax error. Solution: --------- Use the Latin numbering system (`latn`) when formatting the annotation date. Ticket [link](https://www.odoo.com/odoo/project.task/5244656) opw-5244656 Forward-Port-Of: odoo/enterprise#99493
This update fixes a reporting issue on the Purchase Dashboard where completed receipts were incorrectly included in 'Not Acknowledged' and 'Late Receipt' counters. The fix ensures the dashboard accurately reflects only pending acknowledgments and genuinely late receipts, providing more reliable purchase tracking.
Original PR description
Before this commit: ------------------------- - On the Purchase Dashboard, the 'Not Acknowledged' and 'Late Receipt' counters also included purchase orders whose receipts had already been done. - For…
Before this commit:
-------------------------
- On the Purchase Dashboard, the 'Not Acknowledged' and 'Late Receipt' counters
also included purchase orders whose receipts had already been done.
- For Not Acknowledged:
- Such POs should be implicitly considered acknowledged once their receipts
are done, but they were still shown at the counter.
- Additionally, unacknowledged POs that were locked were incorrectly excluded
from the counter.
- For Late Receipt:
- POs with received products were incorrectly counted as late, even
though their receipts were already done.
- Locked POs with late receipts were also excluded from the counter, which was
an incorrect behavior.
Steps to reproduce:
-------------------------
1. Install the 'purchase_stock' module.
2. Open Purchase module.
3. On the Purchase Dashboard, click on the 'Not Acknowledged' or 'Late
Receipt' card.
4. Notice that POs whose receipts are already completed still appear in the
counters and some locked POs that are unacknowledged or have late receipts
are missing from the counters
Cause of the issue
-------------------------
- The domains for both Not Acknowledged and Late Receipt counters only relied on
the purchase order state without checking whether the receipts were done.
- As a result, POs with done receipts were still included in the counters, while
some locked POs were incorrectly excluded.
After this commit:
-----------------------
- Updated the search domains for both counters to properly exclude POs whose
receipts are done.
- The action_done method now triggers action_acknowledged, ensuring that any
unacknowledged POs with completed receipts are automatically marked as
acknowledged and excluded from the Not Acknowledged counter. Locked POs that
remain unacknowledged will still correctly appear in the counter.
- Now the POs with received products are no longer shown as late once their
receipts are completed and Locked POs with late receipts will now correctly
continue to appear in the counter.
- This ensures that the dashboard accurately reflects only pending
acknowledgments and genuinely late receipts, helping users track POs in
the correct state.
Task ID: 4874116
Forward-Port-Of: odoo/odoo#237305
Forward-Port-Of: odoo/odoo#224180This update fixes an issue where channel names weren't displaying correctly in the invite dialogs accessed from the sidebar. The change ensures the correct channel name is shown by using the channel's display name instead of the previous method. This improves the user experience when inviting members to channels.
Original PR description
Before this commit, certain channels whose names were computed on the client side did not appear correctly as the title of the invite dialog when opened via the sidebar actions. This commit resolves the issue by using the channel’s displayName instead of the thread.name to ensure the correct title is shown in the invite dialog. task-5357104 Forward-Port-Of: odoo/odoo#237278
This update automatically determines the sales order's VAT rate based on the warehouse location, ensuring accurate VAT calculations and compliance with VAT regulations. This eliminates manual configuration and reduces the risk of errors, improving invoicing accuracy and efficiency.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where new users joining group chats weren't receiving the correct welcome message and subtitle. The change ensures all channel types display the appropriate start message and subtitle, enhancing the user experience for group chat participants. This was achieved through a code correction and added testing.
Original PR description
Before this commit, The start message subtitle condition was incorrect for group chats, this commit corrects that condition and also add a test to cover all the channel types to show correct start message and subtitle. Before: <img width="625" height="109" alt="image" src="https://github.com/user-attachments/assets/830f9574-573f-4448-b54f-b70c8a4685ef" /> After: <img width="640" height="133" alt="image" src="https://github.com/user-attachments/assets/bcba270a-88fc-446d-9015-1125872c5748" /> Forward-Port-Of: odoo/odoo#237425 Forward-Port-Of: odoo/odoo#237292
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 selected theme, ensuring clear visibility for all users.
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 ensures that the status of a sale order is correctly updated to 'Sales Order' in the Sales module after a payment is processed through the Point of Sale (PoS) system. Previously, the status remained as 'Quotation,' leading to potential confusion and errors. This fix maintains the accurate tracking of sales orders regardless of payment method.
Original PR description
**Steps to reproduce:** - Make a quotation in the Sales module - Go to PoS, click Quotation/Order and select your quotation - Select Settle the order - Go through with the payment - Go back to the…
**Steps to reproduce:** - Make a quotation in the Sales module - Go to PoS, click Quotation/Order and select your quotation - Select Settle the order - Go through with the payment - Go back to the Quotation in the Sales module The Status widget still shows Quotation instead of Sales Order **Why the fix:** Since 18.3, the sale_order.state was not updated anymore when the state changed through the PoS. This happened because we would only change the sale_order state if there was a downpayment involved. In 18.2, we always recomputed the sale_order that was linked to the order we are currently settling. The way it is done now is part of the same way it was done in 18.2 and before, meaning we add the linked sale_order regardless of downpayments. In 18.2, we did an action_confirm on the selected sale_orders, but doing that in 18.3 will create another picking for this sale_order. This is not what we want as the picking is now handled and created by the PoS. This fix will just put the related sale orders in the "sale" state, so that users can no longer confirm it in the sales modules, which would create a second picking and create duplicates. opw-5033979 Forward-Port-Of: odoo/odoo#237213 Forward-Port-Of: odoo/odoo#226008
This update fixes an issue where sale order previews incorrectly displayed a down payment percentage even after the online payment setting was turned off. The change ensures the preview accurately reflects the currently active payment percentage, preventing confusion and ensuring accurate order previews for sales teams. This improves the user experience and data accuracy.
Original PR description
****Behavior:**** **Current:** When setting the online payment percentage to something else than 100% and then turning off the setting. The preview of sale orders still show a down payment with the percentage set previously. This is caused because there is no check on wheter the setting is activated or not in the template. ****Steps to reproduce:**** - In Settings->Sales: activate Online Payment. - Set it to somethings else than 100% then save. - Turn the setting off then save. - Create a Sale Order. - There will be a down payment of 0€ with the percentage you set in parentheses. opw-5254575 Forward-Port-Of: odoo/odoo#236763
This update corrects a bug where archived users were incorrectly sending out automated follow-up emails for 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 corrects a bug in the demo kiosk's payment process. Previously, the kiosk incorrectly used a 'meal' payment mode, causing the payment screen to be skipped. This change ensures the kiosk always uses the 'each' payment mode when in kiosk mode, guaranteeing the correct payment flow.
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 issues with Viva wallet integrations across multiple terminals by streamlining data transmission. Previously, concurrent database writes caused errors, but now information is sent directly via websocket, reducing message size and improving reliability. Additionally, the system now handles payment status polling and webhook events more efficiently.
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 streamlines the print experience by removing interface elements that aren't relevant in printed documents, specifically within the accounting and sales modules. The changes enhance print quality and reduce clutter, ensuring only essential information is included in printed reports and documents.
Original PR description
*: account, sale This change adjusts layouts for print mode and removes interface parts that do not belong on printed documents. Form View: - Removed border on the sheet - Removed actions line at end of list the list view (`o_field_x2many_list_row_add`) - Removed "?" tooltip indicator - Made list view full width in print mode Kanban View: - Removed "new" button (`.o-kanban-button-new`) Specific: - Accounting form view: removed "Add" outstanding credit buttons (`.outstanding_credit_assign`) - Sale form view: removed `.so_button_below_order_lines` ENT: https://github.com/odoo/enterprise/pull/100068 task-5265277 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue with accounting reports when printed, removing unnecessary borders and padding. This results in cleaner, more professional-looking reports for users, improving the overall user experience. The change is a straightforward fix to enhance the visual presentation of these reports.
Original PR description
This commit removes the padding and the border of the accounting reports when in print mode. COM: https://github.com/odoo/odoo/pull/236748 task-5265277
This update resolves a minor visual issue on the product pages where the 'out-of-stock' message wasn't properly spaced. The fix adds a margin bottom, ensuring the product page layout appears consistent and professional. This improves the overall user experience.
Original PR description
The out_of_stock_message div doesn't have a margin bottom, and it looks like something is off in the product page. Steps To Reproduce: 1.Go to a product with no inventory. 2.Add a out-of-stock message in the sale tab. 3.Go to the product page on the website. We can see that the message div has no margin bottom. To fix this we just add a margin bottom, as it was before. The PR that affected the margin bottom: https://github.com/odoo/odoo/pull/220506 opw-5259994
This update resolves an issue where clicking on message links outside of a conversation thread would open the link in a new browser tab. The fix ensures that message links always open within the existing Odoo window, improving user experience and workflow efficiency. This was a minor bug fix related to how Odoo handles internal links.
Original PR description
Before this commit, clicking on a message link for a message outside of the current thread would open a new tab. This unwanted behavior is caused by a missing return value on an override of Thread's `open` introduced in [1], breaking the chain of returns. This commit fixes the issue by correctly returning the super call in said override. [1] https://github.com/odoo/odoo/pull/223004 task-5268790
This update corrects a technical issue in the account reports module that was causing errors when generating reports. The change ensures that report data correctly references the selected return type, preventing a 'Expected singleton' error. This improves report stability and accuracy.
Original PR description
In this fwp https://github.com/odoo/enterprise/pull/100353, we change the `self.return_type_ids` by a browse, but we're still using `self.return_type_ids.id` in the new `return_type_id` key, introduced in 19.0, instead of the browse result, which could lead to a `Expected singleton` error. This commit replace the old self.return_type by the browse result. no-task
15 changes
Resolved issues and error corrections
This update resolves a minor typographical error within the account_reports module. The fix ensures accurate reporting functionality by removing a redundant comment that was previously present. This change improves the overall clarity and stability of the reporting system.
Original PR description
- This pull request fixes a typo in the account_reports module. - In the previous version, the `_prepare_lines_for_analytic_groupby` method contained a query with a DROP CONSTRAINT statement, and from this [PR](https://github.com/odoo/enterprise/pull/85942/files) the query was updated, but the related comment was not removed.
This update fixes an issue where documents and moves were incorrectly linked across companies in a multi-company setup. By adding the company ID, the system now accurately creates and searches documents within the correct company context, preventing errors and ensuring data integrity. This improves the reliability of our core accounting processes.
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
This update fixes an issue where signature fields added to views in Studio didn't display the correct widget option. Now, when adding a signature field, Studio automatically includes the signature widget in the selection list, allowing users to properly configure these fields. This ensures signature fields function as intended within the Studio view editor.
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 resolves an issue that occurred when all user type groups were marked as 'Share'. The change ensures a valid value is assigned to a field during user group updates, preventing a critical error that could disrupt system functionality. This ensures a smoother upgrade process.
Original PR description
… are share If all the user type groups have the flag `Share` as true, they will be filtered out by `get_application_groups`. While updating `user_groups_view`, the field `user_type_field_name` will…
… are share
If all the user type groups have the flag `Share` as true, they will be filtered out by `get_application_groups`. While updating `user_groups_view`, the field `user_type_field_name` will never be assigned, as the condition
`app.xml_id == 'base.module_category_user_type'` will never be fulfilled.
That means that `user_type_invisible` will be `None`, but that's not a valid value and it will break.
Steps to reproduce:
- Mark all the user type groups as Share.
- Upgrade `base`.
```
File "/home/odoo/src/odoo/18.0/odoo/addons/base/models/res_users.py", line 1801, in _update_user_groups_view
E.group(*(xml2), invisible=user_type_invisible),
File "src/lxml/builder.py", line 204, in lxml.builder.ElementMaker.__call__
File "src/lxml/builder.py", line 186, in lxml.builder.ElementMaker.__init__.add_dict
KeyError: <class 'NoneType'>
```
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#209470This update ensures Odoo correctly transmits invoice data to the Hungarian tax authority (NAV) by removing unnecessary state information. The EDI standard now only requires the province code (HU-BU) as specified in the official documentation, streamlining the process and avoiding potential errors.
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 where Italian e-invoicing error messages weren't being correctly stored and displayed to users. The fix ensures that error messages from the Italian tax authority are now properly captured and presented, improving invoice processing for Italian clients. This prevents data loss and provides better feedback to users.
Original PR description
Before this commit:
Steps
1) When clients try to send their invoice to Italian e-invoicing
2) If it's got rejected, they replied with an error message
=> A Traceback Error is raised with the message:
`errors = '\n- '.join(error.get('errors', ''))
^^^^^^^^^
AttributeError: 'str' object has no attribute 'get'`,
This occurs because the `_call_web_service_after_invoice_pdf_render()` method in l10n_it_edi is setting `moves_data[move]['error']` to a string while `_generate_and_send_invoices()` that calls `_hook_if_errors()` expects it to be a dict.
After this commit:
If the Italian e-invoicing rejects the request with `error_message` in the response, Odoo stores and displays it to the client correctly.
opw-5271525This update resolves an issue where the demo logo on reports was cropped at the bottom. The fix introduces a minimum width to ensure the logo displays correctly, preventing cropping. This improves the visual consistency of reports with short content.
Original PR description
Scenario: - set the report background to demo logo (621x196 pixels) - print a report with short content (eg. quotation without lines) Result: the logo is cropped at the bottom Why: Before 18.0, the…
Scenario: - set the report background to demo logo (621x196 pixels) - print a report with short content (eg. quotation without lines) Result: the logo is cropped at the bottom Why: Before 18.0, the background image was stretched over all the report, so needed to be ok esthetically if stretched. From 18.0 with https://github.com/odoo/odoo/commit/87258f05c7398173d3df6ec39869f52031502ede, the image is only intended to be shown one time on the first page without stretching over the whole document. There is two issues: - the "background-size" value "contains" is a typo of "contain" - if we fixed the typo we would break case where the image has a portait aspect ratio, the image would be zoomed to fit vertically (possibly over several page, which is itself an issue that the commit was trying to fix), but since we have the value "background-position: auto 300px" the contain is computed over the whole element area, and we will have 300px cropped of the bottom of the image Fix: This is not simple to fix, we could have used something like: background-size: auto calc(min(100% - 300px, 800px)); but both min and calc do not seem supported by wkhtmltopdf. So it seems that the only way to make this work better would be: - have a min-width, so people can know that if they can use an image of eg. 300px (for a min-width of 600px) of height without bottom cropped - we could fix the background-size: contain, but then we would possibly bring more issue for vertical image (that will be zoomed up or down all of a sudden) that are not solvable because of background-position. This fix just set the min-height to 600px. opw-4364722
This update corrects a bug where the 'Use Documents' option wasn't automatically enabled for LATAM invoices during setup. The fix ensures that when a LATAM chart of accounts is selected, this crucial setting is correctly applied, streamlining invoice processing for Latin American businesses. This resolves an issue impacting invoice document generation.
Original PR description
### Issue: During the loading of fiscal position data for LATAMs the option "Use Documents" on Journals is not set-up. ### Steps to reproduce: - Install 'l10n_ar' - Settings > Accounting - Make sure…
### Issue: During the loading of fiscal position data for LATAMs the option "Use Documents" on Journals is not set-up. ### Steps to reproduce: - Install 'l10n_ar' - Settings > Accounting - Make sure the "Fiscal Localization" have a value (not Argentina) - Change the "Fiscal Localization" to "Argentine - Generic Chart of Accounts [...]" - Go in Accounting > Configuration > Journals - Click on "Ventas Preimpreso" - The journal don't have "Use Documents" ticked but it should ### Cause: When loading the data, `_get_chart_template_data()` calls `_get_ar_base_res_company()` and `_get_latam_document_account_journal()`. The first one returns the data to change `res.company.account_fiscal_country_id` to `base.ar`. The second one [checks](https://github.com/odoo/odoo/blob/26a5384af0af8fc6e6b5a10bea277f937e2b3481/addons/l10n_latam_invoice_document/models/account_chart_template.py#L12) that [`self.env.company.account_fiscal_country_id.code == "AR"`](https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/l10n_ar/models/res_company.py#L36) before returning the data to change `l10n_latam_use_documents` to `True`. As `res.company.account_fiscal_country_id` has not been updated, it's not Argentina during the check and `_get_latam_document_account_journal()` returns nothing. ### Solution: When loading the template, we cannot use `res.company.account_fiscal_country_id` to know if we are in LATAM or not. So instead we check on `chart_template`. opw-5221931
This update resolves an issue where negative amounts (like credit notes) were not being included in the XBRL export of the EC Sales List report. The change ensures that all non-zero amounts, including negative ones, are now correctly generated for the report, improving data accuracy for VAT reporting. This addresses a prior bug impacting report completeness.
Original PR description
To replicate: 1. Install l10n_nl_reports_sbr_icp 2. Create an european partner with a VAT number 3. Create a credit note for this partner 4. Go to Accounting > Reporting > EC Sales List 5. The negative line appears in the report 6. Click on XBRL to export the report The negative line is not included in the exported report Only non-negative positive lines are added to the report in `_generate_codes_values()`. This commit changes that to include non-zero values. opw-5220622 Forward-Port-Of: odoo/enterprise#100009
This update resolves visual issues with the mobile website's scrollbar when navigating between pages. Previously, the fallback iframe content remained visible, causing a distracting scrollbar. Now, the iframe content is removed after loading, and the scrollbar appearance is corrected, ensuring a smoother and more professional mobile experience.
Original PR description
### [FIX] website: copy the whole document to fallback iframe Since da85d7f8f39f43bd21603b40f357dfc572036d27, the style in head and the body of the website preview are copied to the fallback iframe's…
### [FIX] website: copy the whole document to fallback iframe Since da85d7f8f39f43bd21603b40f357dfc572036d27, the style in head and the body of the website preview are copied to the fallback iframe's document. This did not copied the attributes on the `html` node, which somtimes impacted the appearance. With this commit, the whole document is copied to the fallback iframe. Steps to reproduce: - Activate "Mobile preview" when viewing the website - Go to a page that is long enough for a scrollbar to appear - Navigate to another page - Bug: During the transition, the fallback is shown, and its scrollbar is wider than the one of the page that was shown just before task-5212287 ### [FIX] website: remove content of fallback iframe after load Since commit 7b19831e1c624b483008feb526ba773ec8b23009, an fallback iframe is shown behind the website preview to avoid flicker on navigation. Since commit 3036c7dc4720a88f2717b96a29d45d923eb6ec75, the preview for mobile has some transparency on its scrollbar. Thus the part of the fallback iframe behind the scrollbar when previewing mobile was slightly visible. This commit fixes it by removing the fallback iframe's content after the website has loaded (and the fallback is not needed anymore). Steps to reproduce: - On website, activate "Mobile preview" - Navigate to a page long enough to have a scrollbar - Navigate to another page long enough to have a scrollbar - Scroll a bit - Bug: The scrollbar of the fallback is slightly visible task-5212287
This update fixes an error that occurred when users tried to view time off information for contracts without a defined working schedule. The fix prevents the application from crashing by skipping calculations when a schedule isn't present, ensuring a smoother user experience.
Original PR description
Currently, an error occurs when a contract has no working schedule set and the user tries to open the Time Off overview in the Gantt view. **Steps to Reproduce:** 1. Install `hr_holidays_contract_gantt` with demo data. 2. Open the **Marc Demo** employee and remove the **Working Schedule** from the contract. 3. Navigate to: Time off > Overview **Error:** `AttributeError - 'bool' object has no attribute 'upper'` **Cause:** The error occurs because at [1], the contract does not have a `resource_calendar_id` (working schedule) assigned. As a result, it attempts to access attributes of a False value, causing the error. **Fix:** This commit skips the computation when the contract does not have a working schedule set. [1] - https://github.com/odoo/enterprise/blob/e60429fce3875a282172cd81d18322d472d7fee4/hr_holidays_contract_gantt/models/hr_leave.py#L52 sentry-7017326141
This update fixes an error that occurred when creating new product templates. Previously, the system incorrectly set the template's write date to 'False' if the template was created without a pre-existing product. This change ensures accurate date tracking for new product templates, preventing potential data inconsistencies.
Original PR description
If _compute_write_date is launched when creating a product.product without starting from an existing product.template, the compute may be launched before the product.template is created, hence record.product_tmpl_id.write_date is False, and comparing datetime and bool leads to an error. This completes the fix proposed https://github.com/odoo/odoo/pull/138177 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where the DIOT tax report export failed when journal entries lacked a partner. The code was updated to gracefully handle missing partner information, preventing errors and ensuring the report generation process continues smoothly. This ensures accurate reporting for all DIOT tax scenarios.
Original PR description
**Steps to reproduce:** 1. Install `Accounting` and `l10n_mx_reports` modules. 2. Create two journal entries using DIOT tax grid: one with partner, one without 3. Confirm the entries. 4. Go to `Accounting → Reporting → Tax Report → DIOT (MX)`. 5. Try to print the DIOT report in TXT format from the top-right dropdown. **Observed behavior:** * Export fails with a traceback if any entry has no partner. **Root cause:** The method `_get_diot_values_per_partner` does not handle entries without partners. **Solution:** raise `Usererror` if entries without partners when sorting and exporting. note: The second commit addresses a traceback caused by a missing operation_type_code. This occurs when all entries lack a partner or when a partner’s operation_type_code field is not set. opw-5060825 Forward-Port-Of: odoo/enterprise#96529
This update fixes a potential issue where duplicate payments could be created when UrbanPiper order statuses were updated. The change ensures that a payment is only created if the order hasn't already been paid, preventing errors and streamlining the payment process. This improves order accuracy and reliability.
Original PR description
When an UrbanPiper order status is updated to 'food_ready' via webhook, the controller's _order_status_update method was calling _make_order_payment without checking if the order was already paid. This could result in duplicate payments being created if the webhook was called multiple times or if the order status transitioned back to 'food_ready'. The fix adds a check to ensure the order is not already paid before attempting to create a payment, matching the behavior in the order_status_update method.
This update corrects a problem that prevented users from sending E-Factura (SPV) invoices when linking bank accounts to invoices in the Romanian localization. The issue stemmed from a mismatch in how bank and partner information handled 'state' data. The fix ensures the correct field is used, allowing E-Factura sending to proceed smoothly. This resolves a previous bug identified in 18.4 and later versions.
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 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
10 changes
Resolved issues and error corrections
A recent update to optimize the way stock lots are processed introduced a bug. This fix resolves an error that occurred when a new stock lot was created, preventing disruptions in order fulfillment. The change ensures the system correctly handles both existing and newly created stock lots.
Original PR description
### Description: With the commit 72a87353f76bfa31561bed5eb21377b8e95cb7ee, `_find_delivery_ids_by_lot` has been replaced with another method more optimized. However, it introduces a bug when triggering the compute on a new lot. When `self` is not an existing lot but rather a new lot, it throws an error since the lot doesn't have an ID. ### References: 72a87353f76bfa31561bed5eb21377b8e95cb7ee opw-5355952
This update resolves a technical issue where the system was incorrectly creating duplicate bank accounts when processing UBL invoices. The fix filters out duplicate account numbers, ensuring accurate bank information is imported into Odoo. This prevents potential data inconsistencies and improves the reliability of financial transactions.
Original PR description
Currently `_import_retrieve_and_fill_partner_bank_details` may try to to create multiple res partner bank with the same account. This can i.e. happen in case there are multiple `cac:PaymenMeans` nodes in the XML. After this commit we filter out duplicate bank accounts numbers. opw-5149621
This update resolves an issue where scanning invalid GS1 barcodes caused Odoo to crash. The fix corrects a formatting error in the error message, ensuring that users receive clear and accurate feedback when barcode data is incorrect. This improves data integrity and prevents disruptions to inventory processes.
Original PR description
**Steps to reproduce:** 1. Install Inventory. 2. Open Inventory → Configuration 3. Barcode Nomenclature and select the default GS1 Nomenclature. 4. Open Barcode → scan the code:154105510000000244. **Observation:** - Scanning a GS1 barcode with an invalid date crashes Odoo and raises a traceback. **Cause:** - The translated ValidationError message uses the wrong interpolation syntax: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L58 and therefore fails during rendering. - Correct syntax should be: https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/account/models/account_move.py#L5647 **Fix:** - Fix faulty interpolation placeholder in ValidationError message to use `%(error_message)s` instead of `'%(error_message)'`, preventing the traceback and allowing the error message to display correctly. **opw-5253564**
This update resolves an issue where the FAIA report incorrectly classified partners as suppliers due to a logic error in how negative balances were interpreted. The fix involves creating a specific invoice and credit note sequence to trigger the correct customer classification within the report. This ensures accurate reporting for financial compliance.
Original PR description
1. Create a contact (with minimal details). 2. Create a customer invoice for that contact **last month** with `quantity = 300`. 3. Create a credit note for that invoice **this month**. 4. Create another customer invoice for the same contact **this month** with `quantity = 100`. In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer. In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative. However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. opw-5360924
This update resolves a problem with the layout of US check PDFs. A previous change introduced unnecessary code that was causing layout errors. This commit removes the problematic code, restoring the correct check formatting and ensuring accurate check printing.
Original PR description
In this commit afa85a637959f64dfdc9f24a0c7ae93fb2588bd1 we made few changes to fix the us checks pdf layout to fit with the expected format. But this commit added some t-if to deal with sequences, to hide some divs in case the journal is not set to Manual Numbering = True But some of them are useless and break the layout. This commit remove the t-if in `ckus_stub` template, this should fix the pdf template issue. opw-5125081
This update resolves a translation issue in the Odoo software's Marathi localization module (l10n_mr). Specifically, the tax report data was not correctly translated, leading to potential inaccuracies in financial reporting for users in India. This fix ensures accurate and compliant tax reporting for our Marathi-speaking customers.
Original PR description
--- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a bug where canceled Point of Sale (POS) transactions were sometimes still processed. The change ignores canceled payment lines, ensuring that only valid payments are recorded and preventing potential financial discrepancies. This improves the accuracy of sales data and reduces the risk of errors.
Original PR description
backport of https://github.com/odoo/odoo/pull/219054 opw-5160328
This update fixes an issue where form fields without labels were not being submitted when users clicked the 'send' button. Now, all form fields, including those without labels, are correctly transmitted, ensuring data is captured reliably. This improves the overall user experience and data integrity for website forms.
Original PR description
Before this commit, a form input without a label would not send its data when clicking send. Steps to reproduce - go to the website editor - add a form - choose any field - delete the field label - save and exit the editor - now in the website, fill the form and click send => the fields without a name label are not sent After this commit fields without a label get sent with a placeholder "unknown_field" task-5062575
This update resolves a bug where exiting a barcode picking process for products with serial numbers would incorrectly create a backorder. The fix ensures that remaining quantities are handled correctly, preventing unexpected backorders when scanning additional serial numbers. This improves the accuracy of inventory tracking for serial-numbered items.
Original PR description
**Problem:** Exiting a barcode picking will assign the remaining quantity, which can be problematic in the case of a product tracked by serial number because if the client scans another serial…
**Problem:** Exiting a barcode picking will assign the remaining quantity, which can be problematic in the case of a product tracked by serial number because if the client scans another serial number, at validation a backorder is created. **Steps to reproduce:** - Create a product tracked by serial number - create 4 quants (S1,S2,S3,S4) in stock - create a delivery of this product for a quantity of 3 - make sure the source location is stock - save but do not mark as todo - open it in barcode - scan s1 scan s2 - exit and come back to the picking in barcode - notice how a a new line with "0 / 1" has been added - scan s4 and validate **Current behavior:** A back order is created **Cause of the issue:** When we exit the operation on barcode, the post_barcode_process method is called. This method calls split_uncompleted_move https://github.com/odoo/enterprise/blob/1764381e3b3d4d78286a80b9ec32e2f68a946a86/stock_barcode/models/stock_move.py#L65 Which creates and confirm a new move (and thus a new move line) with the remaining quantity (here 1). https://github.com/odoo/enterprise/blob/1764381e3b3d4d78286a80b9ec32e2f68a946a86/stock_barcode/models/stock_move.py#L37 Then post_barcode_process calls truncate_overreserved_moves on self but because the quantity difference was added on an other move the method does nothing. **fix** The fix is essentially a backport of https://github.com/odoo/enterprise/pull/89967 In v18 the bug does not happen because at the end of split_uncompleted_moves, the new move is merged with the existing one (since the linked PR). https://github.com/odoo/enterprise/blob/b3a80334f375b8dc66d73cb13599d81b48470218/stock_barcode/models/stock_move.py#L37 This allows truncate_overreserved_moves to decrease the quantity on the move and remove the extra move line. opw-5172820
This update corrects a bug where replenishment lines were incorrectly duplicated in the MO Overview report. The issue stemmed from how the system tracked and linked replenishment quantities, leading to multiple entries for the same MO. This fix ensures accurate reporting of replenishment needs.
Original PR description
#### Issue: - Some replenishment lines appear several times in MO Overview #### Step to reproduce: - Create a product B - Activate Manufacture in the Inventory tab - Add a BoM to B - Add a reordering…
#### Issue: - Some replenishment lines appear several times in MO Overview #### Step to reproduce: - Create a product B - Activate Manufacture in the Inventory tab - Add a BoM to B - Add a reordering rule (min qty: 0, max qty: 0) - Create a product A - Activate Manufacture - Add a BoM to A which consume 1 unit of B - Create a MO for 6 units of A - Confirm it - It should have created a MO for 6 units of B - Confirm the MO for B. - Produce all - Go to the MO for A - Set the quantity to 1 (out of 6) - Click on the Scrap Button - Scrap 2 units of B and replenish quantities. - Click on the overview Button #### Current behavior: - Several lines appear for the MO to replenish quantities. (2 lines if state in 'draft', 3 line if state in 'confirmed') #### Expected behavior: - one line appear for the MO to replenish quantities. #### Cause of the issue: [In `_get_replenishments_from_forecast()`](https://github.com/odoo/odoo/blob/17.0/addons/mrp/report/mrp_report_mo_overview.py#L693-L694) we call `self.env['stock.forecasted_product_product']._get_report_lines()` which creates line for confirmed move (but neither done, nor draft move). Then in `_add_origins_to_forecast()` it tries to link a `document_in` to the previous lines using `line['move_out']._rollup_move_origs()`. There is 2 issues: - the `document_in` of a line created through `_get_report_lines()` was being displayed a second time if used to reconcile the `document_in` of another line. - a "document" used as `document_in` can be used for multiple lines regardless of its distribution in previous lines. #### Solution: - prevent lines from being displayed a second time - add a system to remember the already distributed quantity of document_in among lines opw-4882391 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr