Daily updates from Odoo
Navigate
Branch
Friday, July 25, 2025
80 changes
39 changes
New functionality added to Odoo
Adds the missing Oman tax return setup so companies using the Oman localization can access tax closing forms from the Tax Report. This makes the Returns button visible and lets Oman users generate the required tax closing form.
Original PR description
#### Issue: This commit adds a missing account.return.type data in the Oman localization. This is related to the new Accounting Returns #81569 The l10n_om module did not include an…
#### Issue: This commit adds a missing account.return.type data in the Oman localization. This is related to the new Accounting Returns #81569 The l10n_om module did not include an account.return.type record, which prevents the "Returns" button (linked to the action_open_returns) from appearing in the Tax Report. As a result, users in Oman are unable to access the Tax Closing form. Also the l10n_om is a community module, because of that, we need to add a new enterprise module to add the related data for the tax returns. The visibility of the button is controlled by the following condition: [Code](https://github.com/odoo/enterprise/blob/f924f120cbd04002e21c78b081e1c8006b56a4b6/account_reports/models/account_report.py#L1776) #### Affected Versions: 18.3 and later #### Steps to reproduce: 1.Install the l10n_om module 2.Switch to the Oman company 3.Go to Accounting > Reporting > Tax Report 4.The "Returns" button is not visible #### Expected behavior The "Returns" button should be visible, allowing the user to generate the closing tax form. #### Current behavior The button is hidden due to missing account.return.type data in the Oman localization. OPW-4943024 Forward-Port-Of: odoo/enterprise#90814
Enhancements to existing features
Point of Sale no longer repeatedly checks the database to confirm whether IoT-connected devices are still online. This reduces unnecessary database activity and can improve efficiency for stores using IoT Box peripherals such as scales or other hardware.
Original PR description
In order to reduce the amount of search reads from the pos to the database we removed the status loop running to check if devices are still connected to the IoT Box. Forward-Port-Of: odoo/enterprise#90638
The food delivery configuration fields no longer allow users to quickly create new configuration entries from the product setup screens. This keeps setup more controlled and prevents accidental or unnecessary configuration records.
Original PR description
*= pos_urban_piper_enhancements -------------------------------------------------- In this commit, Removed the quick create option for the `Available on food delivery` field as we don't require the config creation from this field. task: 4951290
UrbanPiper order handling now records clearer logs for more webhook checks, validation problems, and API outcomes. This improves traceability for support teams, making it easier to diagnose integration issues and confirm successful requests.
Original PR description
Before this commit:
====================
- Logging was done using hardcoded names.
- Logging was done only for the webhook and API failure scenarios.
- API success requests/responses were not logged.
After this commit:
====================
- Added dynamic name parameter to `log_xml` calls.
- Added log for the below scenarios:
- Validation of `X-Urbanpiper-Uuid`, missing store, session, charge product,
and delivery provider in webhook flow.
- Payload validation errors.
- API call responses and all exception types:
(`ConnectionError`, `HTTPError`, `JSONDecodeError`).
Task: 4909050The AI discussion tools were adjusted to stay compatible with a related platform change that removes direct message author data. This helps keep AI actions in conversations working reliably after the underlying messaging update.
Original PR description
PR community: https://github.com/odoo/odoo/pull/219890
The AI features in Discuss were updated to use the latest way of reading a member's availability status. This keeps AI-related chat actions aligned with the main platform changes and helps prevent inconsistencies after the underlying status logic changed.
Original PR description
This commit adapts the code to the new member.im_status getter. PR community: https://github.com/odoo/odoo/pull/220066
WhatsApp discussion channels now send only the information relevant to each channel type. This reduces unnecessary network data and helps keep related checks simpler and easier to maintain.
Original PR description
This commit updates the `_to_store_defaults` of the discuss channel model only to return data that makes sense according to the channel type. This will reduce the payload size on the network but also clean the many tests that list useless fields. task-4883062 community: https://github.com/odoo/odoo/pull/220095
The Indian GSTR-1 report now uses updated selection rules and a dedicated handler to classify transactions more accurately. This helps businesses prepare GST reports with more reliable figures and better alignment across related Indian tax reporting flows.
Original PR description
In this PR, update the domain in GSTR-1 Report which was using reverse charge field and added a custom handler. Community PR: https://github.com/odoo/odoo/pull/112877 Upgrade PR: https://github.com/odoo/upgrade/pull/4344 Task - 3110483
Austrian companies can now manage EC Sales List and Intrastat reporting with country-specific deadlines and filing periods in Odoo. This helps businesses stay aligned with Austrian reporting obligations and reduces manual tracking for compliance teams.
Original PR description
Following the implementation of the Tax returns feature in 18.3 which was focused on the general implementation and Belgium, we want to add the specification for other country and in this case Austria. Adding EC sales list, Intrastat specific deadlines and periodicities. task-4963439
Global invoices in Mexico now automatically correct small one-cent rounding differences that can occur when combining individual invoices or POS sales. This helps ensure CFDI submissions match accounting totals and avoids inaccuracies when invoices are issued or canceled.
Original PR description
When creating global invoices in Mexico, small rounding discrepancies of up to 1 cent arise due to pre-rounded sums of individual invoices. This leads to discrepancies between the global invoice total and the sum of its individual journal entry lines, causing inaccuracies in the global invoice submission for CFDI,for invoices or POS transactions. This commit introduces a corrective miscellaneous entry to offset these discrepancies: - Calculates the rounding difference between the aggregated invoice amounts and the global invoice total. - Applies the correction to the most used product and tax accounts. - Stores this adjustment entry on l10n_mx_edi.document, allowing it to be reversed if the global invoice is canceled. - Handles both standard invoices and POS orders task-4256227
User selection fields now rely on the standard creation flow instead of showing redundant quick-create options. This reduces confusion because creating a user still requires an email, so the streamlined flow leads users to the same complete setup screen when needed.
Original PR description
- Since an email is mandatory when creating a user, the `quick_create` option automatically falls back to `create_and_edit`. As a result, from the user's perspective, both `quick_create` and `create_and_edit` effectively serve the same purpose. - This PR removes both of the options from wherever we have used them with the Many2xAvatarUser widget. Task-4613146
Payroll access has been adjusted so users without payroll rights no longer see the Payroll app, payroll officers see employee payroll information, and payroll administrators can manage payroll configuration. This clarifies who can view or configure payroll features after recent changes, including Swiss payroll employee views.
Original PR description
Payroll No right : You don't see payroll app Officer : Employee officer + payroll tab Admin : Employee admin + payroll app config. Task: 4900703 Forward-Port-Of: odoo/enterprise#90230
Point of Sale testing tools were improved so teams can more easily validate store services, model data, and standalone components. This helps reduce regressions in PoS-related features across appointment, IoT, restaurant, payment, and delivery integrations, with no direct change expected for end users.
Original PR description
Improved test hoots in PoS to test model and service functions. It is now possible to access the `pos_store` via `getService(“pos”)`. This will automatically load mocked data and information on the various models. Components can also be mounted independently of the rest of the application, so that their functions can be tested. For the moment, only `point_of_sale` models are loaded, but the implementation is designed to be patched from other PoS modules. Forward-Port-Of: odoo/enterprise#90339 Forward-Port-Of: odoo/enterprise#90234
Resolved issues and error corrections
The point of sale customer display now opens more reliably even when the IoT Box cannot be reached. This prevents error screens during checkout and keeps the customer-facing display available by using an alternate connection method when needed.
Original PR description
We fixed the customer display not opening and displaying a traceback when the Iot Box was not reachable, by calling the action via iot_http, fallbacking on websocket when needed. We also removed the "customer display with IoT Box" logic from the PoS to the module pos_iot. Community PR: odoo/odoo#219917 Forward-Port-Of: odoo/enterprise#90657
This update adjusts an automated test for Mexican point-of-sale invoicing so it no longer fails because of an irrelevant generated identifier. It helps keep validation reliable without changing any customer-facing invoicing behavior.
Original PR description
Fix the test file for pos order then invoice request to match the expected XML structure, by ignoring the `UUID` attribute in the `TimbreFiscalDigital` element because it is not relevant for the test and can cause issues with the test validation. build_error https://runbot.odoo.com/runbot/build/83409879 Forward-Port-Of: odoo/enterprise#88756
This fixes an error that could prevent employees from clocking out in restaurants using the Belgian blackbox POS setup. The POS now receives the required employee identification data during synchronization, so clock-in and clock-out actions work reliably.
Original PR description
How to reproduce: - Set up a restaurant with a Belgian blackbox - Create employees - Enable the POS setting "Log in with Employees" - Open the POS configuration - Select an employee - Click "Clock Out" - The following error is displayed:TypeError: Cannot read properties of undefined The required employee '_insz_or_bis_number' data was not properly transferred to the POS during incoming synchronization, causing undefined references when performing clock-in/clock-out actions.
Ecuador electronic invoice processing now handles empty or incomplete responses from the tax authority without crashing. This helps users continue processing invoices more reliably when the external service returns unexpected data.
Original PR description
The system will crash when we receive nothing in `response` and also tryig to retrieve values from response. **Error:-** `TypeError: 'NoneType' object is not subscriptable` **Root Cause:-** - While…
The system will crash when we receive nothing in `response` and also tryig to retrieve values from response. **Error:-** `TypeError: 'NoneType' object is not subscriptable` **Root Cause:-** - While we are in `EC Company`. - When we click `Process Now` on the invoice. It will call `button_process_edi_web_services` method. And while in execution when at [1], `move.company_id._l10n_ec_is_demo_environment()` is `False`, then it calls `_l10n_ec_send_document` method. - While submitting electronic invoices to SRI, the method `_l10n_ec_get_client_service_response_new()` sometimes returns `None` . - It may also lack expected keys like 'estado' or 'comprobantes', depending on SRI’s behavior. [1] https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_ec_edi/models/account_edi_format.py#L425-L428 **Solution:-** - Wrapped the access to response and its keys inside a `try...except` block that catches:- - `TypeError`: for cases where the response is `None`. **Sentry - 6708486009, 6728767866** Forward-Port-Of: odoo/enterprise#88611
Belgian point-of-sale receipts are adjusted to meet blackbox certification requirements after recent receipt layout changes. Receipts now more clearly show whether a ticket is valid and whether it is a refund, while removing duplicated date and address details.
Original PR description
Since this revmap of the POS receipt (https://github.com/odoo/odoo/pull/201105), we have to make some changes on the receipt when using `pos_blackbox_be`: - Display if the ticket is valid or not (Pro Format) & increase its size. - Display if the order was a refund or not. - No need to display the `blackbox_date` since we now have the `date_order` inside `/point_of_sale/static/src/app/screens/receipt_screen/receipt/receipt_header/receipt_header.xml``. - No need to display the `order.company.street` since the whole adress is now displayed inside `/point_of_sale/static/src/app/screens/receipt_screen/receipt/order_receipt.xml`. task-id: 4848882 community PR: https://github.com/odoo/odoo/pull/214394 Forward-Port-Of: odoo/enterprise#90180 Forward-Port-Of: odoo/enterprise#87759
This fixes a display issue on the shop page where products sold by subscription could show the same price twice. Customers now see a clearer, more professional product listing, reducing confusion during browsing and purchase decisions.
Original PR description
This PR fixes an issue where the product price was displayed twice on the `/shop` page of a product with a subscription type. task-4954676 Issue: <img width="618" height="271" alt="image" src="https://github.com/user-attachments/assets/e00adabf-ecfb-4424-8c2a-3b7413cbeee3" /> Forward-Port-Of: odoo/enterprise#90924
This update fixes issues that could prevent Gemini-based AI features from working correctly and improves how attachments are processed for AI use. It also prevents AI search data from different models being mixed, making results more reliable for users.
Original PR description
- Use correct gemini model names (gemini-2.5-flash instead of just gemini) - Fix google API endpoint to use openAI-compatible path (/v1beta/openai) - Introduce embedding_model field in ai.embedding to prevent cross-model mixing - Fix attachment processing percentage calculation to count unprocessed embeddings - Add proper provider detection and embedding model mapping - Handle None responses from embedding API gracefully - Fix AI agent duplication with proper name suffix - Add comprehensive gemini integration tests - Update settings UI labels for clarity Task-ID: 4778862
Fixes an error that could stop users from reconfirming a loan after cancellation when Accounting Audit Trail is enabled. This ensures loan workflows remain usable even when past accounting entries must be preserved for compliance.
Original PR description
Steps: - Activate Audit Trail in Accounting configuration - Create and confirm a loan, having some moves posted in the past - Cancel it, reset it to draft the re-confirm it again -> ValueError: Expected singleton This is because posted moves can not be unlinked when canceling/closing the loan if audit trail is activated. Therefore we try to access the `state` field from a recordset instead of a singleton. With this commit, we filter the generated move to get the newly created one. opw-4834361 Forward-Port-Of: odoo/enterprise#90578 Forward-Port-Of: odoo/enterprise#88286
The Luxembourg payroll settings now reflect the latest accident insurance bonus-malus factors required by local regulations. This helps companies use the correct payroll configuration and avoid relying on an outdated 0.9 factor.
Original PR description
**Problem**: =========== Bonus-Malus Factor l10n_lu_accident_insurance_factor, the value 0.9 is no longer used according to an update in Luxembourg regulations. Found the legal documentation from Luxembourg's social security institutions page: https://www.secu.lu/assurance-accidents/reglements/ **To Reproduce**: ================== -> install l10n_lu_hr_payroll -> switch to Luxembourg company -> settings -> filter with Bonus-Malus Factor **Solution**: ============== Update Bonus-Malus Factor https://github.com/odoo/upgrade/pull/8088 opw-4818034
Fixes formatting issues when inserting fields and records into AI prompts, making them easier to delete and edit. It also reduces unnecessary prompt update calls when the content has not changed.
Original PR description
Purpose: -------- Currently records and fields inserted in AI prompts are badly formatted, making it sometimes impossible to delete an inserted field or to place the cursor after a field or a record. This commit fixes their format: For standalone fields, we do not insert divs inside a span anymore For grouped fields, the container is now a div instead of a t (which was set as inlined by the qweb plugin while the group shouldn't) For records, the container is now a span instead of a div, since we want the records to be inlined. Also, ai prompt widget now only calls onChange when the prompt content changed (to not make useless calls to it) Task-4780975 Forward-Port-Of: odoo/enterprise#90774
This fix prevents an error when users or integrations access signing requests that are not in the shared state. Non-shared requests now safely show no sharing link instead of triggering a traceback, improving reliability for administrators and connected systems.
Original PR description
### Issue Commit [58425a0](https://github.com/odoo/enterprise/commit/58425a0022c79f2c45f23fdd5a5476d8c20a887e) introduced a new field `share_link` in `sign.request` that gets computed for requests…
### Issue Commit [58425a0](https://github.com/odoo/enterprise/commit/58425a0022c79f2c45f23fdd5a5476d8c20a887e) introduced a new field `share_link` in `sign.request` that gets computed for requests that are in the 'shared' state. However this compute method fails for requests not in the 'shared' state leading to a traceback error. This commit fixes it by setting the default as False for the sign.request records that do not have state='shared' so the traceback error is handled. This can be reproduced in v17 and above by: 1. Open any sign.request record that isn't in the shared state 2. Enable Developer Mode 3. Using the debug icon, click on view record data The traceback will be visible here which mentions that the compute method failed to assign It can also be re-produced by using an xml-rpc / json-rpc ORM call to search_read the sign.request records that does not have state = 'shared' ### Before https://github.com/user-attachments/assets/24c07f2a-2398-44b4-8969-30abb576876a ### After https://github.com/user-attachments/assets/e92b1212-5405-4b98-ba41-c81b2ac547d7 [opw-4864159](https://www.odoo.com/odoo/project/49/tasks/4864159) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#90576
Fixed an issue in the Gantt schedule where clicking Today after choosing a one-day custom range could create an invalid date range. This ensures navigation arrows continue to work correctly for resource bookings and similar planning views.
Original PR description
Steps to reproduce ================== - Go to Appointments > Schedule > Resources Bookings - Select a custom range with the same start date and stop date - Click apply - Click on Today - Use the next arrow => Nothing changes Cause of the issue ================== If there is 0 day between the start and stop dates, clicking on today will have the stop date before the start date. opw-4754203 Forward-Port-Of: odoo/enterprise#88919
This fixes issues in the salary package configurator and offer signing flow that could save employee details on the wrong record or select an archived contract version. It improves reliability when HR teams generate, sign, and countersign offers, especially for Belgian salary configuration data.
Original PR description
Forward-Port-Of: odoo/enterprise#90307
Worksheet fields on the customer portal now respect visibility rules configured in worksheet templates. This helps customers see only the relevant fields and keeps worksheet layouts clearer when answers or conditions change.
Original PR description
When the user configures the field in the worksheet template to be visible based on a
condition, but it is not applied in the portal because the 'invisible' attribute is not
working. We have used 't-if'.
Technical:
1) Due to dynamic row visibility, the server-side cannot determine if the row is odd or even,
so I have implemented it in SCSS.
2) When the value of the field changes, `_add_field_node_to_container()` method is not triggered. Hence, we cannot
evaluate the domain.
task-3686737Fixed an issue where confirming an upsell with a non-recurring product could incorrectly increase the quantity on the original subscription. This prevents subscription records from being changed by unrelated products, helping keep customer billing and subscription quantities accurate.
Original PR description
**Steps to reproduce:** - Install `sale_subscription` - Create a recurring product (P1) and a non-recurring product (P2) - Create a Sale Order (S1) with P1 (quantity > 0) and confirm it - Create an…
**Steps to reproduce:** - Install `sale_subscription` - Create a recurring product (P1) and a non-recurring product (P2) - Create a Sale Order (S1) with P1 (quantity > 0) and confirm it - Create an upsell of S1 (new child order S2) - In S2, edit the P1 line, and select P2 - Set quantity > 0 for P2 - Confirm S2 **Issue:** After confirming the upsell order (S2), the quantity of P1 on the original subscription (S1) is incorrectly increased by the quantity of P2 from S2. The _compute_parent_line_id method did not reset the parent_line_id when the product was not a subscription Product, which caused it to incorrectly update the subscription This issue is present in all three versions: **16.0, 17.0, and 18.0**. **Solution:** Reset parent_line_id to False if the product is not a subscription product to prevent incorrect subscription updates. [opw-4638955](https://www.odoo.com/odoo/project.task/project.task/4638955) Forward-Port-Of: odoo/enterprise#90871 Forward-Port-Of: odoo/enterprise#88282
This change moves Point of Sale configuration tests into the Enterprise POS module where the related functionality belongs. It helps keep automated checks aligned with the correct product area, reducing build issues and improving release reliability without changing user-facing behavior.
Original PR description
move tests for POS configuration settings from point_of_sale to pos_enterprise refer to this commit :https://github.com/odoo/odoo/pull/215611/commits/0074d743451834424706608fc76f32b0df9c5f1c build_error-227602 Forward-Port-Of: odoo/enterprise#89351 Forward-Port-Of: odoo/enterprise#88742
Brazilian POS orders with a zero total now still send the required payment information to Avalara. This prevents invoice submission errors for free or fully discounted sales, helping affected businesses complete compliant electronic receipts without manual intervention.
Original PR description
Right now, for 0 cost POS orders no `paymentMode` section is sent to Avalara, which leads to an error from them when trying to submit the invoice: Code 899: incorrectly entered payment method field The proper fix is to always send `paymentMode` with a value of 0.00 and mode of `Other`. (Note that there is a payment mode that corresponds to no payment, 90, but it only available for NF-e not NFC-e so we use 99) opw-4874094 Forward-Port-Of: odoo/enterprise#90960 Forward-Port-Of: odoo/enterprise#90724
The Partner Commission module can now be installed even if the default Services product category was deleted. This prevents an installation failure and lets businesses continue setting up commissions without needing to restore that category first.
Original PR description
Currently, a ParseError is arising when the user installs the `partner_commission` module after deleting the `Services` in Product Categories/Configuration. Steps to reproduce: --- - Install…
Currently, a ParseError is arising when the user installs the `partner_commission` module after deleting the `Services` in Product Categories/Configuration.
Steps to reproduce:
---
- Install `Invoicing` application (without demo data).
- Invoicing > Configuration > Product Categories > Delete `Services`
- Now install `partner_commission` module
Traceback:
---
```py
ValueError: External ID not found in the system: product.product_category_services
ParseError: while parsing /home/odoo/src/enterprise/saas-18.4/partner_commission/data/data.xml:3, somewhere inside <record id="product_commission" model="product.product">
<field name="name">Commission</field>
<field name="purchase_ok" eval="True"/>
<field name="categ_id" ref="product.product_category_services"/>
<field name="type">service</field>
</record>
```
The error occurs because the user deleted `Services` in Product Categories, and then tried to install the other module.
This commit resolves the error by providing a False value for the field if the product category is missing.
sentry-6754387015
Forward-Port-Of: odoo/enterprise#90598The Belgian certified POS setup now shows the correct required cash rounding value in its validation message. This helps users configure Belgian Blackbox POS settings accurately and avoids confusion during setup.
Original PR description
The message `"The rounding method must be set to 0.5 and HALF-UP"` was wrong in `pos_blackbox_be/models/pos_config.py`
```py
def _check_cash_rounding(self):
if not self.cash_rounding:
raise ValidationError(_("Cash rounding must be enabled"))
if (
self.rounding_method.rounding != 0.05
or self.rounding_method.rounding_method != "HALF-UP"
):
raise ValidationError(
_("The rounding method must be set to 0.05 and HALF-UP")
)
```
It should be `"The rounding method must be set to 0.05 and HALF-UP"` as indicated in that documentation :
https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/belgium.html?highlight=blackbox#certified-pos-system
It's the same for 18.0
I also added the field for translation into `pos_blackbox_be.pot`
opw-4862967
Forward-Port-Of: odoo/enterprise#90321
Forward-Port-Of: odoo/enterprise#87496Chilean factoring AEC files now always report the total amount in Chilean pesos, even when the original invoice uses another currency. This prevents incorrect values in regulatory export files and helps ensure submissions match local requirements.
Original PR description
In this bug, when a currency other than CLP is selected in invoicing, the generated aec has MntTotal tag with the rate of selected currency, while it must always be in CLP. To reproduce the bug: 1- Create a database with invoice app and a Chilean company 2- Create an invoice with document type of 34 3- Choose a different currency than CLP 3- Click on Send Now to SII and Create AEC 4- Click on Yield Entry smart button 5- Download generated AEC xml file 6- You can see the value of MntTotal is in selected currency which is wrong related: https://github.com/odoo/enterprise/commit/4e97c5d008c2879c5d014203fafc2c125d6c5ae7 opw-4830957 Forward-Port-Of: odoo/enterprise#90858 Forward-Port-Of: odoo/enterprise#90232
This update makes automated checks for the report editor more dependable by waiting more reliably for scrolling to finish. It reduces occasional false test failures, helping development and release validation run more smoothly without changing user-facing behavior.
Original PR description
Linked tests: - `test_add_field_blank_report` - `test_field_placeholder` These tests contained scroll-related indeterminacies that caused them to fail from time to time. This was due to the fact that we were modifying the scroll and we used this code to make sure it was done: ```js await new Promise(requestAnimationFrame); ``` However, sometimes this wasn't enough, so we now use `waitUntil`, which is more robust https://runbot.odoo.com/odoo/runbot.build.error/181989 runbot-181989 Forward-Port-Of: odoo/enterprise#90806
Fixed how Helpdesk tickets created from the website contact form handle the description field. The field is now hidden when it would be the only extra field, and its label uses the visitor's selected language when shown.
Original PR description
## Short functional explanation of the issue When a ticket is created and there are no additional fields, the only field in the ticket is the description field. Moreover, it is not translated. ##…
## Short functional explanation of the issue When a ticket is created and there are no additional fields, the only field in the ticket is the description field. Moreover, it is not translated. ## Reproduction Steps 1. Go to the general settings. Add a language where the term "description" differs from the english word (for example, Spanish). Do the same for the website settings. 2. Go to the website app. Scroll down and change the language. Then, click on the translated "contact us" tab. Fill the form and send the ticket. 3. Go to the helpdesk app and open the ticket you just created. ### Expected behavior The description field shouldn't show, as it appears in the description page. The field should only show if there are additional fields on the "contact us" page. ### Unexpected behavior The description field shows, untranslated. ## Origin of the issue In the ticket code, the field.name is used, instead of the field .field_description, which is translatable. Moreover, there isn't a condition checking if the field should appear or not. -- opw-4876726 Forward-Port-Of: odoo/enterprise#88913
When users generate an electronic invoice XML from the send and print flow and choose to download it instead of emailing it, Odoo now creates the matching Documents entry. This keeps accounting documents complete and consistent regardless of whether the invoice attachment is sent by email or only downloaded.
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#90475 Forward-Port-Of: odoo/enterprise#88746
Belgian Intrastat XML exports now follow the same 'Hide lines at 0' option shown on the report screen. This prevents zero-cost transactions from being included in official XML exports, reducing reporting errors and manual cleanup for accounting teams.
Original PR description
_______________________________________ ## Short functional explanation of the error On the export intrastat report page, we can click on the 'Posted Entries' button, which allows us to select 'Hide…
_______________________________________ ## Short functional explanation of the error On the export intrastat report page, we can click on the 'Posted Entries' button, which allows us to select 'Hide lines at 0'. Doing this will prevent 0 cost transactions from appearing in the report. However, when exporting to XML, such transactions are still displayed. Note: this is related to Belgian companies only. ## Reproduction Steps 1. Go to settings and make sure the company you're operating with is Belgian. Then, in accounting, under the Custmer Invoices section, check the 'Intrastat' option. 2. Go to products and create a new product of type 'Goods'. Then, in the 'Accounting' tab, click on a random commodity code. Set the country of origin as a country belonging to the European Union (for example, Austria). Click on save. You should see a field named 'Intrastat Supplementary Unit Amount' appear. 3. Go to accounting. Click on the 'Vendors' tab and 'Bills'. Click on New. Select a random vendor, and add a line containing the product you just created. Add the column 'Intrastat' and set the corresponding field at '11 outright...'. Then, set a price. In the 'Other Info' tab, set the field 'Intrastat Country' as a random country in the European Union (for example, Australia). Set the fiscal position at 'Import/Export' and set the 'Intrastat Transport Mode' field at '1. Sea transport'. Finally, click on confirm. 4. Duplicate the vendor bill you just created. On this new vendor bill, set the Intrastat at '12 Direct trade...'. Display the column 'Disc.%' and set the field at 100. Then click confirm. 5. Click on the 'Reporting' tab, and under 'Audit Reports', click on 'Intrastat Report'. Set the month to the current month, then click on 'Report: Intrastat(Services....)' and select 'Intrastat (Goods)'. You should be able to see the 2 vendor bills you just created. Click on 'Options' then 'Hide lines at 0': you should see the bill having a 0 cost disappear. Finally, click on the cog on the top left next to 'Intrastat Report' and click on 'XML'. 6. Once the XML file has finished downloading, open it. ### Expected behavior The transaction having a 0 cost shouldn't appear. ### Unexpected behavior The transaction having a 0 cost appears. ## Origin of the issue In the code responsible for the display of the XML report, there isn't any condition responsible for checking if the transaction should be displayed or not. _________________________________________ opw-4464123 --- Forward-Port-Of: odoo/enterprise#90193 Forward-Port-Of: odoo/enterprise#89285
Features or functions removed from Odoo
The Documents app no longer shows sample records in empty views because the behavior was inconsistent and could confuse users during uploads. Users will instead rely on the standard empty-content helper for a clearer experience.
Original PR description
Support for this feature was only partial as when we switched folder then came back to an empty one, sample data was not rendered anymore. The records are also rendered not muted during uploads, which confuses users, and it's also tricky to avoid. All things considered, we're removing support for the sample records in Documents as it requires custom code and is not really useful with the no-content helper. Task-4788941
Code cleanup and technical improvements
The helpdesk website knowledge base search was reorganized behind the scenes to use a newer interaction structure. This should preserve the existing customer experience while making the feature easier to maintain and improve in future updates.
41 changes
New functionality added to Odoo
Odoo can now use systemd socket activation with its prefork server mode, matching support already available in threaded mode. This gives operations teams more flexibility and consistency when deploying or managing Odoo services.
Original PR description
This commit brings the prefork model to feature parity with the threaded model, allowing systemd socket activation to be used in both cases.
This update adds automated checks to ensure mail alias domain behavior is covered in the enterprise test suite. It helps reduce the risk of regressions in email alias handling without changing customer-facing functionality.
Original PR description
add test for this see https://github.com/odoo/odoo/pull/219223
Enhancements to existing features
Sales orders with many lines now load available product documents much faster. This reduces waiting time when opening large quotes by replacing repeated lookups with a more efficient grouped lookup.
Original PR description
Replace search in for loop with `_read_group` and a precomputed dictionary of available product documents Description of the issue/feature this PR addresses: Performance issue when opening SO with multiple lines (more than 100). See Speedscope before [speedscope_before.json](https://github.com/user-attachments/files/21251034/speedscope_before.json) <img width="1920" height="659" alt="image" src="https://github.com/user-attachments/assets/e77bec12-e8cf-4cc9-b3d2-90ad59db6fa3" /> And after: [speedscope_after.json](https://github.com/user-attachments/files/21251096/speedscope_after.json) <img width="1911" height="404" alt="image" src="https://github.com/user-attachments/assets/e1663ec3-2918-451d-ae25-6103d8a75eff" /> We went from 252ms for the query only to 12.63ms. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now choose whether to generate a Factura-e file directly from the Send & Print step for Spanish partners. This makes invoice sending clearer, reduces setup mistakes, and keeps the partner’s e-invoicing preference aligned with the user’s choice.
Original PR description
Currently, `Factura-e` generation is controlled only by an partner E-invoice format setting, making it difficult for users to enable or disable when sending invoices. This PR adds a dedicated Factura-e checkbox on the `Send & Print` wizard for partners in Spain if the `l10n_es_edi_facturae` module is installed. The checkbox defaults to the partner’s current `E-invoice format` but can be toggled by the user. When enabled, it triggers Factura-e file generation and updates the partner’s E-invoice format to ensure consistency. This approach simplifies the user flow and reduces configuration errors. > Task-4831835
Odoo now supports a special Peppol registration option that keeps trial and training databases fully local, avoiding real Peppol network calls. Scheduled background actions were also adjusted to run under the correct company, improving reliability in multi-company setups.
Original PR description
When the company is registered with this particular EAS, Odoo will act as if it was in demo mode. No call to the real Peppol Network is performed, everything is mocked locally. This allows to do the trainings on /trial databases, and get the lastests improvements. Also fixing some crons that needed to be run with the right company. task-no (FP/WTA request)
Companies in French overseas territories can now activate Peppol when the accounting module is installed. The system can also automatically choose the right Peppol identifier from existing business IDs, reducing manual setup effort.
Original PR description
Purpose ------- Add the DOM-TOM to the list of countries allowed to activate Peppol when the module is installed. Changes ------- - Updated `PEPPOL_LIST` to include the following country codes: 'MF', 'MQ', 'NC', 'PF', 'RE', 'GF', 'GP', 'TF', 'BL', 'PM', 'YT', 'WF' - Updated EAS_MAPPING so that the Peppol ID and endpoint can be automatically set based on either the SIRET, SIRENE, or VAT number, as in the French implementation. Task-4889705
The Turkish Profit and Loss report now includes 700-series accounts, which are used during an accounting period before closing entries are made. This makes the report more useful for local businesses and accountants by enabling more accurate real-time financial reporting.
Original PR description
The current Profit and Loss report has some limitations that inhibit its proper adoption as it does not enable the user to use the report in real-time since it excludes the 700 accounts (accounts used within a period until their closing to 600 accounts.) Therefore, this limits the usefulness of the report for local businesses and accountants. In this task, we included the 700 accounts in the report to enable real-time reporting for our users task-4809142
Businesses using the Türkiye accounting reports can now export the General Ledger in the CSV format required for e-Ledger reporting. The file is automatically packaged in a ZIP archive, helping companies meet Türkiye Revenue Administration delivery requirements for any selected reporting period.
Original PR description
This PR implements the necessary functionality for Türkiye’s e-Ledger reporting, as mandated by Türkiye law (Law No: 15570). Taxpayers that switched to e-Invoice/e-Archive are also required to submit their General Ledger (GL) in the e-Ledger format. Summary of the change This update enhances the existing Türkiye General Ledger report in the `l10n_tr_reports` module with the following features: - Adds the ability for users to generate the General Ledger as a CSV file, formatted according to the Türkiye e-Ledger requirements. - Allows export for any selected period, including relevant and filtered fields. - The generated CSV file is automatically compressed into a ZIP archive to comply with the GIB (Türkiye Revenue Administration) guidelines for file delivery. Task-4270136 Forward-Port-Of: odoo/enterprise#86592
Resolved issues and error corrections
The HTML editor color picker now shows background color opacity changes immediately in the preview. This helps users see the final appearance while editing content, reducing confusion and trial-and-error.
Original PR description
### Steps to reproduce: - Type a command (e.g., /table) to insert a table. - Select some cells and apply a background color using the toolbar. - Click the Background Color button again in the toolbar. - Go to the Custom tab in the color picker. - Adjust the opacity using the slider. ### Description of the issue/feature this PR addresses: - Adjusting the opacity slider had no effect on the background color preview. ### Desired behavior after PR is merged: - The preview updates dynamically as the opacity slider is moved. task-4942309 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix lets Odoo disable image transformation controls in places where they do not work, such as PDF reports. Users avoid applying visual changes that would be ignored, reducing confusion and improving report editing reliability.
Original PR description
Problem: In some contexts, such as reports, the `transform` option is not needed or applicable. For example, `transform` is not supported by `wkhtmltopdf`, so any applied transformation is ignored. Solution: Introduce the ability to disable the `transform` option when needed. opw-4809761 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#218352
Fixes tax report calculations when invoices use the same tax with different analytic distributions. Businesses will see accurate net/base amounts in grouped tax reports, helping avoid misleading tax reporting figures.
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 a line, add the tax on it and change the analytic distribution - Do the same for another invoice with another analytic distribution - Confirm the invoices - Go to the tax report - Select the report "Group By: Account > Tax" - On the report the "Net" amount is only the one of the first invoice, the tax amount is correct ### Cause: The bug appeared after this [commit](https://github.com/odoo-dev/enterprise/commit/9a7142ef57503efad9538e571d2e35c4aaa59531) which fixed another issue with analytics. Now several lines with the same tax can be returned by the query if they have different analytics. This was used to avoid having the base amount doubled on the invoice when several lines from the same move had with different analytics: there is a line for each analytic but they all have the same base, in the end the base amounts was doubled for each different analytic. Now the query returns multiple lines but as they all have the same key the base amounts are not added together. This fixes the previous issue when several lines from the same move but with different analytics were added but it creates another issue when different invoices have the same tax and different analytic because these lines also have the same key. This result in only the base amount of the first invoice to be taken into account. ### Solution: The previous fix was incorrect. The correct fix is to not join the lines when there are two tax lines. To do this the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line_tax_details.py#L153) in the query needs to be the same as the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line.py#L984) that will duplicate the lines in python. The check on `use_in_tax_closing` was missing so we add it. opw-4766421 Forward-Port-Of: odoo/odoo#220394
This fix restores product codes in electronic invoices and ensures barcode identifiers use the required format. It also removes an incorrect bank branch attribute for Peppol BIS3 invoices, helping invoices pass validation and reducing rejection risk.
Original PR description
### [FIX] account_edi_ubl_cii: Add SellerItemIdentification and add tests Before the UBL refactor, the `SellerItemIdentification` node was populated with the product code. We restore this behaviour. In addition, the refactor added the `StandardItemIdentification` node without specifying the `schemeID` (which is required by the schematron), then commit f46c10f03e59e8 added `schemeID="0160"` This commit adds tests to enforce this behaviour. task-none ### [FIX] account_edi_ubl_cii: BIS3 rm FinancialInstitutionBranch/schemeID In BIS3, the `FinancialInstitutionBranch` node should not specify the `schemeID` property. https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-CR-655/ This was correct before the UBL refactor but was messed up by the refactor. task-none
The checkout address form now correctly recognizes Uruguay as the website country. This restores the Uruguay-specific identification type options customers need during ecommerce checkout.
Original PR description
Steps: - Install Uruguay Ecommerce. - Set Uruguay company on website. - Go to address page on the checkout. Issue: - Uruguay related ID types are missing. Cause: - Because of bad adaption of Fw-port to 18.0 wrong county_code was set on PR https://github.com/odoo/odoo/pull/218920. Fix: - Update county_code to UY instead PE.
Fixed a rounding issue where analytic accounting splits could add up to a slightly different total than the original invoice line. This prevents one-cent discrepancies in analytic reports and keeps accounting figures aligned with invoices.
Original PR description
**PROBLEM** Sometimes, the sum of the generated analytic lines for an invoice line doesn't equal the amount on the invoice line. For example, in invoice line with a price of 182.25, with an analytic…
**PROBLEM** Sometimes, the sum of the generated analytic lines for an invoice line doesn't equal the amount on the invoice line. For example, in invoice line with a price of 182.25, with an analytic distribution split into 98% and 2%, the generated analytic lines amount to 182.26 (off by 0.01) because of rounding. **STEP TO REPRODUCE** 1. install the accounting module and enable the Analytical Accounting option. 2. create an invoice, with a line with a price of 182.25, and a distribution of 98%/2%. 3. confirm the invoice. 4. go to Accounting/Analytics Items and notice the sum of analytical line is 182.26 instead of 182.25. **CAUSE** We only apply rounding after having calculated all the analytic line amounts. This mean we will sum the rounding error. In our example, the computation is like so: 98% of 182.25 = 178.605 rounded to 178.61 2% of 182.25 = 3.645 rounded to 3.65 178.61 + 3.65 = 182.26 **FIX** We compute the last analytic line for each plan, relatively to the other. `last_line_amount = invoice_price - sum(rounded_other_line_amount)` This ensure that the sum of analytic lines is always equal to the invoice price. opw-4848784 Forward-Port-Of: odoo/odoo#219602 Forward-Port-Of: odoo/odoo#214736
Malaysia electronic invoices now place prepaid amounts in the format required by MyInvois. This helps prevent submission issues for invoices involving prepayments and keeps generated documents aligned with local reporting rules.
Original PR description
Before: Prepaid Amount was submitted under LegalMonetaryTotal node, which follows UBL format but not supported for MyInvois. After: Introduced separate PrepaidAmount node used specific to Malaysia to support MyInvois. taskID-4947994 Forward-Port-Of: odoo/odoo#219419
When a cashier enters a product barcode in Point of Sale, Odoo now uses that barcode to preselect the matching product variant options in the configuration popup. This reduces manual selection steps, speeds up checkout, and helps avoid mistakes for products with multiple attributes.
Original PR description
Before this commit, when a user manually entered a product barcode in the search bar, and the product had multiple attributes and values, the configuration popup required the user to manually select the correct attribute values—even though the barcode uniquely identified the product variant. This slowed down the selling process and caused unnecessary friction. With this commit, when a product is found via its barcode (including manual entry), the configuration popup is automatically preset to the correct attribute values associated with that barcode. This improves the user experience and speeds up sales, especially for products whose barcodes cannot be scanned and must be entered manually. opw-4635497 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
A failing automated test for restaurant point-of-sale order synchronization was corrected. This helps keep the restaurant POS quality checks reliable, reducing the risk of synchronization issues reaching users.
Original PR description
Fixes the failing test `test_synchronisation_of_orders` by creating the order data through frontend `ORM` calls instead of patching the `notify_synchronisation` method. Introduced here: https://github.com/odoo/odoo/pull/207406 Error-[230275](https://runbot.odoo.com/odoo/runbot.build.error/230275)
This fixes an internal testing helper so freezing time is explicit instead of accidentally toggling on or off. It reduces the risk of misleading automated tests and helps developers catch issues more reliably before they affect users.
Original PR description
The freezeTime utility function had a very strange behaviour: if it is called without an argument, it would toggle the current value. This means that if i read a test that calls freezeTime, i actually do not know if the time is frozen after that function call. This could be a problem in many subtle situations. For example, if a test is using freezeTime, and then later, someone add a `beforeEach(freezeTime)` in that suite without removing the existing freezeTime, then weirdly, the test would no longer be "protected". This commit simplifies the behaviour of freezeTime to make sure we know what we are doing in all cases. 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
Underlines and strikethroughs now remain visible when users apply gradient text in the website editor. This fixes a visual issue so formatted website content appears as intended for visitors.
Original PR description
Problem: Using `-webkit-text-fill-color: transparent;` in `.text-gradient` is required for gradient text, but it also causes underline (`<u>`) and strikethrough (`<s>`) styles to become invisible, since those decorations rely on the text fill color. This results in the lines under `u` and `s` elements not being rendered when gradient text is applied. Solution: Render the underline and strikethrough manually using a `background-image` (gradient) applied to `s` and `u` tags. This simulates the missing lines while keeping the gradient text style. Steps to reproduce: 1. Add a text block in the website editor. 2. Apply a text color gradient. 3. Apply underline or strikethrough. → The underline/strikethrough is not visible. opw-4797201 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#210390
This fix prevents upgrades from failing when Documents folders with email aliases belong to different companies. Odoo now creates the related mail alias using the correct company context, avoiding domain ownership validation errors during migration.
Original PR description
**Step to reproduce:** 1. Install documents in version 17.0. 2. create new company for that create document folder and set alias_domain 3. upgrade to 18.0 below menitoned traceback will raise…
**Step to reproduce:**
1. Install documents in version 17.0.
2. create new company for that create document folder and set alias_domain
3. upgrade to 18.0 below menitoned traceback will raise
**Issue** :-
previously fix was deployed https://github.com/odoo/upgrade/commit/edae53792f81859dd4c843d8da4307e4eae8e0ff in the upgrade forcefully creating the incoming mails.
**Cause** :-
``mail.alias.mixin`` is introduced in existing [model]( https://github.com/odoo/enterprise/commit/a32825ee00f2b330d99113f4d8c1488903fe744e#diff-b394e0e6aa5c87ff7d84c0317fa2ed372a90b7d3e730c462fcb81d4b747f46ebL34) As ``alias_id`` is kept as false according to this new alias records are creating but as it sudo it bringing all company records due to this and during upgrade env company is admin related company which is letting alias_domain_id [here](https://github.com/odoo/odoo/blob/9719feb1fac64e06c988b336b077a0aa47a2b96a/addons/mail/models/mail_alias.py#L262) of that company which is leading to validation error
**Fix:**
for fixing this is record have company_id so create mail alias
according to that
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/18.0/odoo/service/server.py", line 1361, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-13>", line 2, in new
File "/home/odoo/src/odoo/18.0/odoo/tools/func.py", line 97, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 129, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 480, in load_modules
processed_modules += load_marked_modules(env, graph,
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 365, in load_marked_modules
loaded, processed = load_module_graph(
File "/home/odoo/src/odoo/18.0/odoo/modules/loading.py", line 206, in load_module_graph
registry.init_models(env.cr, model_names, {'module': package.name}, new_install)
File "/home/odoo/src/odoo/18.0/odoo/modules/registry.py", line 617, in init_models
func()
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_alias_mixin.py", line 49, in _init_column_alias_id
alias = self.env['mail.alias'].sudo().create(record._alias_get_creation_values())
File "<decorator-gen-136>", line 2, in create
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 495, in _model_create_multi
return create(self, [arg])
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_alias.py", line 266, in create
return super().create(vals_list)
File "<decorator-gen-120>", line 2, in create
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 496, in _model_create_multi
return create(self, arg)
File "/tmp/tmppqp1_15u/migrations/util/orm.py", line 249, in wrapper
return f(*args, **kwargs)
File "/tmp/tmppqp1_15u/migrations/base/0.0.0/pre-models-match_uniq.py", line 25, in create
return super().create(vals_list)
File "<decorator-gen-31>", line 2, in create
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 496, in _model_create_multi
return create(self, arg)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5017, in create
records = self._create(data_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5275, in _create
records._validate_fields(name for data in data_list for name in data['stored'])
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 1631, in _validate_fields
check(self)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_alias.py", line 159, in _check_alias_domain_id_mc
raise ValidationError(_(
odoo.exceptions.ValidationError: We could not create alias Inactive Alias because domain bsiri.co.th belongs to company BSIRI Company Limited (HeadOffice) while the owner document belongs to company MindGift LL>
```
upg-3017582
opw-4941387
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prSales quotations now calculate fixed taxes correctly when an early payment discount is applied. This prevents customers from seeing duplicated fixed tax amounts, improving billing accuracy and reducing invoice corrections.
Original PR description
### Issue: The fixed tax value is doubled in `sale` when an early payment discount is applied. Steps to reproduce: - Create a fixed tax of $20 for example - Create a payment term with an early…
### Issue: The fixed tax value is doubled in `sale` when an early payment discount is applied. Steps to reproduce: - Create a fixed tax of $20 for example - Create a payment term with an early discount of 10% if paid before 10 days - Select "Always (upon invoice)" - In Sale create a new quotation with a line of $100 and the fixed tax - Select the created payment term - The tax value is doubled ($40) ### Cause: To compute the payment terms `_add_base_lines_for_early_payment_discount` (added in this [commit](https://github.com/odoo/odoo/commit/781678fb07ab3dd4d132193a938bbb71e8395424)) is adding two lines: - one with the negative amount of the payment term and the taxes - one with the positive amount of the payment term The goal is to compute the taxes on the discounted untaxed amount of the line. The original line compute the taxes for the undiscounted amount. The first added line computes the taxes for the amount of the discount and is negative. When adding the two the result is the tax value computed from the discounted untaxed amount. The issue is that a fixed will always have the same value, this means that the tax amount of the first added line will be positive and the same as the original line. When adding the two the amount is doubled. ### Solution: We don't add taxes with fixed amount on the first add line. opw-4868011
Uploading a non-PDF file as a product document for quote PDFs no longer triggers an immediate system error. The system now avoids trying to read non-PDF files as PDFs, allowing the existing validation to handle the file type cleanly when the record is saved.
Original PR description
Currently an error occurs when user uploads a non-pdf file on product documents. Steps to replicate: - Install `sale_management` and go to products. - Open any product's form view and click on the…
Currently an error occurs when user uploads a non-pdf file on product documents. Steps to replicate: - Install `sale_management` and go to products. - Open any product's form view and click on the `Documents` smart button. - Click new and upload any non-pdf file. - On the field `Sale : Visible at`, select the value `inside quote pdf` and you will get the error. Error: `PdfReadError: EOF marker not found` The error occurs because at the line [1] the code requires a pdf file, and as we have passed a non-pdf file the error occurs. [1] - https://github.com/odoo/odoo/blob/e750244c3125a48e2ca030160b977bb0344609db/addons/sale_pdf_quote_builder/models/sale_pdf_form_field.py#L206 There is already a constraint made for this particular thing [2], but the problem is that the error is due the compute [3] (Because constraints are checked at the time of form saving, and compute runs when a field is changed so even before the constraint is checked the error will be triggered). [2] - https://github.com/odoo/odoo/blob/e750244c3125a48e2ca030160b977bb0344609db/addons/sale_pdf_quote_builder/models/product_document.py#L44-L45 [3] - https://github.com/odoo/odoo/blob/e750244c3125a48e2ca030160b977bb0344609db/addons/sale_pdf_quote_builder/models/product_document.py#L59-L61 This commit resolves this issue by skipping the pdf extraction if the file is not a pdf type, because we already have a constraint [2] that will trigger at save. sentry-6161120972 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The view-switching shortcut label now remains clearly visible when users switch between views. This avoids a small visual overlap in the interface, making the control panel easier to read and use.
Original PR description
Previously when switching views using the hotkey, the hotkey (SHIFT + V) was not properly visible, it was overlapping with the active view button. After this commit the hotkey (SHIFT + V) will be visible and not overlap with the active view. task-4828401 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Very small negative values that round to zero are now shown as normal zero instead of negative zero. This avoids confusing displays such as "-0.00" in screens, reports, and generated documents where the value is effectively zero.
Original PR description
float_repr(-0.00000001, 2)
formatFloat(-0.00000001, { digits: [16, 2] })
Before: "-0.00"
After: "0.00"
opw-4685953
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prMobile users opening a subtask from a project task now see it in the main screen instead of a pop-up. This makes the discussion area available, so users can communicate with customers directly from the subtask.
Original PR description
Before this commit, when the user is in mobile view and go to a task with subtasks and selects a subtask, the form view of that subtask is opened inside a dialog form view instead of opening the…
Before this commit, when the user is in mobile view and go to a task with subtasks and selects a subtask, the form view of that subtask is opened inside a dialog form view instead of opening the record in the main view. Because of that, the chatter for that subtask is not displayed. This commit opens the form view in the main view instead of opening it inside a form view dialog to be able to display the chatter of the subtask selected. Steps to reproduce the issue: ---------------------------- 1. Install project and go to project app. 2. Create a project A. 3. Add a task inside the project A 4. Add a subtask inside the new task created in step 3 5. Open the form view of the task created in step 3 in mobile 6. Click on the kanban record contained the subtask created in step 4 Expected behavior: ----------------- The chatter should be displayed in the form view of that subtask to be able to communicate with the customer. Current behavior: ---------------- Since the form view of the subtask selected is opened inside a form view dialog the chatter for that subtask is not displayed. task-4278273
Imported sales orders in Point of Sale now keep the tax position set on the sales order, even when it differs from the customer's default tax position. This helps ensure taxes are calculated consistently with the original sale and reduces billing errors at checkout.
Original PR description
When a sales order is imported into the PoS, the tax position does not match if the sales order has a different tax position than the one assigned to the partner. This commit ensures that the tax position will always be the one assigned to the sales order and not that of the partner. taskId: 4963118
The mail activity counter in the systray now refreshes correctly when activities are archived, rescheduled, reassigned, created, or deleted in batches. This helps users see an accurate number of pending activities without needing a manual refresh.
Original PR description
Currently the systray counter is only updated at: - create - unlink - write, but only if the user changes We want to detect changes such as activities being archived or due dates being updated to properly reflect the changes as the user applies them. We now do a separate check for activity count per user before and after a write call that modifies these fields. Additionally since we now have a count we provide that as part of the bus notification so that it can be updated accurately when modifying/creation/deleting activities in batch. Common activity test utils are updated to avoid false negatives. task-4862215
This fixes an intermittent issue in automated checks for Knowledge pages that include embedded calendars. By making the resize action happen consistently, it helps reduce false test failures and improves confidence in releases without changing user-facing behavior.
Original PR description
This commit fixes an indeterministic error in the knowledge_calendar_command_tour when a calendar view is embedded and an event is resized. The resize handler is only visible when hovering the event, which is required to actually be able to resize it. This commit merges both the "make resizer visible" step and the "resize the item" step into a single one as those actions should be done in one go, instead of separate steps (cf. the hovering state is kind of reset in-between the steps). Note: this matches the behavior of the CalendarView's unit tests helpers (`resizeEventToTime()`). runbot-error-163015
This fixes an issue where some online bank synchronization fields could disappear because provider details are no longer sent by Odoofin. Businesses can keep viewing and managing the needed synchronization information, with a related search behavior also corrected; the module must be updated for the fix to apply.
Original PR description
The fields on the online synchronization were invisible if no provider_data wass put on the synchro. But now, this info is not given anymore from Odoofin. So, we should not hide these fields based on provider_data. Also fixed a search domain. It will need an update of the module. Forward-Port-Of: odoo/enterprise#90822 Forward-Port-Of: odoo/enterprise#90785
Tax reports grouped by account and tax now show the correct net base amounts when invoices use the same tax with different analytic distributions. This prevents understated or duplicated tax report bases, improving accuracy for accounting and reporting.
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 a line, add the tax on it and change the analytic distribution - Do the same for another invoice with another analytic distribution - Confirm the invoices - Go to the tax report - Select the report "Group By: Account > Tax" - On the report the "Net" amount is only the one of the first invoice, the tax amount is correct ### Cause: The bug appeared after this [commit](https://github.com/odoo-dev/enterprise/commit/9a7142ef57503efad9538e571d2e35c4aaa59531) which fixed another issue with analytics. Now several lines with the same tax can be returned by the query if they have different analytics. This was used to avoid having the base amount doubled on the invoice when several lines from the same move had with different analytics: there is a line for each analytic but they all have the same base, in the end the base amounts was doubled for each different analytic. Now the query returns multiple lines but as they all have the same key the base amounts are not added together. This fixes the previous issue when several lines from the same move but with different analytics were added but it creates another issue when different invoices have the same tax and different analytics. Because these lines also have the same key. This result in only the base amount of the first invoice to be taken into account. ### Solution: The previous fix was incorrect. The correct fix is to not join the lines when there are two tax lines. To do this the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line_tax_details.py#L153) in the query needs to be the same as the [condition](https://github.com/odoo/odoo/blob/cf8d38205c09a2724f41907fa07c5f23ff2d46a3/addons/account/models/account_move_line.py#L984) that will duplicate the lines in python. The check on `use_in_tax_closing` was missing so we add it. opw-4766421 Forward-Port-Of: odoo/enterprise#90936
Odoo Studio now disables image transformation options when editing reports because those changes cannot be reproduced in generated PDF files. This prevents users from applying visual changes that would disappear in the final PDF, making report previews and output more predictable.
Original PR description
Problem: Image transformations are not applied in generated PDFs because they are not supported by `wkhtmltopdf`. Solution: Disable image transform options when rendering reports to ensure expected output and avoid unsupported behavior. Steps to reproduce: - Open any report in Studio - Add an image - Apply a scale transformation - Generate a PDF preview > The image transform is not applied in the generated PDF opw-4809761 Forward-Port-Of: odoo/enterprise#89952
Barcode scanning now finds internal stock locations only within the active company. This prevents users in multi-company setups from being sent to the wrong location when different companies use the same barcode.
Original PR description
Description of the issue/feature this PR addresses: When scanning a location by barcode, the system may return the wrong location if multiple companies have internal locations with the same barcode. This is because the search does not currently filter by company. Current behavior before PR: The system searches for a location using only the barcode and usage='internal', without restricting by company. If multiple companies use the same barcode for different locations, the first match (regardless of company) is returned. Desired behavior after PR is merged: The location search is now restricted to the active company.
Belgian Intrastat XML exports now respect the option to hide zero-value lines. This prevents transactions with no cost from being included in exported reports, keeping submitted files consistent with what users see on screen.
Original PR description
_______________________________________ ## Short functional explanation of the error On the export intrastat report page, we can click on the 'Posted Entries' button, which allows us to select 'Hide…
_______________________________________ ## Short functional explanation of the error On the export intrastat report page, we can click on the 'Posted Entries' button, which allows us to select 'Hide lines at 0'. Doing this will prevent 0 cost transactions from appearing in the report. However, when exporting to XML, such transactions are still displayed. Note: this is related to Belgian companies only. ## Reproduction Steps 1. Go to settings and make sure the company you're operating with is Belgian. Then, in accounting, under the Custmer Invoices section, check the 'Intrastat' option. 2. Go to products and create a new product of type 'Goods'. Then, in the 'Accounting' tab, click on a random commodity code. Set the country of origin as a country belonging to the European Union (for example, Austria). Click on save. You should see a field named 'Intrastat Supplementary Unit Amount' appear. 3. Go to accounting. Click on the 'Vendors' tab and 'Bills'. Click on New. Select a random vendor, and add a line containing the product you just created. Add the column 'Intrastat' and set the corresponding field at '11 outright...'. Then, set a price. In the 'Other Info' tab, set the field 'Intrastat Country' as a random country in the European Union (for example, Australia). Set the fiscal position at 'Import/Export' and set the 'Intrastat Transport Mode' field at '1. Sea transport'. Finally, click on confirm. 4. Duplicate the vendor bill you just created. On this new vendor bill, set the Intrastat at '12 Direct trade...'. Display the column 'Disc.%' and set the field at 100. Then click confirm. 5. Click on the 'Reporting' tab, and under 'Audit Reports', click on 'Intrastat Report'. Set the month to the current month, then click on 'Report: Intrastat(Services....)' and select 'Intrastat (Goods)'. You should be able to see the 2 vendor bills you just created. Click on 'Options' then 'Hide lines at 0': you should see the bill having a 0 cost disappear. Finally, click on the cog on the top left next to 'Intrastat Report' and click on 'XML'. 6. Once the XML file has finished downloading, open it. ### Expected behavior The transaction having a 0 cost shouldn't appear. ### Unexpected behavior The transaction having a 0 cost appears. ## Origin of the issue In the code responsible for the display of the XML report, there isn't any condition responsible for checking if the transaction should be displayed or not. _________________________________________ opw-4464123 --- Forward-Port-Of: odoo/enterprise#89285
This fixes refund receipts in the Italian point of sale so fiscal printers receive the refund details they need. It prevents fiscal printers from blocking when processing refunds, restoring normal checkout operations for affected Italian retailers.
Original PR description
The refund are bugged after PR #89419 . That PR removed the header but in the header are passed the refund information needed by italian fiscal printer to print the refund. Without this PR the fiscal printer is blocking. The printRecMessage on the receipt is required before the beginfiscalreceipt
Customer statement reports can now be sent even when selected customer records include contacts without names. The system skips unnamed contacts when preparing report details, preventing scheduled email delivery failures and reducing interruptions for accounting users.
Original PR description
**PROBLEM** In the accounting app, when selecting multiples customers, if one of them doesn't have a name, the cron sending the report will traceback. **STEP TO REPRODUCE** - On a clean db, install…
**PROBLEM** In the accounting app, when selecting multiples customers, if one of them doesn't have a name, the cron sending the report will traceback. **STEP TO REPRODUCE** - On a clean db, install the account_reports module - From the accounting app, create a new company customer (Customers/Customers) - From that new company customer form view, add a new contact of type "other" and don't specify a name for it. - Create an invoice for the company - From the customer list view, select all, and trigger the action "Open Customer Statements" - Send -> Print and Send - Check the console, the cron task should traceback on the template **CAUSE** In accout_report.py, we get the name of each selected partners, and we don't check if the name doesn't exist. In the template `pdf_export_filters`, we try to join all the name in a string, it fails because one of the name isn't a string (its value is False because it doesn't exist on the partner record). **FIX** When getting the partners names, filter out the partners without names. opw-4916660
Very small negative amounts that round to zero are now shown as 0.00 instead of -0.00 in Luxembourg reports. This prevents confusing or misleading figures in generated report values.
Original PR description
float_repr(-0.00000001, 2)
formatFloat(-0.00000001, { digits: [16, 2] })
Before: "-0.00"
After: "0.00"
opw-4685953Uploading files through the Documents chatter no longer shows temporary upload progress cards or rows in the main document views. This keeps kanban and list views cleaner and avoids confusing users with transient upload visuals.
Original PR description
Step to reproduce: - In Documents, open the chatter either on a folder or a document. - Upload an attachment through the chatter. - You will see the upload kanban card / list row showing the progression. There should be no visual in kanban/list views showing the progression. Task-4863051 Forward-Port-Of: odoo/enterprise#87410
Users with Planning permissions but no Employee access can now open and view Planning roles without encountering an access error. This keeps role configuration available to planning users while respecting employee-related access restrictions.
Original PR description
Trying to display the roles in the planning app is not possible if the user doesn't have hr_rights even with full planning rights. ** Step to reproduce ** - Connect to Odoo with an user that only have acces right for "Planning" (no employees). - Open Planning app - Configuration>Roles - It will trigger an Access Error (If it didn't trigger add a user to Ressources) ** Cause of the issue ** The acces for the default_role_id is limited to hr.group_hr_user: https://github.com/odoo/enterprise/blob/a7122011a0b0cdd111eccf59c917c6b8e2c25137/planning/models/resource_resource.py#L27 But is used in _compute_display_name: https://github.com/odoo/enterprise/blob/a7122011a0b0cdd111eccf59c917c6b8e2c25137/planning/models/resource_resource.py#L73 ** Fix ** Retrieve the information about the role with sudo opw-4908979
Sales commission achievement reports now include down payments and invoice lines that do not have a product assigned. This fixes mismatches between invoice analysis totals and commission results, helping sales users and managers see more accurate commission achievements.
Original PR description
In the sale achievement report, down payments and other account move lines that have no product attached to them would not be accounted for in the sale commission achievement report. This was due to the fact that the table was being inner joined on product_id which would get rid of records that had no product. Because of this behavior there would be a mismatch between the invoice analysis of a user and their commission even if the rate was 100% on the commission plan. Left joining the products onto the account move line keeps the lines with no products and fixes the discrepancy between the report and the invoice analysis. opw-4625340
Creating a new helpdesk ticket from the timesheet timer now keeps the selected support project and applies the right helpdesk team. This prevents validation errors and ensures users see the ticket option even before any tickets exist for that project.
Original PR description
Steps to reproduce: ------------------- - Install 'helpdesk_timesheet' module - Go to Timesheets and click on `Start` to launch the timer - Select `VIP Support` as Project - Create a new ticket…
Steps to reproduce: ------------------- - Install 'helpdesk_timesheet' module - Go to Timesheets and click on `Start` to launch the timer - Select `VIP Support` as Project - Create a new ticket Issue: ------ 1. Validation error raised: `At least one analytic account must be set.` 2. When we select a helpdesk project that does not have any ticket linked to it already, the field next to it is set to `Task` (task_id) instead of `Ticket` (helpdesk_ticket_id). Cause: ------ 1. When creating the ticket, we don't provide the default project who got the analytic account linked to it. 2. The field `helpdesk_ticket_id` is hidden because we consider that we the project is not linked to any helpdesk team; this is because we retrieve the projects based on tickets already created only. Solution: --------- 1. Set the default project in the context when creating the ticket (like for a task). In the create method, if no team is provided and we have a default project (from `list_value` or the `env.context`), we set the team based on the project if the project is linked to a helpdesk team. 2. Fetch all projects that have `helpdesk_team` field set. opw-4404097
Products with GST rates above 5% now include the required packaged-good tag when synced to Swiggy and Zomato. This helps ensure product information is sent consistently to delivery partners, reducing listing or compliance issues.
Original PR description
*: pos_urban_piper_swiggy, pos_urban_piper_zomato Before this commit: --- - Products with GST != 5% were not receiving the `packaged-good` tag in the sync payload for Swiggy and Zomato. After this commit: --- - Now, products with GST != 5% correctly include the `packaged-good` tag in their respective provider tag list (`swiggy` or `zomato`). task-4954571