Daily updates from Odoo
Wednesday, July 23, 2025
13 changes · master
Resolved issues and error corrections
A spreadsheet issue has been fixed where autofilling pivot columns could cause a crash, especially when the columns were originally created through autofill or involved dates outside the expected range. This improves reliability for users working with spreadsheet pivots and reduces interruptions during data analysis.
Original PR description
Fix crash when autofilling columns which where created by autofill. Task: 4719884 Forward-Port-Of: odoo/enterprise#90566 Forward-Port-Of: odoo/enterprise#83314
This fix ensures that refunding an invoiced point-of-sale order in the Peruvian localization opens the expected reason dialog instead of sending users back to the order screen. It helps store staff follow the correct refund process and avoids confusion when handling invoiced sales.
Original PR description
Steps to reproduce - install `l10n_pe_edi_pos` module - open a pos session - create a order, when checking out, tick `invoice` checkbox - pay and complete the order - go to order menu (present in…
Steps to reproduce - install `l10n_pe_edi_pos` module - open a pos session - create a order, when checking out, tick `invoice` checkbox - pay and complete the order - go to order menu (present in navbar) - select the previously completed order, apply for refund Observation: you are navigated to Order screen Expectation: A dialog for reason should be open first Issue - after this commit odoo/odoo@3a09ea7 and odoo/enterprise@e3e84bb account_move field is used instead of `invoiced` state of order. But the `account_move` field is always undefined. This is due to fact that when pos_order is fulfilled from `syncAllOrders` function, a call to `missingRecursive` is made, as `account.move` model is never loaded, it is unable to link it to appropriate model and results to undefined Fix - use `order.raw.account_move` instead of `order.account_move` Note: `account.move` is loaded from saas-18.3 by https://github.com/odoo/odoo/pull/201528 opw-4744785 Forward-Port-Of: odoo/enterprise#90166 Forward-Port-Of: odoo/enterprise#87283
This update fixes errors that could block users from connecting or setting up bank accounts in Odoo. It restores the expected flow so businesses can continue linking bank accounts for online synchronization without encountering crashes.
Original PR description
After [this PR](https://github.com/odoo/enterprise/pull/81894) was merged, we are encountering below errors. **Issue 1:** An error occurs when attempting to connect a new bank account. **Step to…
After [this PR](https://github.com/odoo/enterprise/pull/81894) was merged, we are encountering below errors. **Issue 1:** An error occurs when attempting to connect a new bank account. **Step to produce:** - Install the `account_online_synchronization` module and open `invoicing`. - Go to: `Configuration > Banks > Add a Bank Account`. - `Add new bank > Enter Details > Connect`. **Error:** `TypeError: AccountOnlineLink.create_new_bank_account_action() takes 2 positional arguments but 3 were given` **Root cause:** It appears that removal of `@api.model` was missed in [this PR](https://github.com/odoo/enterprise/pull/89932) during the forward-port process, leading to this error. **Fix:** This commit removes `@api.model` so that the method behaves like a recordset method, as done in [this PR](https://github.com/odoo/enterprise/pull/81894). **Issue 2:** An error occurs when attempting to Setup Bank. At [1], when an exception occurs, the method returns an empty list, and this displays the `Setup Bank` button. Upon clicking the button, an error occurs. [1] https://github.com/odoo/enterprise/blob/443d7d303ecb3bfcba6ac865cf0185b5070b6b9d/account_online_synchronization/models/account_journal.py#L88-L97 **Error:** `ValueError: Expected singleton: account.online.link()` **Root Cause:** At [2], the JS method `fallbackConnectBank` was passing only one positional argument instead of two. However, the corresponding Python method at [3] requires two positional arguments. [2] https://github.com/odoo/enterprise/blob/443d7d303ecb3bfcba6ac865cf0185b5070b6b9d/account_online_synchronization/static/src/components/bank_configure/bank_configure.js#L67-L71 [3] https://github.com/odoo/enterprise/blob/443d7d303ecb3bfcba6ac865cf0185b5070b6b9d/account_online_synchronization/models/account_online.py#L418 This commit updates the JS method `fallbackConnectBank` to pass two positional arguments as required by the python method at [3]. sentry–6745764054,6388425767 Forward-Port-Of: odoo/enterprise#90225
Referral refusal notifications are now only sent after HR confirms a refusal, avoiding premature messages when the wizard is merely opened. The notification is also linked to the referrer’s user record, preventing unnecessary email processing delays and improving performance.
Original PR description
## [PERF] hr_referral: Send refusal notification to referrer's users Description ----------- Following https://github.com/odoo/enterprise/commit/764f9b6f513c90eb79935d9e8469989ea704b61b,…
## [PERF] hr_referral: Send refusal notification to referrer's users Description ----------- Following https://github.com/odoo/enterprise/commit/764f9b6f513c90eb79935d9e8469989ea704b61b, `_send_notification` will not attach the message on the `hr.applicant` itself, so a `model` was provided. But due to a missing `res_id`, `message_notify` will set both `model` & `res_id` to `False` since both are not specified. This leads to the creation of a `mail.message` with no `res_id` and no `model` (as `self` is an empty `mail.thread` recordset). This leads to a performance regression when mail references need to be computed to attach to the notification in `_notify_by_email_get_base_mail_values`, due to the missing `model` and `res_id` of the message. This commit attaches the notification to the referrer's users instead, providing its `model` and `res_id`. Reference --------- opw-4943488 --- ## [FIX] hr_referral: Do not send notif when opening the refuse wizard Description ----------- Currently, when opening the refusal wizard for an applicant, a call to `archive_applicant` is made. However, there is an override of it in `hr_referral` to send a notification for the applicant's refusal, and closing the `referral_state`, even though the applicant may have not been provided a reason for refusal, and the HR can simply close the wizard instead of confirming it. This commit removes the override of `archive_applicant` and moves its logic into `action_refuse_reason_apply` which is called when the wizard is confirmed. Reference --------- opw-4943488 Forward-Port-Of: odoo/enterprise#90563 Forward-Port-Of: odoo/enterprise#90309
This fixes an issue where POS sessions could not be closed after using an Urban Piper payment method assigned to a shop. The closing screen now avoids listing the same Urban Piper payment method twice, preventing the error and keeping end-of-day operations unblocked.
Original PR description
Currently if setting a urban piper payment method on a shop and using it at checkout will not allow you to close the session. Steps to reproduce: ------------------- * Go in the setting and set up…
Currently if setting a urban piper payment method on a shop and using it at checkout will not allow you to close the session. Steps to reproduce: ------------------- * Go in the setting and set up urban piper (no need for credentials) testing with random keys will do * Go into the payment methods and take one of the urban piper one and assign it to a shop * Open that shop * Place an order and use the urban piper payment method * Validate * Try closing the session > Observation: Nothing happen, we're now unable to select the menu. If doing the same steps but in debug mode, a traceback is shown indicating a duplicate key in a t-foreach Why the fix: ------------ The duplicate key is happening when rendering the closing popup because the function `get_closing_control_data()` was returning twice the information related to the urban piper payment method. Even though urban piper wasn't build with the use case in mind we want to keep it possible. We avoid sending twice the urban piper methods if they were already computed in the super method. opw-4874699 Forward-Port-Of: odoo/enterprise#90584 Forward-Port-Of: odoo/enterprise#88156
Manufacturing orders created through Barcode now generate the full set of stock transfers required for 3-step manufacturing, including component picking and finished product storage. This helps keep warehouse operations complete and consistent, and also ensures by-product movements are correctly linked to the manufacturing order.
Original PR description
Task: 4558792 If 3-step manufacturing is enabled, the creation of an MO should also create 2 stock transfers: "Pick Components" and "Store Finished Product". Currently, when an MO is created via Barcode, only SFP is created. The problem boils down to the newly created stock move not having a `warehouse_id` field set, which causes Odoo to miss the required stock rules. This PR fixes the issue by fetching the `warehouse_id` field in XML, from where it is later passed to JS and back to Python's `create` method. Additionally, by-product moves for MOs created via Barcode were not correctly associated with the MO. This issue was solved by passing the missing fields from XML to Python. Forward-Port-Of: odoo/enterprise#90451 Forward-Port-Of: odoo/enterprise#83895
Selecting specific appointment types for an appointment button no longer causes an error. The selected appointment types now show their names correctly, making the website editor option usable and clearer for users.
Original PR description
Since [1], the conversion of actions to classes introduced a forgotten shared function, leading to a traceback when specifying appointment types under the "Appointments" option. Additionally, this commit corrects the missing `display_name` in `SetAppTypesAction`. Previously, this omission caused the selected appointment types to appear empty without a name in the UI. Steps to reproduce: - Drop "Appointment Button" - Change "Appointments" option to "Specific Types" - Click on "Specify" option and choose any record from the list - Traceback occurs [1]: https://github.com/odoo/enterprise/commit/1f8b599a23330b03bffd898d85fe74a0f0eeda1f Forward-Port-Of: odoo/enterprise#90612
Completed signing certificates are now downloaded as separate files instead of being merged into the signed PDF. People involved in a signing request, including signers and copied recipients, can also download the original documents while access remains limited to relevant users.
Original PR description
This PR targets reverting to the previous behavior where certificate of completion is never merged with the original PDF but downloaded separately. It also handles the downloading of completed original documents in the list form/view: - For users who are involved in a sign request (either as a signer or CC'd), the original documents are now available for download. They are now granted read access to the related sign documents. - This ensures that any user who is asked to sign or is CC'd on a sign request can view and download the original documents, without exposing templates or documents to unrelated users. task-id-4886240 Forward-Port-Of: odoo/enterprise#88482
Document batches are now uploaded only after the related database changes are safely committed. This helps prevent OCR credits from being spent on documents that later fail due to a transaction rollback.
Original PR description
Since commit 7f7ff8d, the upload of a batch of documents isn't safe against a rollback of the SQL transaction. If there is a error after some documents were successfully sent to the OCR server, the transaction will be rollbacked and the IAP credits spent for those documents will be lost. This commit attempts at preventing that by moving the upload of the batch in a postcommit hook, where we can safely commit after each upload. opw-[4920363](https://www.odoo.com/odoo/project/2068/tasks/4920363)
German Intrastat XML exports now include required report details that were previously missing, such as the XML declaration, test indicator, agreement ID, and region code. This helps ensure reports generated from Odoo are accepted by the German Federal Statistical Office via INSTAT/XML.
Original PR description
In the German Intrastat-Report some elements are missing when downloding the xml report First, the XML version and character encoding must be included in the XML prolog Second, the element testIndicator is missing when its false Third, the element interchangeAgreementId under Party Fourth, the element regionCode under Declaration > Item `interchangeAgreementId` field is entirely form Odoo, and absence of one of these elemetns prevents the report from being accepted by German Federal Statistical Office via INSTAT/XML. To solve this we need to add a new field for interchangeAgreementId in the res_company opw-4752415
Corrects how Mexican electronic payment documents calculate VAT bases when invoices are paid in a foreign currency. This prevents payment CFDI submissions from being rejected because of small exchange-rate rounding differences, helping businesses complete compliant payment reporting.
Original PR description
Steps to reproduce: - With an MX Company setup - Set USD rate to 20.4277 - Create an invoice as follows: - line 1: price_unit 93.76, quantity 172, tax 16% - line 2: price_unit 74.18, quantity 161,…
Steps to reproduce:
- With an MX Company setup
- Set USD rate to 20.4277
- Create an invoice as follows:
- line 1: price_unit 93.76, quantity 172, tax 16%
- line 2: price_unit 74.18, quantity 161, tax 16%
- line 3: price_unit 74.18, quantity 162, tax 16%
- line 4: price_unit 93.76, quantity 384, tax 16%
- line 5: price_unit 111.28, quantity 178, tax 16%
- Confirm and send CFDI
- Register full payment in USD
- Send Payment CFDI
Issue: Payment validation will fail with error
> Code : 301
> Message : Error en complemento Recepción de Pagos. [Error #CRP20204] El
> Valor del campo TotalTrasladosBaseIVA16 no es igual al redondeo de la
> Suma del resultado de multiplicar cada uno de los importes de los
> Atributos BaseP de los impuestos trasladados registrados en el elemento
> TrasladoP donde los atributos contengan en ImpuestoP el valor IVA, en
> TipoFactorP el valor Tasa y en TasaOCuotaP el valor 0.160000, por el
> Valor registrado en el atributo TipoCambioP de cada nodo Pago. Folio: 2.
> Serie: PBNK1/2025/. El atributo "Totales:TotalTrasladosBaseIVA16"
> Contiene el valor "95898.54" sin embargo se calculó que la sumatoria
> Debe contener el valor "95898.45".
opw-4750981
Forward-Port-Of: odoo/enterprise#90287
Forward-Port-Of: odoo/enterprise#88952When creating a credit note for a Peruvian vendor bill, Odoo now shows the appropriate purchase journals instead of sales journals. This helps accounting users select the right journal and reduces errors when processing supplier refunds.
Original PR description
**Issue** When creating a credit note for a vendor bill, the journal selection dropdown incorrectly shows only sales-type journals instead of purchase-type journals. **Steps to Reproduce** 1. Install the modules: Accounting, l10n_pe, and l10n_pe_edi. 2. Navigate to Accounting > Vendors > Vendor Bills. 3. Open a posted vendor bill and click Credit Note. 4. Open the journal dropdown. 5. Notice that only sales journals are shown. **Root Cause** The journal field's domain was hardcoded to type = 'sale' in the inherited view. This forces the dropdown to show only sales journals, even when reversing a vendor bill. **Fix** Removed the hardcoded domain from the XML view. This allows Odoo to apply its standard logic for journal filtering, which correctly selects purchase journals when reversing vendor bills. Opw-4913997 Forward-Port-Of: odoo/enterprise#90445
Users can now import simple CSV bank statement files without the accounting dashboard crashing. The fix ensures the import flow keeps the needed information when closing, improving reliability for bank statement imports.
Original PR description
file.csv content: ```csv amount 1 2 ``` Steps: - Install `account_bank_statement_import_csv` - Open accounting/dashboard - Click on 3 dots on Bank - Import file - Choose file.csv (previously created) - Import - Traceback Since https://github.com/odoo/enterprise/pull/34249, a new class has been added to `ImportAction`: `BankStatementImportAction`. This class contains an override of the `exit` method that recalls `super.exit()` without including the potential arguments. This worked until recently, when https://github.com/odoo/odoo/pull/211187 finally included logic using this argument: `resIds` So now we received this domain which causes the crash ```js ["id", "in", undefined] ``` A solution would be to always call the super with arguments received. opw-4943902 Forward-Port-Of: odoo/enterprise#90633