Daily updates from Odoo
Thursday, November 27, 2025
110 changes
20 changes
Resolved issues and error corrections
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 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 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 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 the PDF report title for DIAN support documents was incorrectly displayed after the document was stamped by the DIAN. The change reordered a key condition to ensure the correct 'Documento Soporte' title is consistently used, aligning with DIAN requirements. This ensures accurate reporting for Colombian tax filings.
Original PR description
Steps: - Create and confirm a vendor bill with 'DIAN Support Documents' journal - Print the PDF — it display 'Documento Soporte' as document title - Send the document to the DIAN and print it again -> the returned PDF with the DIAN stamp now shows 'Factura Electrónica de Venta', it should still be 'Documento Soporte' Cause: In `AccountMove._get_name_invoice_report` we return the name of the report depending on specific conditions, but the order of the conditions prevent to get the right report name as soon as the document has been accepted by DIAN. Fix: Modifying the order of the condition, to redirect to the right report, even when the support document has been accepted by DIAN opw-5119858 Forward-Port-Of: odoo/enterprise#99028
This update fixes an issue where long participant names in the call sidebar would cause the layout to break, leading to a distorted view. Now, participant names are handled safely, ensuring the call sidebar remains properly formatted and functional. This improves the user experience and prevents visual disruptions.
Original PR description
**Description of the issue this PR addresses:** Prevent call participant name overflow **Current behavior before PR:** Before this PR, long participant names in the call sidebar could overflow their container, distorting the layout and causing the call action icons to shift incorrectly. **Desired behavior after PR is merged:** This PR ensures long names are now handled safely, preventing any layout breakage in the call participants sidebar. Before: <img width="302" height="125" alt="image" src="https://github.com/user-attachments/assets/309d3a0e-8304-43ee-ab22-0d7ee2883fc1" /> After: <img width="289" height="119" alt="image" src="https://github.com/user-attachments/assets/6c838fff-70d2-443a-b651-b985afe9cea6" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237327
This update resolves a technical issue that previously caused crashes when creating binary files within the Web Studio module. The fix prevents a problem with parallel field creation, ensuring stable operation of this key feature. This improves the reliability of the Web Studio interface for users.
Original PR description
Before this commit and subsequently to commit odoo/enterprise@75db3379655dc889b31ad34c66332f5a21f8cff4 creating a related binary field crashed because of the parallel creation of the filename related field. After this commit, this is fixed. opw-5237866
This update fixes a translation error in the Netherlands (l10n_nl) module, specifically regarding the description of the 9% ST tax. The incorrect translation 'TVA' was corrected to the accurate 'ST tax' description, ensuring proper reporting and compliance with Dutch tax regulations. This ensures accurate financial reporting for Dutch customers.
Original PR description
The traduction of te description of the 9% ST tax was wrong and was TVA to get back on a sale tax task-5217323 Forward-Port-Of: odoo/odoo#237467 Forward-Port-Of: odoo/odoo#236655
This update fixes a bug where the 'Late,' 'Today,' and 'Future' filters in the Activity Menu didn't correctly display Approval requests. The fix adds necessary filters to the Approvals search view, ensuring these filters now function consistently and align with other Odoo modules.
Original PR description
Issue: - In the Activity Menu, clicking "Late", "Today", or "Future" did not filter Approval requests and always returned all records. - The Approvals search view lacked the activity filters that these context defaults rely on. Fix: - Added the invisible activity filters (overdue, today, upcoming_all) to the Approvals search view. - Filters use `my_activity_date_deadline` to match Odoo's standard deadline-based activity filtering. Impact: - Activity Menu filtering now works correctly for Approvals and aligns with behavior in other modules. Task: 5261406 Forward-Port-Of: odoo/enterprise#100514 Forward-Port-Of: odoo/enterprise#99632
This update resolves a visual issue where the course search dropdown was incorrectly positioned above the search input on the homepage. The fix ensures the dropdown appears correctly within the search form layout, improving the user experience.
Original PR description
Scenario: go to homepage > Courses > one "View all" > type in search Result: dropdown with result is shown over the search input Issue: search form is in flex layout, but the dropdown is displayed in absolute so it is outside of flex flow and is positionned at the top-right of the form container. History: - before bootstrap 4 (odoo 15): the search form had a flex layout, but bootstrap dropdown used "top:100%" so were positionned at the bottom of it. - as of bootstrap 5 (odoo 16): the form kept a flex layout, but bootstrap dropdown now used "position: absolute" with unset top putting them below the search item in a block container, but over it in a flex layout. Fix: when the search bar is displayed, display it as block. opw-4735257 Forward-Port-Of: odoo/odoo#206909
This update adjusts the spacing between message text and reactions in notifications, resolving a previous issue where the UI appeared cramped. By removing a negative margin, the notification design is now cleaner and more visually comfortable for users. This improves the overall user experience.
Original PR description
Before this commit, the spacing between the text content of a message of type notification and the reactions was too small and resulted in the UI feeling cramped. This commit fixes the issue by removing the negative top margin in message reactions for messages that don't have enough padding. | Before | After | | ------------- | ------------- | | <img width="207" height="223" alt="Pasted image 20251124144956" src="https://github.com/user-attachments/assets/f23c070c-6253-440a-8b93-7b546daabda3" /> | <img width="202" height="236" alt="image" src="https://github.com/user-attachments/assets/e366a2ba-f851-4676-b108-bebf2fb12ec8" /> | task-5344759 Forward-Port-Of: odoo/odoo#237120
18 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 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 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 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
This update adds a warning message to bank statement lines when an analytic distribution is required. Previously, users weren't alerted if this was necessary, leading to potential errors. Now, users will receive a clear notification to set the correct analytic distribution, ensuring accurate financial reporting.
Original PR description
When setting the account on a bank statement line, analytic distribution might be required due to a mandatory plan. Before this commit, the user had no idea if the analytic is required or not. After this commit, lines that required analytic distribution will have a warning directing the user to set it. task-5055351 This is a backport of: https://github.com/odoo/odoo/commit/c337d97a3e06db37a316c4020261a797df4c6a1d Enterprise PR: https://github.com/odoo/enterprise/pull/100494 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update adds a warning message to bank statement lines when an analytic distribution is required. Previously, users weren't alerted if this was necessary, leading to potential errors. Now, users will receive a clear warning, guiding them to set up the correct analytic distribution plan.
Original PR description
When setting the account on a bank statement line, analytic distribution might be required due to a mandatory plan. Before this commit, the user had no idea if the analytic is required or not. After this commit, lines that required analytic distribution will have a warning directing the user to set it. task-5055351 This is a backport of: https://github.com/odoo/enterprise/commit/00396d24114b8747ff73ae60f032b630ce88c7a4 Community PR: https://github.com/odoo/odoo/pull/237368
8 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
This update resolves an issue where users wouldn't see signed documents after a request was completed. The fix ensures that both the requester and signer automatically receive 'view' access rights to the signed document, preventing access restrictions and improving document visibility.
Original PR description
To reproduce: ============= - as a User U with Admin rights on Documents (not Sys Admin) - create a folder at the root of the company - create a Sign Request template using this folder as signed document folder - send the Sign Request to another user O and sign it with that user O - go to Documents app with user U and check the folder where the signed document should be - the signed document is not there Problem: ======== when creating signed documents, the access rights for the requester are not set, causing the requester to not see the signed document Solution: ========= give `view` access right on signed documents to both the requester and the signer if they don't already have `edit` access right on it or ownership opw-[5087233](https://www.odoo.com/web#id=5087233&view_type=form&model=project.task) Forward-Port-Of: odoo/enterprise#97132
This update resolves a previous issue where installing the UK Construction Industry Scheme (l10n_uk_reports_cis) would trigger an error due to duplicate account codes. The fix ensures the scheme correctly handles companies with branches, allowing for successful installation and reporting.
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 resolves a technical issue that was causing a traceback when accessing the Documents app on mobile devices. The problem stemmed from an adaptation oversight during the forward port of a recent update. This fix ensures a stable and functional experience for users accessing the Documents app.
Original PR description
Steps to reproduce =================== 1. Toggle mobile view. 2. Open documents app. List prop is replaced by groupByField here https://github.com/odoo/odoo/pull/189109/commits/b5e821f0383caf6126a0d3c915cb4bccc8345b2b in 18.2. Here https://github.com/odoo/enterprise/pull/90647, we missed adapting the code in the forward port. Task-5363758
This update corrects a labeling issue within Odoo's document access rights settings. Previously, labels were unclear, now they clearly indicate the associated user groups providing access. This ensures better clarity and easier management of document permissions.
Original PR description
This commit fix the label of documents access rights which now shows a helper for each documents res.groups. Task-5186096 Forward-Port-Of: odoo/enterprise#98890
This update corrects a calculation error in rental order quantity tracking, specifically when returns are processed within linked pickings. The previous issue resulted in incorrect inventory counts for rental products. This fix ensures accurate tracking of product quantities during rental transactions.
Original PR description
Steps to reproduce: - Enable multi-step & Rental transfers - Set warehouse to 2 steps reception/delivery - Create a rental order for a product with a qty of 5 - Process the PICK - Change the quantity in the rental order to 3 and save - Change the quantity back to 5 and save again Issue: The Rental IN picking has now a `product_uom_qty` of 1. This is due to a wrong computation of incoming/outgoing moves when there are returns (e.g. here a return PICK) in the linked pickings. opw-5028794 Forward-Port-Of: odoo/enterprise#98473
10 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 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
This pull request resolves a technical issue (runbot error 234028) within the Web Studio module. The fix improves the stability and reliability of Web Studio's automated testing processes, preventing potential disruptions to users' ability to customize their Odoo applications. This ensures a smoother experience for Odoo Enterprise users.
Original PR description
runbot-error-234028
This update fixes an issue where the EC Sales List menu was incorrectly placed within the application views. The menu has now been moved to the data folder, ensuring it appears correctly within the Odoo interface. This improves the user experience for reports related to sales in Ecuador.
Original PR description
The menu record was wrongly stored under views. It is now moved to the data folder.
23 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 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 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 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 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 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
This update corrects an issue where the Odoo system was sending incorrect data in electronic invoices to the Hungarian tax authority (NAV). The system now adheres to specific documentation requirements, omitting the state name and only sending the required province code as defined by the ISO standard. This ensures compliance and accurate invoice submissions.
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 adds a notification to inform users when they are utilizing the Chorus Pro feature but haven't installed the necessary module. This ensures they receive all the required checks and functionality, preventing potential errors or omissions in their accounting processes. It's a proactive measure to maintain data integrity and user experience.
Original PR description
This commit will add an alert when the customer use Chorus pro but don't have the module installed, and so don't have all the additional checks <img width="982" height="242" alt="image" src="https://github.com/user-attachments/assets/fc35d4ee-9a8b-41b8-8ee3-cbc32b266379" /> task-5223874 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237201 Forward-Port-Of: odoo/odoo#236856
This update prevents Odoo from automatically canceling workorders when a subcontracting manufacturing order (MO) is created or modified through the portal. Previously, this caused unnecessary MO duplication. Now, the system correctly avoids workorders on subcontracted MOs, aligning with the intended product structure.
Original PR description
When adding/changing serial number on a subcontracting MO via portal view, Odoo will cancel and unlink the old MO(s) to recreate new ones. This include cancelling workorders, which a portal user doesn't have access to. Since subcontracted MO should not have workorders because the bom should not have operations, this PR adds a call to `_has_workorders` before searching for workorders.
This update fixes an issue where portal users couldn't properly unsubscribe from leads marked as spam. It now allows users to access and manage tags on leads when they identify them as spam, ensuring a smoother unsubscribe process and improved user experience. This change enhances the portal's functionality for managing unwanted communications.
Original PR description
Allow a portal user to read tags on the lead when he mentions that it is spam. Correct access for the unsubscribe process with child partner for the commercial partner of the portal user. task-5347166
This update resolves a bug that occurred during Odoo upgrades when a default confirmation template wasn't available. The error stemmed from incorrectly attempting to use a boolean value (False) as if it were an object with an 'exists' method. This fix ensures a smoother and more reliable upgrade process.
Original PR description
When there is no default confirmation template,
An error is raised:
AttributeError: 'bool' object has no attribute 'exists'. This happens because default_template is False,
So calling default_template.exists() results in the error. The issue occurs during the upgrade process.
```
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3142, in _init_column
value = field.default(self)
File "/home/odoo/src/odoo/19.0/addons/website_sale/models/website.py", line 52, in _default_confirmation_email_template
if default_template.exists():
AttributeError: 'bool' object has no attribute 'exists'
```
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-prThis update resolves an issue that occurred when users deleted all overtime rules before installing the 'hr_work_entry_attendance' module. The fix prevents a parsing error by intelligently handling the absence of required records, ensuring smooth module installation. This improves the user experience and avoids installation failures.
Original PR description
Currently a `ParseError` arises when the user installs the `hr_work_entry_attendance` module after deleting all `Overtime Rules' in the 'Rulesets` Configuration. Steps to reproduce: --- - Install…
Currently a `ParseError` arises when the user installs the `hr_work_entry_attendance` module after deleting all `Overtime Rules' in the 'Rulesets` Configuration.
Steps to reproduce:
---
- Install `hr_attendance` module(without demo)
- Attendance > Configurations > Overtime Rulesets
- Delete all `Overtime Rules` in `Default Ruleset`
- Now install `hr_work_entry_attendance` module
Traceback:
---
```py
Exception: Cannot update missing record 'hr_attendance.hr_attendance_overtime_employee_schedule_rule'
ParseError
while parsing /home/odoo/src/enterprise/19.0/hr_work_entry_attendance/data/hr_attendance_overtime_rule_data.xml:4, somewhere inside <record id="hr_attendance.hr_attendance_overtime_employee_schedule_rule" model="hr.attendance.overtime.rule">
<field name="work_entry_type_id" model="hr.attendance.overtime.rule" eval="obj()._get_default_work_entry_type_id()"/>
</record>
```
The error occurs because the user deleted all `Overtime Rules` and then installed the `hr_work_entry_attendance` module. which requires particular records.
This commit solves the above issue by using `noupdate="1"`and `forcecreate="0"` to skip the creation of record if it doesn't exists.
https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/odoo/tools/convert.py#L364-L366
sentry-7023182659This update fixes a technical error that occurred when validating online payments with invoices in the Point of Sale (POS) system. The fix involved correcting how invoice PDF downloads and cashbox actions were handled, ensuring smoother online payment processing for customers. This resolves a previous error that prevented successful order validation.
Original PR description
steps to reproduce: - Create an Online Payment payment method. - Open POS, create an order, and validate it using the Online Payment method with Invoice enabled. issue: - A traceback error is displayed after validating the order. fix: - Fixed the `invoice PDF download` actions so it use the correct service. - Also, corrected for the cashbox action. task: 5269502
This update corrects a technical error in how Odoo processes webhook events related to expense reports using Stripe virtual cards. Specifically, the system was incorrectly interpreting 'None' shipping values as dictionaries. This fix ensures accurate data handling and prevents potential disruptions to expense reporting workflows.
Original PR description
Add a fix to a pattern of error found in webhook events where virtual cards whose shipping value is "None" would be accessed as dict
This update removes a redundant filter in the HR work entry system, resolving an issue that caused problems with localization (l10n_BE). The change ensures accurate leave calculations by allowing the system to correctly handle variations in work entry types.
Original PR description
This filter was not necessary and was causing some issues in l10n_BE as the work entry type can change depending on various reasons. If it changed, the leave_id would not be copied to the new work entry. task-5103485 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
11 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 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 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 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 releasing a table in the Restaurant POS module would cause a crash. The team added a test case to ensure stability when removing orders from a table, preventing unexpected errors and improving the user experience. This ensures smoother operation for restaurant staff.
Original PR description
## In this commit: - Testcase added to ensures that no traceback occurs when releasing a table after deleting a synced order. ## Steps to reproduce: - Open Restaurant POS - Select a table and add a product - Click the order button - Reopen the same table and remove all order lines - Click "Release Table" Related PR: https://github.com/odoo/odoo/pull/216336 Task: 4899160
This update fixes a visual issue where the comparison price for subscription products wasn't displayed on the product page. The fix involves updating how the product page renders pricing dynamically, ensuring the comparison price is correctly shown to customers. It addresses a technical limitation with client-side rendering and formatting.
Original PR description
Steps to reproduce: 1. Install website_sale_subscription 2. Enable Comparison Price from the settings 3. Create a Subscriptions product with a recurring plan and 'compare to price' > recurring price…
Steps to reproduce: 1. Install website_sale_subscription 2. Enable Comparison Price from the settings 3. Create a Subscriptions product with a recurring plan and 'compare to price' > recurring price 4. Go to product page via smart button Issue: - The comparison price is not visible beside the recurring plan. Cause: - The product page updates the pricing display dynamically using client-side rendering when the subscription plan information is loaded. The XML template `website_sale_subscription.SubscriptionPricingSelect` used the <field> tag `<field name="product.compare_list_price"/>` to render the comparison price. The <field> tag is a server-side QWeb element and is not supported by the client-side Owl engine, causing the rendering to display nothing. Additionally, client-side templates do not have automatic access to server-side field formatting (like currency symbols) when simply escaping raw values. Solution: - In `variant_mixin.js`, extract the already formatted comparison price text from the existing DOM element (the `<del>` tag inside the pricing selector) before the element is replaced and pass this formatted string to the rendering context. Update the XML template to use `t-esc` to display this pre-formatted string instead of using `<field>` before: <img width="426" height="79" alt="image" src="https://github.com/user-attachments/assets/fe34b4c5-5cd6-4877-80e3-9ed4481cd86f" /> After: <img width="392" height="115" alt="image" src="https://github.com/user-attachments/assets/ed043fef-bfd3-46de-aeb2-1a48cacc89ed" /> opw-5248297
This update resolves a bug where a previously unlinked call continued to appear in the Odoo softphone. The fix ensures that calls are immediately removed from the softphone interface when they are no longer linked, improving the user experience and data accuracy.
Original PR description
A call that was unlinked previously remained visible in the VOIP softphone. This fix ensures that the call is correctly removed from the softphone view as soon as it is unlinked. Task-5262162 Forward-Port-Of: odoo/enterprise#100036
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 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 ensures that all B2C invoices generated through our Saudi Arabia localization (l10n_sa) module now correctly display 'Simplified Tax Invoice' as the invoice title. Previously, this requirement was only applied to phase 2 ZATCA invoices. This change aligns with regulatory requirements and improves invoice consistency.
Original PR description
For B2C invoices, the invoice's title must be "Simplified Tax Invoice". This was only applied to phase 2 ZATCA in "l10n_sa_edi". This change makes sure to apply the same requirement for phase 1 invoices. Task-5322118 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Original Bills report in Odoo Studio was producing empty results due to a complex report generation process. To resolve this, the Studio team has blacklisted this specific report, preventing it from being created within the Studio interface. This ensures Studio focuses on reports it can reliably handle.
Original PR description
Steps to reproduce ================== - Install account_accountant,web_studio - Go to Invoices - Open studio - Click on "Reports" - Select the "Original Bills" report => The report is empty Cause of the issue ================== The Original Bills is a very specific report. Multiple streams are created and then combined to make the final PDF See: odoo/odoo#85150 Solution ======== Since studio cannot handle this usecase, we blacklist this report opw-5108198
This update resolves a visual issue in check printing for US layouts, where the payment date would overlap with the table below. The fix ensures the date is always positioned correctly in the generated PDF, improving the presentation of vendor bills and payments.
Original PR description
In the Accounting app, users can print checks created to pay Vendor Bills. When using any of the US Checks Layout (from `l10n_us_check_printing`), the payment date would overlap the table beneath it…
In the Accounting app, users can print checks created to
pay Vendor Bills. When using any of the US Checks Layout (from
`l10n_us_check_printing`), the payment date would overlap
the table beneath it when the journal's manual sequencing option was
disabled.
<img width="1201" height="624" alt="image" src="https://github.com/user-attachments/assets/cd3aa46a-1952-4652-9034-e4bc2ea9a44d" />
This occured because the `.summary_line` container collapsed to a height
of 0 whenever its first child wasn't displayed, as the remaining child
elements are absolutely positioned and therefore do not contribute to
the parent's height.
https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/l10n_us_check_printing/report/print_check.xml#L24-L34
By assigning a minimum height to the `.summary_line` class, we make sure
that it always occupies space above the table, even when only the date
is shown.
### Steps to reproduce:
**/!\ To reproduce the bug locally, you must have a version of wkhtmltopdf with patched qt. Use `wkhtmltopdf -V` and make sure that _"(with patched qt)"_ is specified after your wkhtmltopdf version.**
1. Install Accounting (`accountant`) and US Checks Layout (`l10n_us_check_printing`)
2. In Settings > Accounting, toggle on *Checks* if it is not, and set *Check Layout* to any "US" layout.
3. Go to Accounting > Vendors > Bills
4. Create a new Vendor Bill:
- Set any Vendor
- Set any Bill Date
- Add any Product (with a positive price, the total price of the bill must be positive)
- Confirm
5. Click *Pay*, set the *Payment Method* to *Checks* and click *Create Payment*
6. Click on the *Payments* smart button
7. Click *Print Check* > *Print* (> *Continue*)
8. In the generated PDF, the date overlaps the table beneath it.
This fix moves the date right above the table.
<img width="1189" height="634" alt="image" src="https://github.com/user-attachments/assets/8858098e-b39b-4ad2-aa65-cc0cea550343" />
opw-5165112