Daily updates from Odoo
Wednesday, July 9, 2025
78 changes
29 changes
Resolved issues and error corrections
Bookkeepers can now open return forms from the dashboard even when no opening date has been set. Closing or resetting a tax return also works without access errors when the system updates lock dates, reducing interruptions in tax return workflows.
Original PR description
- Trying to open the returns form the dashboard failed for bookkeepers when no opening date was set, since the wizard used to set them is restricted to administrators only. - When closing a tax return, an access error was triggered when trying to set the lock date. - When resetting a tax return, an access error was triggered when trying to set the lock date. Forward-Port-Of: odoo/enterprise#89610
The Belgian point of sale fiscal device now starts listening for replies before sending a request. This prevents rare timing issues where a fast device response could be missed, leaving the checkout process waiting indefinitely.
Original PR description
Before this commit, the listener to the longpolling or the websocket was added (subscribe for websocket and addListener for longpolling) after the action was sent to the IoT. The answer could be sent before we even listen to it so the answer was never received. This could cause infinite waiting. Forward-Port-Of: odoo/enterprise#89753
Field Service users can now open and generate task report details from the customer portal without hitting an error when only the core Field Service app is installed. The report filename logic was moved into the main Field Service module so the portal flow works reliably without requiring the optional reporting add-on.
Original PR description
An error occurs when a user attempts to generate a report from the portal because the `industry_fsm_report` module is not installed. **Steps to reproduce:** * Install `industry_fsm` * Field Service>New Task>log time sheet using `start` button * open portal view( `/my/tasks` )> Your created task> `View details` `AttributeError: 'project.task' object has no attribute '_get_report_base_filename'` **Solution:** * Define `_get_report_base_filename` inside `industry_fsm` instead of `industry_fsm_report`. **Sentry-6685756279** Forward-Port-Of: odoo/enterprise#89615 Forward-Port-Of: odoo/enterprise#87949
VoIP now removes parentheses when preparing phone numbers for calls. This helps ensure numbers saved or entered with common formatting, such as area codes in parentheses, are dialed correctly.
Original PR description
Add parentheses to the list of characters that are stripped from phone numbers. Part of task-4891947. Forward-Port-Of: odoo/enterprise#89625 Forward-Port-Of: odoo/enterprise#89551
This fixes WhatsApp functionality so it loads correctly in all relevant Odoo pages, including public discussion pages, live chat, portal chatter, and back-end screens. It helps ensure WhatsApp messages and related features behave reliably no matter where users receive or view them.
Original PR description
`common` folder should be included in all bundles. This is especially necessary when broadcasting messages on the bus, because these messages will be received in all tabs, including those potentially not in the back-end, such the discuss public page, any page where a live chat is opened, or a portal page with a chatter. This is also necessary just to have all features properly working in all context, there is no reason that a whatsapp viewed in the public page should not have its features working as intended. runbot-223082
The Point of Sale appointment screen now correctly shows the empty bookings illustration when no bookings are available. This prevents an error from interrupting users after changing the booking view filters.
Original PR description
Steps to reproduce: ------------------------- - Open pos enabled with bookings. - Open booking tab and in gantt view remove groupby filter. Issue: ------- There will be a traceback. Cause: -------- When there are no bookings available it tries to load no booking svg template, which is not loaded in the assets. Fix --- We have loaded the missing asset file to ensure the SVG displays correctly when there are no bookings. task: 4912389
Swiss payroll-specific employee fields are now only shown for Swiss companies in multi-company setups. This prevents users in companies from other countries from seeing irrelevant Swiss payroll information, reducing confusion and keeping employee screens country-appropriate.
Original PR description
When using odoo in multi company with Swiss installed, we can see the fields from any other company. They should be hidden if the country is not Swiss. Task: 4788657
The signing template view now hides edit icons when users are only previewing a template, reducing visual clutter and preventing confusion. The document menu button display was also corrected, making the template viewing experience more consistent.
Original PR description
Hide the pencil (edit) icons in the sign_template_sidebar view when in template visualization mode. Also fixed the document menu button to ensure it appears correctly. These changes provide a cleaner and more consistent template viewing experience. task-4908825 This fix depends on the related [Enterprise PR #89129](https://github.com/odoo/enterprise/pull/89129), which should be merged first as it contains another part of the task.
The UAE Corporate Tax Report now prevents tax amounts from appearing as negative when taxable profit is below the exemption threshold. This avoids misleading report totals and correctly shows zero tax due in these cases.
Original PR description
The Corporate Tax Report was incorrectly showing a negative"Corporate TAX Amount" when the taxable profit fell below the exemption threshold (e.g 375,000 AED). This issue happened because the formula used to compute the Corporate TAX Amount was: `AE_CORP_TAXABLE.balance * (AE_CORP_TAX_PERC.balance / 100)` This formula applies the tax rate even when `AE_CORP_TAXABLE.balance` is negative, which results in an incorrect negative tax amount in the report. Since the report engine doesn't support conditional logic like `max(...)` or `> 0` in XML formulas, we couldn't fix this in the formula definition directly. To solve the issue, we added a check in the Python report handler `_custom_line_postprocessor` to override the value of the Corporate TAX Amount and cap it at zero when it would otherwise be negative. Steps to reproduce: In run bot or any db go to Corporate tax report OPW-4739052 Forward-Port-Of: odoo/enterprise#86087
This fix prevents an error when a user removes the description from a journal item in Uruguay electronic invoicing. It ensures invoices can still generate the required DGI XML correctly, avoiding disruption from an empty description field.
Original PR description
This PR addresses an issue encountered when the product description is removed from an account.move.line within the "Journal items" section. ### Problem: Normally, the `account.move.line` description…
This PR addresses an issue encountered when the product description is removed from an account.move.line within the "Journal items" section. ### Problem: Normally, the `account.move.line` description automatically populates with the product name upon line creation. However, users can intentionally clear this field. If the description field becomes empty, its value is interpreted as `False`. This leads to an `AttributeError: 'bool' object has no attribute 'replace'` traceback when the `_l10n_uy_edi_get_line_nom_and_desc` method attempts to process this boolean value, as it expects a string. This issue specifically affects the generation of the "DscItem" tag in the XML file sent to DGI. ### Solution: To prevent this error, an additional validation has been implemented for the line description. This validation ensures that if the field's value is `False`, it is not processed by the `_l10n_uy_edi_get_line_nom_and_desc` method, thus avoiding the traceback. Forward-Port-Of: odoo/enterprise#89407
The VoIP softphone now uses a minus icon instead of an X to hide the call window. This reduces confusion and hesitation for users who may worry that clicking the button will end their active call.
Original PR description
The "cross icon" (X) is believed to be too "scary"; people don't dare to click it in the middle of a call out of fear of hanging up, even though the softphone window might be in their way. The "minus icon" (-) might deceive one's expectations by hiding the window rather than minimizing it, but we decided that it was still better this way. Part of task-4891947. Forward-Port-Of: odoo/enterprise#89555
This update ensures the Indian GSTR-1 report JSON always includes an expected empty document issue section when there are no entries. It prevents automated validation failures, helping keep tax report generation checks reliable without changing business workflows.
Original PR description
- Assigned doc_issue with empty list to comply with formatting of gstr1 json. - This prevents test failures caused by missing keys during JSON validation. runbot error: 229705 Forward-Port-Of: odoo/enterprise#89711 Forward-Port-Of: odoo/enterprise#89635
Budget reports now handle negative purchase order lines, such as discounts, without creating an extra duplicated budget entry. This keeps budget figures accurate when bills include discount lines tied to a project or analytic account.
Original PR description
Steps to reproduce: - Create a new Budget with budget line having Project [TEST] - Create a purchase order with 2 lines: 1. Product A, analytic [TEST], price unit 100, qty 1 2. Product B, analytic [TEST], price unit -10, qty 1 - Confirm the PO, mark products as received - Create the bill and confirm - Go back in PO, click on Budget smart button, open list view Issue: The budget report will correctly show a line for each invoiced line, but an extra line with double discount amount is present Occurs because we use a SQL code to replicate the qty_invoiced field of a purchase order line, but we adjust the sign based on the aml balance instead of taking into account the move type opw-4775631 Forward-Port-Of: odoo/enterprise#89545
Brazilian electronic invoices now choose the correct invoice purpose in more common business cases instead of always using the standard purpose. This helps invoices, credit notes, and debit notes pass EDI validation when product, vendor, customer, or operation details require a different purpose.
Original PR description
We hardcoded the standard purpose (finNFe) and goal for invoices, credit notes and debit notes. In certain cases however, the purpose is must be different for EDI to succeed (based on the combination of sold product types, vendor and customer). In master we will likely add some fields on the operation type so the user can choose, but in stable we can already determine some other common cases based on the operation type. Using XML ids was considered but since users can create and edit operation types [1] it's better to use the technical names. [1] Since odoo/enterprise#73198 opw-4832447
Bank statement line imports now preserve an included statement reference instead of always creating a new bank statement. This prevents duplicated statements and keeps imported reconciliation data aligned with the original records.
Original PR description
…id during import In the override of execute_import of account_bank_statement_import_csv.py a new account.bank.statement was always created even if the import contained statement_id. Steps to reproduce: - Export an account.bank.statement.line in bank rec with the statement_id included. - Import it back. The statement_id of the imported lines is a new one. opw-4753864 Forward-Port-Of: odoo/enterprise#87885 Forward-Port-Of: odoo/enterprise#87165
This fix corrects an internal automated test so it no longer overlooks missing database indexes in certain data setups. It also adds the missed indexes across several Odoo Enterprise modules, helping prevent performance issues from reaching later CI runs or production environments.
Original PR description
Description ----------- The test `.test_enforce_index_on_one2many_inverse` was added to fail upon a missing index, so developers could add them during development, before merging. One of the criteria…
Description ----------- The test `.test_enforce_index_on_one2many_inverse` was added to fail upon a missing index, so developers could add them during development, before merging. One of the criteria used to ignore the field for indexing was if it belongs to a `test` model in some test module. The best-effort heuristic used for this is to see if there is some `ir.model. data` associated with the model in question and if all module's names associated with these data entries have `test`, then we can ignore the field for indexing. But due to the semantics of `all` for empty collections: ```py assert all([]) is True ``` models that had *no* `ir.model.data` associated at all, e.g. install `--without-demo` and no master data, the field would be ignored for indexing, leading to a passing test. But on nightly, where the CI is run with demo data also, the field isn't ignored anymore and is caught by the test's assertion for indexing suggestion as expected. This leads to errors that are never addressed by the developer that added the fields in question. This commits corrects the test and add the missing indexes that were raised from the CI's false-positive that were missed. Reference --------- runbot-227546 Forward-Port-Of: odoo/enterprise#88998
This fix prevents an error when users run reconciliation models without any bank statement lines available to process. Accounting teams can now run internal transfer reconciliation models safely even when there is nothing to reconcile.
Original PR description
SQL syntax error occurs when trying to auto reconcile transactions via reconcile models,it is because there are no statement lines to reconcile. **Steps to reproduce:** * Install `accountant` module (No demo data needed) * Accounting Dashboard> Bank dropdown menu * Under reconciliation>Models>Internal Transfers>Run Now `syntax error at or near ')' LINE 57: WHERE st_line.id IN ()` **Solution:** * Return the function if there are no statement to reconcile. **Sentry-6610155279** Forward-Port-Of: odoo/enterprise#85937
The map view now opens Google Maps using the contact's full address instead of relying on saved latitude and longitude coordinates. This avoids incorrect Google Maps results when another geolocation provider, such as OpenStreetMap, produced less precise coordinates.
Original PR description
**Steps to reproduce:** - Install Contact app - Create a contact with a specific address - Go to the Map View of the Contact app - Filter to view the new contact - Position in the map might be…
**Steps to reproduce:** - Install Contact app - Create a contact with a specific address - Go to the Map View of the Contact app - Filter to view the new contact - Position in the map might be slightly different from given one (when using OpenStreeMap) - Click on the position marker > `Navigate To` the address is recomputed correctly - Click on `View in Google Maps` the address given is often wrong **Issue:** Previous solution was trying to build the url used by the `View in Google Maps` button by using `partner_latitude` and `partner_longitude`. These were previously computed using the default geolocalization method. If it was set on OpenStreetMap, the coordinates were not precise enough and impacted the Google Maps results. As described in the documentation : `OpenStreetMap might not always be accurate.` But this shouldn't impact Google Place API results. **Fix:** Adapted the computation of `googleMapUrl()` to use `contact_address_complete` to ensure the addresses are recomputed properly when sent to Google Maps. opw-4649910 Forward-Port-Of: odoo/enterprise#87430
This fixes an issue where the refund reason prompt did not appear in Point of Sale when Spanish TicketBAI and Peruvian electronic invoicing features were both installed. Refund workflows now behave as expected, helping staff capture required refund information reliably.
Original PR description
When both l10n_es_pos_tbai and l10n_pe_edi_pos are installed, the refund reason popup was not showing up because we were not awaiting the super method call in the l10n_pe_edi_pos override. runbot-227630 Forward-Port-Of: odoo/enterprise#89423 Forward-Port-Of: odoo/enterprise#88813
This update fixes issues with the Payroll tab on employee records across multiple country-specific payroll setups. It helps HR and payroll users access the expected employee payroll information consistently, reducing confusion when working in localized payroll configurations.
Original PR description
This fixes the payroll tab in the inherited view of employee for various loca. Task: 4885749
Opening the filters panel in the subscription dashboard no longer fails when some filters do not apply to the current data model. The change skips irrelevant filters when preparing suggestions, improving dashboard editing reliability for users.
Original PR description
Steps to reproduce: 1. Edit the subscription dashboard 2. Open the filters side panel => Boom This is caused by the fact that the suggestions store was trying to match filters that are not matching the current model. Task: 4911733
Tax reports now show the correct net base amount when invoice lines share the same tax but use different analytic distributions. This prevents overstated tax report figures while keeping the calculated tax amount unchanged.
Original PR description
### Issue: When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report. ### Steps to reproduce: - Create a new tax on sales…
### Issue: When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report. ### Steps to reproduce: - Create a new tax on sales (eg 10%) - Make sure the option "Analytic Accounting" is ticked in the settings - Create an invoice with two lines (eg both at $100), add the tax on both - Change the analytic distribution on both lines to different values - Confirm the invoice - Go to the tax report - Select the report "Group By: Account > Tax" - On the report the "Net" amount is doubled ($400), the tax amount is correct ($20) ### Cause: On the invoice we can see in "Journal Items" that two tax lines are created instead of one (one for each analytic distribution). The "Group By" reports are generated by [this query](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L92). At the [creation of the second subtable](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L164-L198) the move lines are linked together based among other things on the tax id. The [filter on analytic distribution](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L187-L191) does not apply here as `tax.analytic = False`. The result is that each tax line is linked with both base lines. The second subtable have 4 lines in this case, with each base line doubled. The result of the query have the base amount doubled. ### Solution: We cannot fix the query as there is no link to find the tax line origin amongst the base lines. The method `_read_generic_tax_report_amounts` in `account_reports` is made to fix the base values in report in case of duplicate. Until now it did not include the duplication caused by analytic distribution but duplication because of repartition lines for example. The fix is to use this method also for analytic distribution. So we add `tdr.analytic_distribution` in the `GROUP BY`. This value must be returned by the query in `account` so we add it. opw-4753676 Forward-Port-Of: odoo/enterprise#89569 Forward-Port-Of: odoo/enterprise#87404
Customer follow-up reports now ignore accounting entries that do not have a due date or payment terms. This prevents customers from being incorrectly marked for follow-up and avoids misleading statements showing action needed when the balance is actually zero.
Original PR description
### Issue: It is possible to break the followup reports by directly creating entries in the past. ### Steps to reproduce: - Example on Belgian loca - Accounting Dashboard > Misc > new Entry with -…
### Issue: It is possible to break the followup reports by directly creating entries in the past. ### Steps to reproduce: - Example on Belgian loca - Accounting Dashboard > Misc > new Entry with - Date far in the past (ie 2024-01-01) - Account: "400000 Customers", Partner: "test partner", Debit: 500.0 - Account: "499000 Suspense Accounts", Credit: 500.0 - Post - In Customers > Follow-up reports, the partner is marked as "In need of action" even if no due date was specified - Accounting Dashboard > Bank > new with Amount: 500.0 - "Save & Close" then click on it - In the page "Manual Operations" change the partner to the one from the MISC entry - Change the Account to "400000 Customers" - Validate - The follow-up report is no longer "In need of action" - Create an invoice with a due date in the future - The follow-up report is back to "In need of action" with the amount of the invoice - When sending the follow-up, the Customer statement reads "your account shows an outstanding balance of 0.00€" ### Cause: The origin of this issue is that the MISC entry and the Bank payment are not reconciled. The MISC entry is used to calculate the state of the followup making it to "In need of action" but the bank entry is balancing the amount to 0.00€. The MISC entry should not be used to compute the followup state as it has no due date specified (it makes no sense, it is never linked to any invoice). But in the code when there are no `line.date_maturity` we fallback on `line.date`. ### Solution: The lines without due date or payment term should not be used to compute the state of the followup or calculate the total due. So we remove the fallbacks on `line.date` when `line.date_maturity` is False. Some tests needed to be adjusted as they were not using any payment terms or due date. They were working because of the fallback on `line.date`. opw-4784250 Forward-Port-Of: odoo/enterprise#89627 Forward-Port-Of: odoo/enterprise#87873
Fixed an issue that could stop a barcode scanner from being assigned during Point of Sale IoT setup. This helps stores complete device configuration smoothly and avoids a setup error reported in monitoring.
Original PR description
The error occurs because `append()` is used on the Many2many field `iface_scanner_ids` in `pos_config`, which is not allowed. Traceback: `AttributeError: 'iot.device' object has no attribute 'append'` Many2many fields should be updated using `|=` to add records, as the Python list method `append` is not supported for relational fields. [1]- https://github.com/odoo/enterprise/blob/5bff585cfa24940626b14cdeaeae07b50a931e94/pos_iot/wizard/auto_config_pos_iot.py#L55 sentry-6719710908 Forward-Port-Of: odoo/enterprise#89123
The Signed Contract button now opens the correct employee contract version after all required signatures are completed. This prevents confusion for HR users and helps ensure they review the right signed offer information.
Original PR description
- Fixed an issue where clicking the "Signed Contract" smartbutton after full signature opened an incorrect employee version. Task-4873800
When a new employee contract is created through the salary configurator, the previous contract now automatically ends the day before the new one starts. This prevents overlapping contract records and helps keep employee contract timelines accurate without manual correction.
Original PR description
When you create a new contract through the salary configurator flow, it will create automatically a new version with the date encoded in the offer wizard. However, the 'contract_end_date' for the old version is not automatically updated. The logic has been adjusted to end old contract date the day before the new contract's start date.
Updated automated tests now verify XML namespace details for payment and electronic invoicing files. This helps ensure country-specific EDI documents and ISO 20022 payment files match required standards more accurately, reducing the risk of undetected format issues.
Original PR description
Before, we weren't asserting XML namespaces when calling `assertXmlTreeEqual`. As a result, many expected XMLs in EDI tests had incorrect namespaces. Now that we change the test method to check namespaces, we also need to fix the expected XMLs. Community PR: https://github.com/odoo/odoo/pull/214764 task-none Forward-Port-Of: odoo/enterprise#89303 Forward-Port-Of: odoo/enterprise#87950
Website forms now correctly use automatically filled values when deciding which fields to show or hide. This prevents visitors from seeing incomplete form behavior when a field should appear based on prefilled information such as their email address.
Original PR description
When [1] introduced a cached version of the form data to compute visibility, it did not take into account the values that are completed through `prefillValues`. Because of this, input events are required for those to be taken into account. This commit fixes this by re-evaluating the form content after the execution of `prefillValues`. Steps to reproduce: - Drop a "Form" snippet - Make "Your Question" field visible only if "Your Email" is set. - Save page. => Upon display, the email is populated with the user's email, but "Your Question" did not become visible. [1]: https://github.com/odoo/odoo/commit/027ce4e3991c9fefdbbb862a69f73e865a1100c8 task-jke Forward-Port-Of: odoo/odoo#217729
The website editor test for text highlighting has been updated to match the new Website Builder layout. This helps ensure the text highlight feature continues to work reliably after its controls moved to a more convenient overlay.
Original PR description
This PR re-enables the test_website_text_highlights test, which was broken and skipped due to the DOM changes introduced by the new Website Builder. It also adapts the tour selectors accordingly. Previously, the text highlight option was available in the option bar, but in the new Website Builder, it has been moved to the overlay for easier editing.
29 changes
Resolved issues and error corrections
Credit notes in the Kenya eTIMS workflow can now only be submitted when they are linked to an invoice that was already successfully submitted. This helps prevent rejected or invalid credit note submissions and keeps tax reporting aligned with eTIMS requirements.
Original PR description
To ensure credit notes are only submitted for invoices that have been submitted to eTIMS, we now restrict credit note submission to cases where the related invoice has already been successfully submitted. Forward-Port-Of: odoo/enterprise#89464 Forward-Port-Of: odoo/enterprise#89385
This update prevents translation-related errors that could occur when sharing referral links or working with loan records. The change improves reliability by adjusting how translated text is prepared, without changing user-facing features.
Original PR description
Issue: Prior to this commit, a translation issue occurred due to the use of a list comprehension. The _get_translation_source function attempts to scan the local variables, but in the context of a list comprehension, only variables defined within the comprehension are accessible. As a result, variables like uuid and cursor were not available to the _get_lang function, ultimately leading to an error. Fix: Replaced the list comprehension with a standard for loop to ensure proper access to local variables. runbot-98198 Forward-Port-Of: odoo/enterprise#88632
The intercompany rules settings now use clearer wording for the option related to creating invoices. This reduces confusion for users configuring automated transactions between companies.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/4b57698670a7762bb206ccb24417d63c8edc1a46 change the ux of the intercompany rules, but the naming is confusing for users. task-4907810 Forward-Port-Of: odoo/enterprise#89368
The Time Off Type configuration form now displays localization and payroll-related options in a more consistent two-column layout. This makes the setup screen easier to scan and use, with the Payroll section placed more logically below Negative Cap settings.
Original PR description
* = l10n_in_hr_holidays, l10n_ae_hr_payroll, l10n_be_hr_payroll Steps: - Navigate to Time Off > Configuration > Time Off Types. - Open any time off type form with localization or payroll-related options. Issues: - Configuration fields (including localization modules) appeared misaligned. - The Payroll section was not utilizing space effectively in the layout. Fix: - Aligned all configuration fields in a consistent two-column layout, including localization and payroll-related options., - Repositioned the Payroll section below the Negative Cap section. Task - 4759116
Customer follow-up reports now ignore accounting entries that do not have a due date or payment terms. This prevents customers from being incorrectly flagged for follow-up or receiving statements that show a zero balance as overdue.
Original PR description
### Issue: It is possible to break the followup reports by directly creating entries in the past. ### Steps to reproduce: - Example on Belgian loca - Accounting Dashboard > Misc > new Entry with -…
### Issue: It is possible to break the followup reports by directly creating entries in the past. ### Steps to reproduce: - Example on Belgian loca - Accounting Dashboard > Misc > new Entry with - Date far in the past (ie 2024-01-01) - Account: "400000 Customers", Partner: "test partner", Debit: 500.0 - Account: "499000 Suspense Accounts", Credit: 500.0 - Post - In Customers > Follow-up reports, the partner is marked as "In need of action" even if no due date was specified - Accounting Dashboard > Bank > new with Amount: 500.0 - "Save & Close" then click on it - In the page "Manual Operations" change the partner to the one from the MISC entry - Change the Account to "400000 Customers" - Validate - The follow-up report is no longer "In need of action" - Create an invoice with a due date in the future - The follow-up report is back to "In need of action" with the amount of the invoice - When sending the follow-up, the Customer statement reads "your account shows an outstanding balance of 0.00€" ### Cause: The origin of this issue is that the MISC entry and the Bank payment are not reconciled. The MISC entry is used to calculate the state of the followup making it to "In need of action" but the bank entry is balancing the amount to 0.00€. The MISC entry should not be used to compute the followup state as it has no due date specified (it makes no sense, it is never linked to any invoice). But in the code when there are no `line.date_maturity` we fallback on `line.date`. ### Solution: The lines without due date or payment term should not be used to compute the state of the followup or calculate the total due. So we remove the fallbacks on `line.date` when `line.date_maturity` is False. Some tests needed to be adjusted as they were not using any payment terms or due date. They were working because of the fallback on `line.date`. opw-4784250 Forward-Port-Of: odoo/enterprise#89627 Forward-Port-Of: odoo/enterprise#87873
This fix ensures several enterprise apps consistently target real-time message updates to the correct recipients. It helps prevent missed or misrouted notifications in workflows such as approvals, knowledge articles, helpdesk live chat, VoIP, e-invoicing, and WhatsApp conversations.
Original PR description
\* = approvals, knowledge, l10n_mx_edi, voip, website_helpdesk_livechat, whatsapp Enterprise counter-part. https://github.com/odoo/odoo/pull/215869 Forward-Port-Of: odoo/enterprise#88531
Fixes an issue where tax reports could overstate the net taxable amount when invoice lines used the same tax but different analytic distributions. This helps businesses rely on accurate tax reporting while keeping the tax amount calculation unchanged.
Original PR description
### Issue: When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report. ### Steps to reproduce: - Create a new tax on sales…
### Issue: When having two lines on an invoice with the same tax and different analytic distribution, the base value is doubled on the tax report. ### Steps to reproduce: - Create a new tax on sales (eg 10%) - Make sure the option "Analytic Accounting" is ticked in the settings - Create an invoice with two lines (eg both at $100), add the tax on both - Change the analytic distribution on both lines to different values - Confirm the invoice - Go to the tax report - Select the report "Group By: Account > Tax" - On the report the "Net" amount is doubled ($400), the tax amount is correct ($20) ### Cause: On the invoice we can see in "Journal Items" that two tax lines are created instead of one (one for each analytic distribution). The "Group By" reports are generated by [this query](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L92). At the [creation of the second subtable](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L164-L198) the move lines are linked together based among other things on the tax id. The [filter on analytic distribution](https://github.com/odoo/odoo/blob/51fcbd211d2b1abf4b93becedbcbb9e03002cdd6/addons/account/models/account_move_line_tax_details.py#L187-L191) does not apply here as `tax.analytic = False`. The result is that each tax line is linked with both base lines. The second subtable have 4 lines in this case, with each base line doubled. The result of the query have the base amount doubled. ### Solution: We cannot fix the query as there is no link to find the tax line origin amongst the base lines. The method `_read_generic_tax_report_amounts` in `account_reports` is made to fix the base values in report in case of duplicate. Until now it did not include the duplication caused by analytic distribution but duplication because of repartition lines for example. The fix is to use this method also for analytic distribution. So we add `tdr.analytic_distribution` in the `GROUP BY`. This value must be returned by the query in `account` so we add it. opw-4753676 Forward-Port-Of: odoo/enterprise#89569 Forward-Port-Of: odoo/enterprise#87404
The Contact map view now opens Google Maps using the contact's full address instead of potentially imprecise stored coordinates. This helps users get the correct destination when choosing to view a contact location in Google Maps, especially when OpenStreetMap geolocation is less accurate.
Original PR description
**Steps to reproduce:** - Install Contact app - Create a contact with a specific address - Go to the Map View of the Contact app - Filter to view the new contact - Position in the map might be…
**Steps to reproduce:** - Install Contact app - Create a contact with a specific address - Go to the Map View of the Contact app - Filter to view the new contact - Position in the map might be slightly different from given one (when using OpenStreeMap) - Click on the position marker > `Navigate To` the address is recomputed correctly - Click on `View in Google Maps` the address given is often wrong **Issue:** Previous solution was trying to build the url used by the `View in Google Maps` button by using `partner_latitude` and `partner_longitude`. These were previously computed using the default geolocalization method. If it was set on OpenStreetMap, the coordinates were not precise enough and impacted the Google Maps results. As described in the documentation : `OpenStreetMap might not always be accurate.` But this shouldn't impact Google Place API results. **Fix:** Adapted the computation of `googleMapUrl()` to use `contact_address_complete` to ensure the addresses are recomputed properly when sent to Google Maps. opw-4649910 Forward-Port-Of: odoo/enterprise#87430
This fix adjusts the payroll expense test setup so it no longer uses a default account that could cause duplicate accounting entries to be selected. It helps keep payroll expense reconciliation checks reliable after recent accounting logic changes.
Original PR description
This commit removes the default account set in the setup of test_payroll_expense. Because of 67b5fc47ca4aa1abb60f198a87d7784ef400f796 the filter in get_all_amls_to_be_reconciled would get multiples amls instead of only one. community pr: https://github.com/odoo/odoo/pull/211443 opw-4751270 Forward-Port-Of: odoo/enterprise#88862 Forward-Port-Of: odoo/enterprise#86987
Planning now calculates open shifts correctly when a copied weekly schedule includes a day where an employee is on leave. This prevents lunch breaks from being counted as extra allocated time, giving managers more accurate staffing hours.
Original PR description
**Issue:**
When a resource is on leave for a particular day, and an open shift is created for that day, the open shift includes lunch time, which causes the total allocated hours to be incorrect.
**Example:**
- Shift duration: 1 week (27th to 31st January)
- Resource on leave on 30th January
- Move to the next week and copy the previous week's shift
- New shift created:
- Monday to Wednesday and Friday assigned
- Open shift on Thursday (9 hours allocated)
However, 1 extra hour is added in the open shift.
**Steps to Reproduce:**
-Install the planning_holidays module.
- Create a shift for the week (27th to 31st January).
- Add leave for 6th February.
- Copy the previous week's shift.
- Check the allocated hours for 6th February.
task-4224781
Forward-Port-Of: odoo/enterprise#89542
Forward-Port-Of: odoo/enterprise#73478The update prevents an error when users run automatic reconciliation models without any bank statement lines available. Instead of failing with a database error, the process now exits cleanly, improving reliability for accounting workflows.
Original PR description
SQL syntax error occurs when trying to auto reconcile transactions via reconcile models,it is because there are no statement lines to reconcile. **Steps to reproduce:** * Install `accountant` module (No demo data needed) * Accounting Dashboard> Bank dropdown menu * Under reconciliation>Models>Internal Transfers>Run Now `syntax error at or near ')' LINE 57: WHERE st_line.id IN ()` **Solution:** * Return the function if there are no statement to reconcile. **Sentry-6610155279** Forward-Port-Of: odoo/enterprise#85937
This fix prevents an error when assigning scanner devices during Point of Sale IoT configuration. Businesses can complete scanner setup more reliably without manual troubleshooting.
Original PR description
The error occurs because `append()` is used on the Many2many field `iface_scanner_ids` in `pos_config`, which is not allowed. Traceback: `AttributeError: 'iot.device' object has no attribute 'append'` Many2many fields should be updated using `|=` to add records, as the Python list method `append` is not supported for relational fields. [1]- https://github.com/odoo/enterprise/blob/5bff585cfa24940626b14cdeaeae07b50a931e94/pos_iot/wizard/auto_config_pos_iot.py#L55 sentry-6719710908 Forward-Port-Of: odoo/enterprise#89123
Opening the filters panel while editing the subscription dashboard no longer causes an error. The fix ensures filter suggestions only use filters relevant to the current dashboard data, improving stability for users managing spreadsheet dashboards.
Original PR description
Steps to reproduce: 1. Edit the subscription dashboard 2. Open the filters side panel => Boom This is caused by the fact that the suggestions store was trying to match filters that are not matching the current model. Task: 4911733 Forward-Port-Of: odoo/enterprise#89606
The update corrects test reference files so they now verify XML namespace details for payment and electronic invoicing formats. This helps catch formatting issues earlier and improves confidence that country-specific electronic documents remain compliant.
Original PR description
Before, we weren't asserting XML namespaces when calling `assertXmlTreeEqual`. As a result, many expected XMLs in EDI tests had incorrect namespaces. Now that we change the test method to check namespaces, we also need to fix the expected XMLs. Community PR: https://github.com/odoo/odoo/pull/214764 task-none Forward-Port-Of: odoo/enterprise#89476 Forward-Port-Of: odoo/enterprise#87950
This fix ensures the Indian GSTR-1 report JSON always includes the expected document issue field, even when there are no entries. It prevents automated validation failures and helps keep tax report generation reliable.
Original PR description
- Assigned doc_issue with empty list to comply with formatting of gstr1 json. - This prevents test failures caused by missing keys during JSON validation. runbot error: 229705 Forward-Port-Of: odoo/enterprise#89711 Forward-Port-Of: odoo/enterprise#89635
Users can now upload files from the Documents app control panel as expected. This fixes a bug where choosing a file appeared to do nothing, helping teams add documents without switching workflows.
Original PR description
Reproduce: 1. In the Documents app's control panel, click on New 2. "Upload" 3. Choose a file and confirm -> nothing happens. Task-4926208
The VoIP softphone now uses a minus icon instead of an X for hiding the call window. This makes users less likely to worry that clicking the control will end their call, improving confidence during active calls.
Original PR description
The "cross icon" (X) is believed to be too "scary"; people don't dare to click it in the middle of a call out of fear of hanging up, even though the softphone window might be in their way. The "minus icon" (-) might deceive one's expectations by hiding the window rather than minimizing it, but we decided that it was still better this way. Part of task-4891947. Forward-Port-Of: odoo/enterprise#89555
CSV imports for bank statement lines now preserve the statement reference already present in the imported file instead of creating a new bank statement every time. This prevents duplicated or incorrect bank statements when teams export and re-import reconciliation data.
Original PR description
…id during import In the override of execute_import of account_bank_statement_import_csv.py a new account.bank.statement was always created even if the import contained statement_id. Steps to reproduce: - Export an account.bank.statement.line in bank rec with the statement_id included. - Import it back. The statement_id of the imported lines is a new one. opw-4753864 Forward-Port-Of: odoo/enterprise#87885 Forward-Port-Of: odoo/enterprise#87165
Creating a new employee contract through the salary configurator now automatically ends the previous contract the day before the new one begins. This prevents overlapping contract periods and keeps employee contract records accurate without manual correction.
Original PR description
When you create a new contract through the salary configurator flow, it will create automatically a new version with the date encoded in the offer wizard. However, the 'contract_end_date' for the old version is not automatically updated. The logic has been adjusted to end old contract date the day before the new contract's start date. Forward-Port-Of: odoo/enterprise#88915
The Signed Contract button on salary offers now opens the correct employee contract version after all signatures are complete. This prevents confusion for HR users and ensures they review the right signed employee information.
Original PR description
- Fixed an issue where clicking the "Signed Contract" smartbutton after full signature opened an incorrect employee version. Task-4873800 Forward-Port-Of: odoo/enterprise#89051
This fixes an error that prevented Belgian companies from exporting the Social Balance Sheet report as PDF or XLSX. Payroll users can now generate the required report without interruption.
Original PR description
Since the introduction of versions, a traceback occurs due to an old function call Task: 4911701 Forward-Port-Of: odoo/enterprise#89149
This fix makes an internal quality check correctly detect missing database indexes in all test environments, preventing issues from being missed before release. It also adds the missing indexes found by the corrected check across accounting, ESG, payroll localization, and point-of-sale areas, improving consistency and reducing future performance risk.
Original PR description
Description ----------- The test `.test_enforce_index_on_one2many_inverse` was added to fail upon a missing index, so developers could add them during development, before merging. One of the criteria…
Description ----------- The test `.test_enforce_index_on_one2many_inverse` was added to fail upon a missing index, so developers could add them during development, before merging. One of the criteria used to ignore the field for indexing was if it belongs to a `test` model in some test module. The best-effort heuristic used for this is to see if there is some `ir.model. data` associated with the model in question and if all module's names associated with these data entries have `test`, then we can ignore the field for indexing. But due to the semantics of `all` for empty collections: ```py assert all([]) is True ``` models that had *no* `ir.model.data` associated at all, e.g. install `--without-demo` and no master data, the field would be ignored for indexing, leading to a passing test. But on nightly, where the CI is run with demo data also, the field isn't ignored anymore and is caught by the test's assertion for indexing suggestion as expected. This leads to errors that are never addressed by the developer that added the fields in question. This commits corrects the test and add the missing indexes that were raised from the CI's false-positive that were missed. Reference --------- runbot-227546 Forward-Port-Of: odoo/enterprise#89732 Forward-Port-Of: odoo/enterprise#88998
This fixes an error that could block Uruguay electronic invoice XML generation when a user manually removed a journal item description. The system now safely handles empty descriptions, helping invoices continue to be processed and sent to DGI.
Original PR description
This PR addresses an issue encountered when the product description is removed from an account.move.line within the "Journal items" section. ### Problem: Normally, the `account.move.line` description…
This PR addresses an issue encountered when the product description is removed from an account.move.line within the "Journal items" section. ### Problem: Normally, the `account.move.line` description automatically populates with the product name upon line creation. However, users can intentionally clear this field. If the description field becomes empty, its value is interpreted as `False`. This leads to an `AttributeError: 'bool' object has no attribute 'replace'` traceback when the `_l10n_uy_edi_get_line_nom_and_desc` method attempts to process this boolean value, as it expects a string. This issue specifically affects the generation of the "DscItem" tag in the XML file sent to DGI. ### Solution: To prevent this error, an additional validation has been implemented for the line description. This validation ensures that if the field's value is `False`, it is not processed by the `_l10n_uy_edi_get_line_nom_and_desc` method, thus avoiding the traceback. Forward-Port-Of: odoo/enterprise#89407
Fixed an issue where purchase order discount lines could create an extra budget report entry with the discount counted twice. Budget views now reflect invoiced purchase lines more accurately, helping teams avoid overstated budget impacts.
Original PR description
Steps to reproduce: - Create a new Budget with budget line having Project [TEST] - Create a purchase order with 2 lines: 1. Product A, analytic [TEST], price unit 100, qty 1 2. Product B, analytic [TEST], price unit -10, qty 1 - Confirm the PO, mark products as received - Create the bill and confirm - Go back in PO, click on Budget smart button, open list view Issue: The budget report will correctly show a line for each invoiced line, but an extra line with double discount amount is present Occurs because we use a SQL code to replicate the qty_invoiced field of a purchase order line, but we adjust the sign based on the aml balance instead of taking into account the move type opw-4775631 Forward-Port-Of: odoo/enterprise#89545
This fixes an internal issue in cash basis accounting reports where report filters could fail because the filtering rules were being modified incorrectly. The change helps reports run reliably and avoids runbot errors without changing business workflows.
Original PR description
Domains are immutable, append replaced by the and operator. runbot error 229710
The employee payroll tab has been corrected in several country-specific payroll setups. This helps HR teams access the right payroll information consistently when viewing employee records.
Original PR description
This fixes the payroll tab in the inherited view of employee for various loca. Task: 4885749 Forward-Port-Of: odoo/enterprise#88734
VoIP now removes parentheses when cleaning phone numbers, so numbers copied or entered with common formatting are processed more reliably. This helps avoid call issues caused by formatted phone numbers such as those containing brackets.
Original PR description
Add parentheses to the list of characters that are stripped from phone numbers. Part of task-4891947. Forward-Port-Of: odoo/enterprise#89625 Forward-Port-Of: odoo/enterprise#89551
This fix improves how Odoo detects overlapping project tasks when filters use related information. It prevents valid overlaps from being missed and corrects a test so planned hours are properly considered.
Original PR description
The query that determines overlapping tasks is making two different Query objects: the first one for the main task and the second one for overlapping tasks. The second query is joined into the first one, injecting the second one's where clause as join condition, but that composition does not work if the second query has extra joins. Those extra joins come from related fields that may occur from the domain. The fix consists in recomposing the query with a join condition that does not depend on a dynamic domain, and injecting the domain in the where clause of the main query. With this strategy, the joins that appear because of the related fields in the domain are part of the main query, and are no longer lost by the composition. Note also that the test test_same_user_overlap_with_allocated_hours_less_than_workable_hours was actually broken, because the field allocated_hours wasn't flushed when doing the SQL query. The new query flushes the field, and the test has been fixed.
This fix ensures that refunds in Point of Sale correctly wait for all required steps before continuing. Businesses using both Spanish TicketBAI and Peruvian e-invoicing POS localizations will now see the required refund reason prompt as expected, reducing refund processing errors.
Original PR description
When both l10n_es_pos_tbai and l10n_pe_edi_pos are installed, the refund reason popup was not showing up because we were not awaiting the super method call in the l10n_pe_edi_pos override. runbot-227630 Forward-Port-Of: odoo/enterprise#89423 Forward-Port-Of: odoo/enterprise#88813
20 changes
Resolved issues and error corrections
This update adjusts an automated test for the HTML editor's link popover to prevent intermittent failures. It helps keep quality checks stable so fixes and improvements can move through validation more reliably.
Original PR description
The fix at [1] did not fix the issue. This is another attempt. runbot-227759 [1]: https://github.com/odoo/odoo/pull/215168/commits/9a3c9ecca14fb8701e4f934cf5285297cbe26310
Odoo now notifies the database when an IoT box's details change, not only when new devices are found. This helps keep device information such as network address, hostname, domain, and version accurate, including more reliable IP detection on Windows.
Original PR description
Currently we notify the database of any iot changes only if the iot box discovered new devices. However if its ip address/hostname/mac address/domain/version change the db is never notified. This PR adds this change + fixes the get_ip() method which was using netifaces which is unreliable on Windows to now use socket to get the iot box ip address
A flaky automated check in the Mail discussion area was stabilized by waiting until a reaction is fully removed before reloading the page. This helps reduce false failures in validation systems and supports smoother delivery of future updates.
Original PR description
Before this commit, tour "discuss_channel_public_tour" was failing non-deterministically at the following step: ``` .o-mail-Message:not(:has(.o-mail-MessageReaction)) ``` This happens because prio steps added a new reaction and asserted it was shown. It clicks on reaction to remove it and then page reload to see the reaction is gone. Problem is that it can reload page too fast and the RPC to remove the reaction did not have time to occurs. This commit fixes the issue by awaiting message no longer has reaction before page reload. Fixes runbot-error-227769
This update fixes an unreliable automated test for message reactions selected from the emoji picker. It helps ensure future changes accurately catch reaction behavior issues without false or inconsistent test results.
Original PR description
Before this commit, test "Add the same reaction twice from the emoji picker" may fail non-deterministically in 18.1 on last step: the message reaction is sometimes kept, sometimes removed. The feature works in 18.0 but no longer in 18.1. The test was still passing though very rarely can fail and actually show the feature doesn't work. This happens because the test is clicking on reaction too fast and doesn't assert on UI the 1st message reaction has been added, thus it may flicker and keep showing there's 1 message reaction still. This commit fixes the test in 18.0, in preparation to keep the same test in 18.1 and show the bugged change of behaviour in 18.1 to fix. Fixes runbot error 229340
The HTML editor font size field now uses the correct text color when dark mode is enabled. This improves readability and consistency for users editing content in dark-themed environments.
Original PR description
Purpose of this PR: - Backport a [PR #206008](https://github.com/odoo/odoo/pull/206008), which ensures that the font-size input now changes its color appropriately in dark mode. task-4897771 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes the Discuss channel test wait for a fully saved message before trying to add a reaction. It prevents intermittent automated test failures caused by reacting to a temporary message that is replaced moments later.
Original PR description
Backport of https://github.com/odoo/odoo/pull/217982 [FIX] mail: fix runbot error 222093 (o-mail-Message:contains(cheese)) Before this commit, tour "test_discuss_channel_public_page_as_guest" would…
Backport of https://github.com/odoo/odoo/pull/217982 [FIX] mail: fix runbot error 222093 (o-mail-Message:contains(cheese)) Before this commit, tour "test_discuss_channel_public_page_as_guest" would crash in test after posting a message in which we attempt to add a reaction. This happens because the step is a `hover && click 'Add a reaction'`, so it hovers on selector `o-mail-Message:contains(cheese)` then clicks on the 'Add a reaction' action. In discuss channels, when sending a message, the message is immediately shown on UI before there's a genuine message that is created in DB. This optimistic behavior gives impression the app is fast, but some actions require a genuine message like 'Add a reaction'. The problem of test is that selector `.o-mail-Message:contains(cheese)` passes with temporary / transient message of optimistic behavior, so the `hover` step would be triggered on the temporary / transient message and 'Add a reaction' action is awaited for click. Problem is that when genuine message data is received, implementation detail deletes the temporary / transient message and then shows the genuine message. Because the genuine message is different, component identity is different (it uses message.localId in `t-key`), thus it awaits `Add a reaction` on UI but it's not visible because we need to hover again, this time on genuine message. This commit fixes the issue by awaiting message is shown on UI is the persistent, i.e. non-temporary and non-transient, so that hover and click on the 'Add a reaction' action works without issue. fixes runbot error 181660 fixes runbot error 222093 fixes runbot error 227756 fixes runbot error 227758
When a shopper updates their address outside the checkout flow, open website carts now refresh the applicable tax rules before payment. This helps ensure customers are charged the correct taxes based on their address and avoids incorrect order totals.
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a fiscal position with a country-based tax mapping; 2. go to `/shop` as a public user, 3. create a new account; 4. add a product to your cart; 5. go to…
Versions -------- - 16.0+ Steps ----- 1. Have a fiscal position with a country-based tax mapping; 2. go to `/shop` as a public user, 3. create a new account; 4. add a product to your cart; 5. go to user settings & add an address that matches the fiscal position; 6. go to checkout & pay for the cart. Issue ----- The fiscal position's taxes aren't applied to the order. Cause ----- The `_compute_fiscal_position_id` method is triggered when changing the `partner_id` or `partner_shipping_id` of an order. It does not trigger when modifying the address of the order's current partner. There is logic in place to recompute fiscal position & taxes when an address gets entered via checkout, but not via any other route. Solution -------- Adding address fields to the `api.depends` of the compute method could introduce the unintended behavior of changing taxes & fiscal position of confirmed sale orders. Instead, we can check for fields relevant to fiscal position in `write`, then search for unconfirmed website orders, and recompute their fiscal position & taxes if need be. opw-4844132 opw-4753332 Forward-Port-Of: odoo/odoo#217721 Forward-Port-Of: odoo/odoo#214588
Expense posting no longer requires an employee to have a work email address. This prevents valid expense reports from being blocked when partner records can now be created without that email information.
Original PR description
- removed work email constraint while posting the expense as the partner is now created without the need of work email --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product back-in-stock notification emails no longer display a price that may exclude taxes. This avoids confusing customers when website prices are configured to include taxes and keeps the email focused on product availability.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Configure website to display prices tax-included; 2. disable selling out-of-stock products; 3. go to an out-of-stock product page; 4. request a reminder email; 5. replenish product stock; 6. run the `_send_availability_email` action; 7. check email that was sent. Issue ----- The price display in the email does not include taxes. Cause ----- The email only checks the `list_price` defined on the product. Solution -------- Don't include the price in the email: - On stable: hide the element to avoid breaking xpaths - On master: remove the price element from the email template opw-4712613 Forward-Port-Of: odoo/odoo#215292
This fix makes the HTML editor handle preformatted text areas more consistently. Pasted content inside these areas is treated as plain text while preserving list numbers and markers, reducing unexpected formatting issues for users.
Original PR description
Description of the issue this PR addresses: Current behavior before PR: `pre` was not considered paragraph related element. Also it allowed flow content. Desired behavior after PR is merged: `pre` is considered paragraph related element and now it only allows phrasing content also anything pasted within `pre` is now pasted as plain text and list numbering and markers are preserved. task-4766648 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Changing the product on a sales quotation now recalculates the line price, even if the previous price had been manually adjusted. This prevents outdated prices from carrying over to a different product and helps keep quotations accurate.
Original PR description
step to reproduce - Create a quotation, - Select a product - Update the price manually - change the product - The amount stays the same expectation: with change of product in SO, price should also recompute issue: currently,`_compute_price_unit` depends on `technical_price_unit` such that `price_unit` won't update if `price_unit` and `technical_price_unit` are not same. which is the case when price_unit was manually set, regardless of the product https://github.com/odoo/odoo/blob/12ef230df58122fbdac0b4c1b4781c535b8516ba/addons/sale/models/sale_order_line.py#L567-L570 we should reset to original price with change of product opw-4813069 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When users generate an electronic invoice XML through the Send & Print wizard for download only, Odoo now creates the related document record as expected. This keeps accounting documents complete even when the invoice attachment is not sent by email.
Original PR description
Event with the document integration correctly setup, e-invoice xml generated in the send&print wizard will not create an associated document unless the attachment is actually sent via mail Steps to reproduce: - Have a EU Company setup - Enable and configure Peppol Electronic Invoicing - Enable documents integration with accounting - Create an invoice to a Peppol enabled customer, confirm - Open send&print wizard, enable only 'Download' and 'BIS Billing 3.0' Issue: Document related to the xml attachment is not created. This will work as expected when the message is sent to the customer opw-4720588 Enterprise PR https://github.com/odoo/enterprise/pull/88746 Forward-Port-Of: odoo/odoo#216243
This fix prevents an error when users view reserved packaging quantities for kit products that do not have packaging set. Inventory reporting can now display these reserved quantities reliably instead of failing with a crash.
Original PR description
### Steps to reproduce: - In the settings enable "Product Packagings" - Create a product P with a kit bom: 1 x COMP - Create and confirm a delivery for 1 unit of P - Reserve 1 unit of COMP (put the…
### Steps to reproduce: - In the settings enable "Product Packagings" - Create a product P with a kit bom: 1 x COMP - Create and confirm a delivery for 1 unit of P - Reserve 1 unit of COMP (put the quantity of the move to 1) - Go to Inventory > Reporting > Moves history - Add the field "Reserved Packaging Quantity" in the view (with studio) - remove the "done" filter #### > Traceback: ZeroDivisionError in _compute_product_packaging_qty ### Cause of the issue: The computation of the `product_packaging_qty` can not succeed for a kit move line without `packaging_id` on its move since: `move_line.move_id.product_packaging_id.qty` will be 0: https://github.com/odoo/odoo/blob/b87c896969cc576a799ac63f03501be1e87b0e84/addons/mrp/models/stock_move.py#L107 By contrast since if the packaging is set, there should not be an issue since the field is required and since there is a positive constraint: https://github.com/odoo/odoo/blob/b87c896969cc576a799ac63f03501be1e87b0e84/addons/product/models/product_packaging.py#L21-L27 opw-4781180 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#217877
The media attachment remove icon is now shown correctly in the editor dialog. This fixes a small visual issue that could make it harder for users to remove selected media attachments.
Original PR description
Description of the issue this PR addresses: - The remove icon in the media dialog attachment was not visible due to the use of an invalid `z-index-1` class. This commit c5a98c76ea1cce4acb55faf4768388b94255508f removed custom `z-index` utilities. Replaces `z-index-1` with Bootstrap's default `z-1` class. Before this commit: - The icon used `z-index-1`, which is not a valid Bootstrap class. After this commit: - Replaced with `z-1`, the correct Bootstrap 5 utility class for `z-index: 1`. task-4903381 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix makes an internal mail presence test stable when automated test systems are under heavy load. It reduces false test failures, helping keep releases and updates moving reliably without changing user-facing behavior.
Original PR description
Since [1], https://github.com/odoo/odoo/pull/207974 websocket timeout has been increased during test. Fetching notification only returns the notifications of the last 50 seconds initially. When runbot is under high load, this can lead to non deterministic failures. This commit patches the cursor date to bypass this issue. [1]: https://github.com/odoo/odoo/pull/207974 fixes rubot-223758 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an error that could stop users from creating reordering rules for products with variants in Inventory. Businesses can now set replenishment rules for variant products without hitting a rounding-related crash.
Original PR description
The system encounters an error when attempting to `create` a `reordering rule` for products that have `variants`. **Steps to Reproduce:-** 1. Install the `Inventory` module. 2. Navigate to the…
The system encounters an error when attempting to `create` a `reordering rule` for products that have `variants`. **Steps to Reproduce:-** 1. Install the `Inventory` module. 2. Navigate to the `Products` section and create a product with variants (Make sure the `variants` option is `enabled` in the `settings`). 3. Click on `Reordering Rules` for that product and attempt to`create a new rule`. **Error:-** `AssertionError: precision_rounding must be positive, got 0.0` **Root Cause:-** - When trying to create the reordering rule for a product with variants, the `rounding` value comes as `0.0` at [1]. This occurs because there are `no products` in the `order point`, and consequently, there is `no unit of measure (UoM)` associated with it. [1] https://github.com/odoo/odoo/blob/970bd0e13319b2363c3ec186983faae2713ef5ef/addons/stock/models/stock_orderpoint.py#L343 **Solution:-** - In this commit, set the `rounding` value to `0.01` by default when the value is 0.0. This adjustment will ensure that all float comparisons using that UoM function will work correctly. **Sentry-6731259843** I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Phone numbers entered with parentheses are now handled correctly by the VoIP feature. This helps avoid dialing issues when users copy or type numbers in common formats such as area codes in brackets.
Original PR description
Add parentheses to the list of characters that are stripped from phone numbers. Part of task-4891947. Forward-Port-Of: odoo/enterprise#89625 Forward-Port-Of: odoo/enterprise#89551
Electronic invoice XML files created from the send and print flow now create the expected document record even when the user only downloads them instead of emailing them. This keeps accounting documents complete and easier to find for companies using Peppol and Documents integration.
Original PR description
Event with the document integration correctly setup, e-invoice xml generated in the send&print wizard will not create an associated document unless the attachment is actually sent via mail Steps to reproduce: - Have a EU Company setup - Enable and configure Peppol Electronic Invoicing - Enable documents integration with accounting - Create an invoice to a Peppol enabled customer, confirm - Open send&print wizard, enable only 'Download' and 'BIS Billing 3.0' Issue: Document related to the xml attachment is not created. This will work as expected when the message is sent to the customer It occurs because, in case of xml attachment, we don't create an associated document until some attachment have been registered on the move, effectively delaying document creation until the mail attachments are created opw-4720588 Forward-Port-Of: odoo/enterprise#88746
Italian POS fiscal receipts and invoices no longer add a manual header because the fiscal printer already prints one automatically. This prevents customers from receiving receipts with duplicated header information, making printed documents cleaner and compliant with printer behavior.
Original PR description
The printer is already adding a header by default so we don't need to add one manually. Steps to reproduce: ------------------- * Setup an Italian fiscal printer in the POS * Open the POS and create a new order * Add a product and validate the order > Observation: The printed receipt has 2 headers. Why the fix: ------------ According to the Italian fiscal printer documentation, the header is automatically added by the printer, so we don't need to add it manually. Ticket before and after the fix:  opw-4794322
The empty screen image in Subscriptions now scales with its surrounding space instead of using a fixed size. This makes the image larger and easier to see, improving the first-use experience for users who have no subscription records yet.
Original PR description
Changed the empty screen image size from a fixed value to a dynamic ratio based on its parent element. The image is now larger and clearer for the user. task-4912109