Daily updates from Odoo
Thursday, November 27, 2025
25 changes · saas-18.3
Enhancements to existing features
This update clarifies the tooltip for the 'Prices' setting in the configuration. Previously, it stated the setting was locked after invoice creation, which was confusing. Now, it correctly indicates the setting locks once a journal entry is created, providing clearer guidance for users.
Original PR description
This commit improves the tooltip of the Prices setting in configuration. The old tooltip "This setting cannot be changed after an invoice is created." is changed to "This setting locks once a journal entry is created." task-5354382 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237093
This update automatically notifies users when invoices are canceled due to DGI rejections, ensuring someone is responsible for correcting and resending receipts. It also addresses a previous inconsistency where rejected invoices could unexpectedly change state, now allowing users to manually update the DGI status via a new button.
Original PR description
Added 3 improvements to the process of updating the state of an invoice in Odoo, according to the state in DGI: **For invoices that have been rejected by DGI:** - Added logic to automatically notify…
Added 3 improvements to the process of updating the state of an invoice in Odoo, according to the state in DGI: **For invoices that have been rejected by DGI:** - Added logic to automatically notify relevant users when an electronic invoice (CFE) is rejected by the DGI and, as a result, canceled in the system. The goal is to ensure that there is always someone responsible who is informed to correct and resend the receipt. - Added logs in the terminal to make the debug easier in case we want to identify rejected invoices. **Particular case of an invoice that had been rejected by DGI but the user somehow fixes it and then DGI accepts it:** - Added logic to verify both DGI state and Invoice state and adjust it accordingly when updating invoice DGI status. - Make 'Update DGI status' button always visible to be able to adjust invoices states. **== Context of the Problem ==** Previously, when Odoo detected that a CFE had been rejected by the DGI, the system proceeded to cancel the invoice automatically. However, this process was carried out silently, without generating any notification. This could mean that if no user or salesperson was actively monitoring the status of the receipts, the cancellation would go unnoticed, resulting in invoices that were never corrected or reissued. For the case of a previously rejected and then accepted invoice, we always thought that 'Rejected' state in DGI was a definite state and could not suffer any change. But recently it has been a case that this state changed, creating inconsistencies in Odoo invoices states as they appear as cancelled. With these changes, the user can adjust the invoices state by clicking 'Update DGI status' button. **== Automatic Notification Logic ==** With the new functionality, every time an invoice is automatically canceled due to a DGI rejection, the system posts a message in the document chatter to report the situation. The logic for determining who is notified is as follows: _Scenario 1: Invoice with Internal Followers_ - If the canceled invoice has at least one internal follower (an Odoo user), the system will perform the following actions: - It will post a message in the invoice chatter. - It will tag (@) all internal followers to notify them directly. _Scenario 2: Invoice without Internal Followers_ - If the invoice does not have any internal followers, the system will search for a more general but relevant audience to ensure that the notification is addressed: - It will post a message in the invoice chat. - It will tag (@) all users who belong to the “Accounting Manager” permission group (technical name: group_account_manager). Task ODOO: #[1362](https://latam-localizations.odoo.com/web?debug=1#id=1362&cids=1&menu_id=88&action=131&active_id=16&model=project.task&view_type=form) Task ADHOC: #[54799](https://www.adhoc.inc/odoo//project.task/54799) Forward-Port-Of: odoo/enterprise#98210 Forward-Port-Of: odoo/enterprise#94502
This update simplifies UBL invoice generation by automatically using the latest helpers for BIS3 and related formats. Previously, these helpers were only used for BIS3, but now they're enabled by default, ensuring consistent and reliable UBL invoice creation across various accounting systems. This change improves data accuracy and streamlines the process for generating UBL invoices.
Original PR description
Since commit 52e984037 we have enabled the new helpers by default for generating BIS3 UBLs. But we didn't enable them in the UBL formats that depend on BIS3 (NLCIUS, XRechnung, Chorus Pro etc). That was to first fix any issues in BIS3 in case the new helpers had broken something. Since the new helpers seem to be working fine for BIS3, we are now making them the default for all the formats that depend on BIS3 as well. We also add comments in the old helper methods to indicate that they are no longer used by default for BIS3 and its extensions. task-none Forward-Port-Of: odoo/odoo#237198 Forward-Port-Of: odoo/odoo#229231
Resolved issues and error corrections
This update resolves a technical issue that caused errors when users closed payment tabs in the Point of Sale (POS) system. Specifically, clearing payment lines resulted in a system error. The fix ensures the system gracefully handles scenarios with no selected payment line, defaulting to the first payment line if needed, improving the overall POS experience.
Original PR description
Steps: --- - Enable Tips and "Add tip after payment" in restaurant. - Open a session and add any product(s). - Go to payment and add two card lines (first with full amount, second with 0). - Click on "Close Tab". Issue: --- - After redirecting to the Tip Screen, a traceback appears. Cause: --- - Clicking "Close Tab" clears all 0-amount payment lines. This can leave no selected payment line, but the Tip Screen still tries to access it. Fix: --- - Use the selected payment line if available, otherwise fallback to the first payment line. task-5095825 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237124 Forward-Port-Of: odoo/odoo#227797
This update fixes an issue where signature fields added to views within Odoo's Studio were not correctly configured. The signature widget was missing from the available options. Now, signature fields added to views will correctly display the signature widget, ensuring accurate field configuration and functionality.
Original PR description
Before this commit: ------------------- When a user added an existing signature field to a view, Studio automatically assigned the default binary widget. The expected signature widget did not appear…
Before this commit: ------------------- When a user added an existing signature field to a view, Studio automatically assigned the default binary widget. The expected signature widget did not appear in the widget selection list. As a result, users could not configure the field as a signature input. <img width="1920" height="938" alt="image" src="https://github.com/user-attachments/assets/35893235-2541-4bd5-a7a5-4feab562acb2" /> Cause: ----- Studio builds the dropdown of available widgets by computing a [widgetKey](https://github.com/odoo/enterprise/blob/17.0/web_studio/static/src/client_action/view_editor/editors/utils.js#L132) based on the field type. Because the signature widget did not declare binary as a supported field type, it was always filtered out for fields of type binary. Thus Studio treated the field like any normal binary field and excluded the signature option. After this commit: ------------------ The signature widget is correctly exposed as a supported widget for fields of type binary. When adding an existing signature field to the view (with developer mode enabled), Studio now shows signature in the widget list. <img width="1917" height="934" alt="image" src="https://github.com/user-attachments/assets/079e0a17-ff5a-4dc6-a12d-e02b9cad013e" /> Why this fix is needed: ---------------------- Signature fields are stored as binary, but they require the dedicated signature widget to render correctly. By marking binary as a supported field type for the signature widget, Studio can properly detect and offer the widget during field configuration. Given that this widget is very domain-specific and not intended for general binary fields, it was not added to [web_studio/static/src/client_action/view_editor/editors/sidebar_safe_fields.js](https://github.com/odoo/enterprise/blob/17.0/web_studio/static/src/client_action/view_editor/editors/sidebar_safe_fields.js) though this may be reconsidered after this fix the option is accessible only when the debugger mode is on, if want to show this widget to all the binary type fields even when the debugger mode is off the we'll have to add it to this file. OPW : 5260188 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237287
This update ensures Odoo correctly formats invoices for Hungarian e-invoicing (l10n_hu_edi) by removing unnecessary state information. According to regulations, only the province code (HU-BU) is required, and this change aligns Odoo with the latest Hungarian tax authority specifications.
Original PR description
Purpose: According to documentation, in region tag in address details, we need to send that county's province code as per the ISO 3166-2 alpha 2 standard. E.g. 'HU-BU'. But we were sending state's name E.g. 'Budapest'. But since region tag is not mandatory for edi, we choose not to send that. Before this commit: In region tag, state's name was sent. After this commit: We stopped sending region tag. EDI Documentation(page-87): https://onlineszamla.nav.gov.hu/files/container/download/2025.10.09.%20EN_Online%20Invoice%20System%203.0%20Interface%20Specification%20.pdf task-5270199 Forward-Port-Of: odoo/odoo#236218
This update resolves an issue that caused payslips to fail to generate correctly due to missing data within a configuration dictionary. The fix uses a safer method to access dictionary values, preventing errors when keys are absent. This ensures more reliable and consistent payroll processing.
Original PR description
Bug: When generating payslips, there is a traceback with keyerror. Cause: We were getting info from a dict but keys could be not present. Fix: Use get instead, with a default value. Forward-Port-Of: odoo/enterprise#99245
This update resolves an issue where alerts added to field descriptions during the checkout process couldn't be edited. The fix utilizes the editor's built-in insertion command to ensure alerts are correctly placed within editable text areas, improving the user experience for adding feedback.
Original PR description
Problem: When adding an alert inside a field description in the Extra Step page of the checkout process, the inner content of the alert cannot be modified. Cause: In…
Problem:
When adding an alert inside a field description in the Extra Step page of the checkout process, the inner content of the alert cannot be modified.
Cause:
In
https://github.com/odoo/odoo/blob/1e96a3d127e8f521d3027f7110026ae84e11ed5e/addons/website/static/src/components/wysiwyg_adapter/wysiwyg_adapter.js#L784-L789 the logic determines the block using:
`this.closestElement(range.endContainer, 'p, div, ol, ul, cl, h1, h2, h3, h4, h5, h6');` Since the field description template is:
```html
<div class="s_website_form_field_description small form-text text-muted"
contenteditable="true">
text
</div>
```
and the selection occurs within the text (direct child of the editable `div`), the computed `block` becomes the editable area itself. As a result, the cloned alert is inserted *after* the editable area: `block.after($clonedBody[0]);`, making it non-editable.
Solution:
Use the editor’s built-in `insert` command instead of manually inserting clones. This ensures the alert is correctly inserted within the editable region.
Steps to reproduce:
1. Enable "Extra Step During Checkout" in Settings.
2. Open Website → add a product to the cart → proceed to checkout.
3. In the "Extra info" step, open the editor.
4. Select the "Give us your feedback" field.
5. Enable "Field" → "Description".
6. Run the "/alert" command in the description. → The alert content cannot be edited.
opw-5184309
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#234905
Forward-Port-Of: odoo/odoo#232910This update resolves an issue where invoices weren't being created for alternative sale orders generated from upsells. The fix ensures the correct invoice date is calculated by copying the previous upsell order's invoice date, now allowing invoices to be created successfully after confirming the alternative order.
Original PR description
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the…
Version - 17.0 Issue: - When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error - As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued. Steps to reproduce: - Create an upsell order of a subscription. - Click Create Alternative to generate an alternative SO. - Confirm the SO and click on Create Invoice to make the invoice - This will throw an error of defferred end date Cause: - The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO. - Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error. Fix: - Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation. Impact: Invoices for alternative upsell sale orders can now be created successfully without errors. task-5241150 Forward-Port-Of: odoo/enterprise#99831 Forward-Port-Of: odoo/enterprise#98983
This update corrects a bug where archived users were incorrectly sending out automated follow-up emails for invoices. The fix ensures that follow-up emails are only sent by active users, preventing confusion and ensuring accurate communication. This improves the reliability of our automated customer outreach.
Original PR description
### Issue: If an archived user is set as the Sales person on an invoice or as the followup responsible on a partner, it will be the one sending the automatic followups. ### Steps to reproduce: - Create a partner and an overdue invoice for this partner - Change the "Salesperson" of the invoice to another user - Archive this user - Accounting > Customer > Followup Reports - Click on the partner created earlier - Click the actions and "Process Automatic Follow-ups" - [17.0] Traceback - [18.0+] The sent message is from the user that was archived ### Cause: `_get_followup_responsible()` does not check is the users it returns are active or not. ### Solution: Create an iterable with all the possibilities and iterate on it to return the first active user in the list. Fallback on `self.env.user`. opw-5153159 Forward-Port-Of: odoo/enterprise#100465 Forward-Port-Of: odoo/enterprise#98807
This update fixes a translation error in the Netherlands (l10n_nl) module. The description for the 9% ST tax was previously incorrectly translated as 'TVA' (Value Added Tax). This change ensures accurate tax reporting and compliance for Dutch businesses using Odoo.
Original PR description
The traduction of te description of the 9% ST tax was wrong and was TVA to get back on a sale tax task-5217323 Forward-Port-Of: odoo/odoo#236907 Forward-Port-Of: odoo/odoo#236655
This update resolves an issue where the colorpicker wasn't correctly displaying custom background colors set within Odoo. The fix ensures that all color selections, including background colors, are accurately reflected in the colorpicker interface. This improves the user experience when customizing website content.
Original PR description
Before this commit, the colorpalette for the background color would not display custom colors already on the page. The issue appeared in 17.0 and worked in 16.0 before the conversion of wysiwyg to owl. github.com/https://github.com/odoo/odoo/pull/118966 The "getEditableCustomColors" method was not forwarded and therefore we used the default function, returning nothing. Steps to reproduce the issue: - Add a snippet - Set the background / font color of the snippet to a custom color - Add another snippet - Open the colorpicker for the text color (The colorpicker have access to the custom color set above) - Open the colorpicker for the background color (The colorpicker does not have access to the custom color set above) task-3806989 Forward-Port-Of: odoo/odoo#237173 Forward-Port-Of: odoo/odoo#180335
This update corrects a bug where the search function on the recent and contacts tabs in the VoIP module wasn't properly filtering results. The fix ensures that search terms are now accurately reflected in the displayed contacts, improving user efficiency and data accuracy. This resolves a previous issue impacting contact search.
Original PR description
On recent/contacts tab, search rpc didn't take search term into account. Fix it. Task-5262162
This update fixes an issue where the PDF report title for DIAN support documents was incorrectly displaying 'Factura Electrónica de Venta' after the DIAN stamp was applied. The change adjusts the report naming logic to ensure the correct 'Documento Soporte' title is consistently used, aligning with DIAN requirements.
Original PR description
Steps: - Create and confirm a vendor bill with 'DIAN Support Documents' journal - Print the PDF — it display 'Documento Soporte' as document title - Send the document to the DIAN and print it again -> the returned PDF with the DIAN stamp now shows 'Factura Electrónica de Venta', it should still be 'Documento Soporte' Cause: In `AccountMove._get_name_invoice_report` we return the name of the report depending on specific conditions, but the order of the conditions prevent to get the right report name as soon as the document has been accepted by DIAN. Fix: Modifying the order of the condition, to redirect to the right report, even when the support document has been accepted by DIAN opw-5119858 Forward-Port-Of: odoo/enterprise#99028
This update corrects a bug in the demo kiosk's payment process. Previously, the kiosk incorrectly used a 'meal' payment mode, causing the payment screen to be skipped. This change ensures the kiosk always uses the 'each' payment mode, guaranteeing the payment screen appears as expected.
Original PR description
The field `self_ordering_pay_after` should always be `each` when the `self_ordering_mode` is set to `kiosk`. This is enforced in the `write` method. However, the demo kiosk is created with a `self_ordering_pay_after` value of `meal`, until the `write` method is run. This results in behaviour such as the payment screen being skipped when it is not expected to. This commit sets the correct `self_ordering_pay_after` value of `each` when creating the demo kiosk. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237521
This update corrects a display issue where the 'Due Date' column disappeared in the phone view of invoices. The problem stemmed from conflicting CSS styles, which caused the column title to be incorrectly overridden. This ensures the 'Due Date' column is always visible and correctly labeled when viewing invoices on smaller screens.
Original PR description
****Behavior:****
When switching to phone view, the 'Due Date' column name dissapears but the values stay, which causes every further column of the table to have the wrong title.
The removal of the Due Date column is intended, the issue happens beacause the 't-att-class' specifying the condition to make values red was overriding the initial 'class' specifying the behavior in phone view.
**Steps to reproduce:**
- Create an Invoice for the current user
- Go to Website -> User -> My Account -> Your Invoices
- switch to phone view (reduce to less than 768px if not initially the case)
- You'll see the 'Due Date' column name dissapear and the value shift to the next column name ('Amount Due')
opw-5239794
Forward-Port-Of: odoo/odoo#235474This update resolves a previous issue that prevented the UK Construction Industry Scheme from installing correctly when used with company branches. The fix prevents the creation of duplicate account codes, ensuring successful installation and proper reporting functionality for UK businesses.
Original PR description
Before this commit: Steps 1) Create a UK localization company 2) Create a branch for that company 3) Try to install UK - Construction Industry Scheme (l10n_uk_reports_cis) => A Validation Error is raised with the message `Account codes must be unique. You can't create accounts with these duplicate codes: 220001, 220101, 220201`, This occurs because the `_l10n_uk_reports_cis_post_init()` method is creating accounts for each UK company even if they aren't root companies (branch). After this commit: UK - Construction Industry Scheme (l10n_uk_reports_cis) is installed successfully with UK companies that have branches. opw-5326079 Forward-Port-Of: odoo/enterprise#99901
This update fixes an issue where documents and moves were incorrectly linked across companies in a multi-company setup. By adding the company ID during attachment creation and searches, the system now accurately assigns documents to the correct company, preventing errors and ensuring data integrity. This improves the reliability of financial reporting and move management.
Original PR description
Behavior before: In a multi-company setup, fetching documents could include records from different companies based on VAT numbers. When creating attachments or searching for existing moves, the company ID was not properly considered, leading to incorrect company assignments and failed move creation. Behavior after: Documents and moves are now created and searched within the correct company context by explicitly including the company ID. Root Cause: The company ID was missing in both the attachment creation and the domain used to search for existing moves, causing cross-company mismatches. opw-4929985 Forward-Port-Of: odoo/enterprise#99192
This update fixes a delay in receiving payment notifications for online PoS transactions. Previously, if a customer closed the payment page before confirmation, the PoS would wait up to 10 minutes. The fix triggers a process to ensure immediate notification, improving the order processing flow and preventing delays.
Original PR description
When paying online with the PoS if for some reason the client closes the web page before receiving the payment confirmation, the PoS would not be notified that the payment was successful. Steps to…
When paying online with the PoS if for some reason the client closes the web page before receiving the payment confirmation, the PoS would not be notified that the payment was successful. Steps to reproduce: ------------------- * Setup any online payment method in the PoS. * Open the PoS and create an order. * Proceed to payment and choose the online payment method. * Scan the QR code and close the page before receiving the payment confirmation. > Observation: The PoS will need to wait atleast 10 minutes to receive the payment notification. Why the fix: ------------ When using the online payment method, the user that scans the QR code will open a web page to complete the payment. This webpage is also responsible to poll the status of the payment. When polling the status of the payment, if the payment is successful, the server will send a notification to the PoS to update the order status. If the user closes the web page before the payment is confirmed, the PoS will not receive the notification. We will need to wait for the payment transaction `_cron_post_process` to be executed, which happens every 10 minutes. So the solution is to trigger the cron when the payment is set as done to ensure that the PoS receives the payment notification as soon as possible. opw-4925349
This update resolves an issue preventing users from creating bank statements when the chart of accounts wasn't properly configured. The fix ensures the system correctly identifies related accounts before generating statements, improving the reliability of bank reconciliation processes.
Original PR description
**Steps to Reproduce:** 1. Install the **Accounting** module without demo data. 2. In "**Chart of Accounts**", change the type of all accounts (e.g.; Expenses). 3. In "**Bank**" Journal, create a new bank statement line and try to save it. **Error:** ``` SyntaxError - syntax error at or near ")" LINE 19: AND aml.account_id IN () ``` **Cause:** A **IN** condition is evaluated with an empty tuple `AND aml.account_id IN ()`. This is due to that there are no `account_ids`. **Fix:** This commit only executes the SQL query when there are valid accounts to consider. sentry-7059353053
This update fixes a visual issue where long participant names in the call sidebar would cause the layout to break and icons to shift. The change ensures that participant names are handled correctly, maintaining a clean and functional call sidebar experience.
Original PR description
**Description of the issue this PR addresses:** Prevent call participant name overflow **Current behavior before PR:** Before this PR, long participant names in the call sidebar could overflow their container, distorting the layout and causing the call action icons to shift incorrectly. **Desired behavior after PR is merged:** This PR ensures long names are now handled safely, preventing any layout breakage in the call participants sidebar. Before: <img width="302" height="125" alt="image" src="https://github.com/user-attachments/assets/309d3a0e-8304-43ee-ab22-0d7ee2883fc1" /> After: <img width="289" height="119" alt="image" src="https://github.com/user-attachments/assets/6c838fff-70d2-443a-b651-b985afe9cea6" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237327
This update adjusts the spacing around message type notifications to improve the user interface. Previously, notifications felt cramped due to insufficient spacing between the message text and reactions. This fix removes a negative margin, creating a cleaner and more comfortable viewing experience.
Original PR description
Before this commit, the spacing between the text content of a message of type notification and the reactions was too small and resulted in the UI feeling cramped. This commit fixes the issue by removing the negative top margin in message reactions for messages that don't have enough padding. | Before | After | | ------------- | ------------- | | <img width="207" height="223" alt="Pasted image 20251124144956" src="https://github.com/user-attachments/assets/f23c070c-6253-440a-8b93-7b546daabda3" /> | <img width="202" height="236" alt="image" src="https://github.com/user-attachments/assets/e366a2ba-f851-4676-b108-bebf2fb12ec8" /> | task-5344759 Forward-Port-Of: odoo/odoo#237120
This update fixes an issue where the course search dropdown was incorrectly positioned above the search input on the homepage. The fix ensures the dropdown appears correctly within the search form layout, providing a better user experience for finding courses.
Original PR description
Scenario: go to homepage > Courses > one "View all" > type in search Result: dropdown with result is shown over the search input Issue: search form is in flex layout, but the dropdown is displayed in absolute so it is outside of flex flow and is positionned at the top-right of the form container. History: - before bootstrap 4 (odoo 15): the search form had a flex layout, but bootstrap dropdown used "top:100%" so were positionned at the bottom of it. - as of bootstrap 5 (odoo 16): the form kept a flex layout, but bootstrap dropdown now used "position: absolute" with unset top putting them below the search item in a block container, but over it in a flex layout. Fix: when the search bar is displayed, display it as block. opw-4735257 Forward-Port-Of: odoo/odoo#206909
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