Daily updates from Odoo
Saturday, February 8, 2025
27 changes
1 change
Miscellaneous changes
Versions -------- - 16.0+ Steps ----- 1. Enable Stripe Express Checkout; 2. go to eCommerce as Public User; 3. pay via express checkout for a deliverable item; 4. in Stripe, set shipping address to somewhere in California; 5. finish payment. Issue ----- The new partner is created with its state set to Cadiz instead of California. Cause ----- When searching for a state using its code, it fetches the first matching item. The problem is that unlike country codes, state codes ar
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Stripe Express Checkout; 2. go to eCommerce as Public User; 3. pay via express checkout for a deliverable item; 4. in Stripe, set shipping address to somewhere in California; 5. finish payment. Issue ----- The new partner is created with its state set to Cadiz instead of California. Cause ----- When searching for a state using its code, it fetches the first matching item. The problem is that unlike country codes, state codes aren't unique, e.g. there are 4 states that match the 'CA' code (only one of them being in the United States). Solution -------- Add `country_id` to the search domain to ensure the fetched state belongs to the relevant country. opw-4396024 Forward-Port-Of: odoo/odoo#196763 Forward-Port-Of: odoo/odoo#196428
7 changes
Miscellaneous changes
**Steps to reproduce:** Use a Colombian company. Configure DIAN / Carvajal (company, product, and supplier) as per documentation. Change the language to Spanish (LATAM). Create a new Purchase Order using the supplier and the product: - Receive the product. - Create the Vendor Bill: - Change the Journal to the DIAN Support Documents journal and set the date. - Using the actions, print the invoice (even without payment) and look at the document title. [](https://github.com/user-attachments/files/18359586/SEDS_2025_01_0014.pdf) - Create a Credit Note: - Using the actions, print the credit note (even without payment) and look at the document title. [](https://github.com/user-attachments/files/18359584/RSEDS_2025_01_0009.pdf) --- **Issue:** DIAN vendor bills and vendor credit notes display `Factura de proveedor` and `Nota de crédito de proveedor`. --- **Expected:** DIAN vendor bills and vendor credit notes should display `Documento Soporte` and `Nota de Ajuste del Documento Soporte`. --- **Cause:** Vendor bills and credit notes are not managed by Colombian's EDI nor DIAN modules but only by the Account module. --- **Fix:** Add DIAN-specific `Vendor Bill` and `Vendor Credit Note` translations. Manage the title replacement in the generated file if the PDF generation is done by the DIAN module. [](https://github.com/user-attachments/files/18359493/SEDS_2025_01_0013.pdf) [](https://github.com/user-attachments/files/18359499/RSEDS_2025_01_0008.pdf) --- **Task References:** opw-4423439 opw-4433918 Forward-Port-Of: odoo/enterprise#78819 Forward-Port-Of: odoo/enterprise#76793
Before this commit, In kanban view when selecting multiple documents while holding shift as modifier, it could happen that folders were selected too. This was due to the logic which was using document ids as the range value when looping on `root.records` but with the new UI where the folders are now displayed on top of the documents it was buggy. In list view, we would like to keep the same behavior as in other list views. This commit fixes those issues. Task-4532046 Forward-Port-Of: o
Original PR description
Before this commit, In kanban view when selecting multiple documents while holding shift as modifier, it could happen that folders were selected too. This was due to the logic which was using document ids as the range value when looping on `root.records` but with the new UI where the folders are now displayed on top of the documents it was buggy. In list view, we would like to keep the same behavior as in other list views. This commit fixes those issues. Task-4532046 Forward-Port-Of: odoo/enterprise#78196
Forward-Port-Of: odoo/enterprise#78842
Original PR description
Forward-Port-Of: odoo/enterprise#78842
In 18.0, we dropped the support for the round per line rounding method in Mexico. However, we didn't think about the following scenario: - a user creates an invoice in 17.0 in round-per-line mode, and sends it to the Mexican government without problem - they then upgrade to 18.0 - a while later, they receive payment for the invoice. They then try to send the payment CFDI to the Mexican government. The payment CFDI is a complicated beast because it needs to retrieve values from the i
Original PR description
In 18.0, we dropped the support for the round per line rounding method in Mexico. However, we didn't think about the following scenario: - a user creates an invoice in 17.0 in round-per-line mode,…
In 18.0, we dropped the support for the round per line rounding method in Mexico. However, we didn't think about the following scenario: - a user creates an invoice in 17.0 in round-per-line mode, and sends it to the Mexican government without problem - they then upgrade to 18.0 - a while later, they receive payment for the invoice. They then try to send the payment CFDI to the Mexican government. The payment CFDI is a complicated beast because it needs to retrieve values from the invoice the payment was reconciled with. Since the amounts in the invoice are slightly different from what they should be in round globally, the payment CFDI gets incorrectly generated and gets rejected by the Mexican government. So we need a temporary fix that allows the values of the payment CFDI to be adjusted according to the values of the invoice, which works even if the invoice used round per line. This fix is inspired by the existing solution in version 17: https://github.com/odoo/enterprise/pull/68319 and ensures that the "importe" amount is properly calculated. opw-4537931 opw-4536649 opw-4528785 opw-4490806 Forward-Port-Of: odoo/enterprise#78674
Version - 18.0 Problem - The translation button in the studio reports is hidden/ not accessible to the customer Steps to reproduce- Open Sales app > Go to the Studio view > Select Reports from the menu > Open any report among the listed ones On the left hand side - in the studio editor select "Edit Source" On the Edit source file - In the initial version there used to be an EN (Translation button) for them to translate the display field names opw-4417402 Forward-Port-Of: odoo/enterprise
Original PR description
Version - 18.0 Problem - The translation button in the studio reports is hidden/ not accessible to the customer Steps to reproduce- Open Sales app > Go to the Studio view > Select Reports from the menu > Open any report among the listed ones On the left hand side - in the studio editor select "Edit Source" On the Edit source file - In the initial version there used to be an EN (Translation button) for them to translate the display field names opw-4417402 Forward-Port-Of: odoo/enterprise#78462
HTML content is often saved as XML (i.e. through templates) and saved as such in the database. This introduces issues when elements are written under their `self-closing` format (i.e. `<a/>` or `<br/>`) as browsers will incorrectly parse these values as HTML by adding a closing tag at an arbitrary position which may modify the initial nodes configuration. This can be prevented by post-processing untrusted content before the html parsing. Check this commit community counterparts, which place t
Original PR description
HTML content is often saved as XML (i.e. through templates) and saved as such in the database. This introduces issues when elements are written under their `self-closing` format (i.e. `<a/>` or `<br/>`) as browsers will incorrectly parse these values as HTML by adding a closing tag at an arbitrary position which may modify the initial nodes configuration. This can be prevented by post-processing untrusted content before the html parsing. Check this commit community counterparts, which place the conversion responsibility in the `html_viewer` instead of the `html_upgrade_manager`. task-4547973 Forward-Port-Of: odoo/enterprise#78532
The issue occurs because the query does not apply an offset or limit, causing the same lines to be loaded repeatedly. This results in duplicate keys on the client side. To fix this, we add a query tail and mimic the ordering of account_move_line, ensuring consistency when loading additional lines. This fix is related to an earlier patch in older versions, but due to the refactoring of the Intrastat report, it had to be implemented differently. Old Fix: https://github.com/odoo/enterprise
Original PR description
The issue occurs because the query does not apply an offset or limit, causing the same lines to be loaded repeatedly. This results in duplicate keys on the client side. To fix this, we add a query tail and mimic the ordering of account_move_line, ensuring consistency when loading additional lines. This fix is related to an earlier patch in older versions, but due to the refactoring of the Intrastat report, it had to be implemented differently. Old Fix: https://github.com/odoo/enterprise/pull/76543 Forward-Port-Of: odoo/enterprise#78743 Forward-Port-Of: odoo/enterprise#78628
19 changes
Resolved issues and error corrections
Fixed an issue in Restaurant Point of Sale where sending an order to preparation could print an extra blank receipt when multiple preparation printers were configured by product category. Restaurants now receive only the relevant preparation ticket, reducing paper waste and staff confusion.
Original PR description
When creating multiple preparation printers for different pos categories you could have a case where an empty receipt is printed. Steps to reproduce: ------------------- * Create 2 PoS categories CAT 1 and CAT 2 * Create a first preparation printer for CAT 2 * Create a second preparation printer for CAT 1 * Create a product P1 for CAT 1 * Assign the two printers to a PoS * Open PoS and add the P1 to your order * Send the order in preparation > Observation: Two receipts are printed and one of them is empty Why the fix: ------------ When going over each printer to print the relevant changes, if the first printer in the list has no changes it would always print an empty receipt because `last_preparation_change` would always be empty. To fix this we rely on `changes` to check if there are any changes to print on this printer opw-4462586
This fix makes the lot and serial number dropdown visible in the Point of Sale interface on smaller screens. It helps cashiers correctly select tracked products when using compact devices or reduced screen sizes.
Original PR description
Before this commit: == - Lot-serial dropdown not visible in the small UI. After this commit: == - Displayed the lot-serial dropdown in the small UI. opw-4551161 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Users can now duplicate more than one Server Action at a time without encountering an error. This removes a small workflow interruption for administrators managing automated actions.
Original PR description
This error occurs when attempting to duplicate two actions in ``Server Actions``. Steps to reproduce: --- - Search ``Server Actions`` - Select any two Actions and ``Duplicate`` Traceback: --- ``ValueError: Expected singleton: ir.actions.server(606, 701)`` After this commit: --- We are now able to duplicate multiple records. sentry-6218495006 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The file upload notification in the HTML editor now shows its close button in the expected position on the right. This makes the upload message easier to understand and dismiss, avoiding a small but visible user interface issue.
Original PR description
**Problem**: The close icon on the file upload notification is misplaced, appearing at the top-left instead of the expected position on the right. Before fix:  After fix:  **Solution**: Adjust the button's position to appear on the right side of the notification. **Steps to Reproduce**: 1. Open the Editor. 2. Upload a file. 3. Observe that the close button appears on the top-left instead of the right. opw-4512322 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes several wording and translation issues in the Documents app, especially around access settings and member invitations. Users in translated interfaces should see clearer, more consistent labels and messages, reducing confusion when managing documents and permissions.
Original PR description
[task-4421055](https://www.odoo.com/odoo/project.task/4421055)
Belgian and Swiss payroll modules were updated so their text can be properly translated. This helps companies using these payroll features provide a clearer localized experience for employees and payroll teams.
Original PR description
TaskID: 4558967
Australian payroll now keeps a default Medicare reduction value when employee records are edited or created during upgrades. This prevents errors in tax treatment code calculation and helps payroll records remain usable.
Original PR description
It is possible for a user to empty the value for `l10n_au_medicare_reduction` from an employee's form. Since this field is used in the computation of `l10n_au_tax_treatment_code`, doing so will trigger an error:
```
File "/home/odoo/src/enterprise/18.0/l10n_au_hr_payroll/models/hr_employee.py", line 347, in _compute_l10n_au_tax_treatment_code
code += rec.l10n_au_medicare_reduction # Sixth Character
TypeError: can only concatenate str (not "bool") to str
```
This error can also happen during upgrades, when employee records are created before the module `l10n_au_hr_payroll` is loaded.This update adds missing automated checks for Italian point-of-sale tax totals. It helps ensure receipts and tax summaries remain accurate, reducing the risk of unnoticed issues in future changes.
The salary offer screen now shows final yearly cost information more clearly, helping HR teams and candidates better understand the full annual impact of an offer. This prevents confusion during contract salary discussions and supports more transparent compensation decisions.
Original PR description
TaskID: 4558836
Miscellaneous changes
This pull request does not include enough detail about the affected files or intended behavior to identify a specific business impact. Based on the provided information, it appears to be a miscellaneous update with no clear user-facing scope.
Original PR description
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
Before this commit, if a many2one field was loaded with its data, it would not get connected. For example, in the Chilean localization, the account_move is loaded when capturing an order, but it would not get linked, causing an error. opw-4479284 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193616
Original PR description
Before this commit, if a many2one field was loaded with its data, it would not get connected. For example, in the Chilean localization, the account_move is loaded when capturing an order, but it would not get linked, causing an error. opw-4479284 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#193616
Before this commit, the credit note's tax lines were causing an issue during reconciliation because they were reconciled with both the invoice and with the cash basis entry. Reproduce: * Enable cash basis accounting. * On the tax that will be used, set: Tax Exigibility: Based on Payment. * Allow reconciliation on the associated account. * Add a product without tax and save. * Then, add a tax. * Try to create and post a credit note for this invoice Forward-Port-Of: odoo/odoo#192586
Original PR description
Before this commit, the credit note's tax lines were causing an issue during reconciliation because they were reconciled with both the invoice and with the cash basis entry. Reproduce: * Enable cash basis accounting. * On the tax that will be used, set: Tax Exigibility: Based on Payment. * Allow reconciliation on the associated account. * Add a product without tax and save. * Then, add a tax. * Try to create and post a credit note for this invoice Forward-Port-Of: odoo/odoo#192586
The base.group_user did not have the access right to read overtime_id, which is necessary for filtering allocations that do not have a null overtime_id. The access right was granted to base.group_user only when the allocation state is either draft or confirm. task-4452360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196650 Forward-Port-Of: odoo/odoo#193797
Original PR description
The base.group_user did not have the access right to read overtime_id, which is necessary for filtering allocations that do not have a null overtime_id. The access right was granted to base.group_user only when the allocation state is either draft or confirm. task-4452360 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196650 Forward-Port-Of: odoo/odoo#193797
In [1] the `params` section was refactored, but removing the `]` was missed. This caused an error, always returning "No encontrado". [1] https://github.com/odoo/enterprise/commit/14c1b2f8b36ade09be021d2ae202da19f88c0b78 Forward-Port-Of: odoo/enterprise#78891
Original PR description
In [1] the `params` section was refactored, but removing the `]` was missed. This caused an error, always returning "No encontrado". [1] https://github.com/odoo/enterprise/commit/14c1b2f8b36ade09be021d2ae202da19f88c0b78 Forward-Port-Of: odoo/enterprise#78891
When updating the module, the bank data is reloaded. When the account is already trusted (`allow_out_payment == True`), the write fails due to checks to prevent fraud. To fix this, we wrap the data in a `noupdate` to prevent further writes from happening. If ever the account number changes, a new record will be created instead of updating the existing one. Since this account is the default one stipulated on the official fps site, it can be trusted by default. Issue reported by upgrade team
Original PR description
When updating the module, the bank data is reloaded. When the account is already trusted (`allow_out_payment == True`), the write fails due to checks to prevent fraud. To fix this, we wrap the data in a `noupdate` to prevent further writes from happening. If ever the account number changes, a new record will be created instead of updating the existing one. Since this account is the default one stipulated on the official fps site, it can be trusted by default. Issue reported by upgrade team. Forward-Port-Of: odoo/enterprise#78760
**Steps to reproduce:** Use a Colombian company. Configure DIAN / Carvajal (company, product, and supplier) as per documentation. Change the language to Spanish (LATAM). Create a new Purchase Order using the supplier and the product: - Receive the product. - Create the Vendor Bill: - Change the Journal to the DIAN Support Documents journal and set the date. - Using the actions, print the invoice (even without payment) and look at the document title. [](https://github.com/user-attachments/files/18359586/SEDS_2025_01_0014.pdf) - Create a Credit Note: - Using the actions, print the credit note (even without payment) and look at the document title. [](https://github.com/user-attachments/files/18359584/RSEDS_2025_01_0009.pdf) --- **Issue:** DIAN vendor bills and vendor credit notes display `Factura de proveedor` and `Nota de crédito de proveedor`. --- **Expected:** DIAN vendor bills and vendor credit notes should display `Documento Soporte` and `Nota de Ajuste del Documento Soporte`. --- **Cause:** Vendor bills and credit notes are not managed by Colombian's EDI nor DIAN modules but only by the Account module. --- **Fix:** Add DIAN-specific `Vendor Bill` and `Vendor Credit Note` translations. Manage the title replacement in the generated file if the PDF generation is done by the DIAN module. [](https://github.com/user-attachments/files/18359493/SEDS_2025_01_0013.pdf) [](https://github.com/user-attachments/files/18359499/RSEDS_2025_01_0008.pdf) --- **Task References:** opw-4423439 opw-4433918 Forward-Port-Of: odoo/enterprise#76793
## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the `commercial_partner_id` of `self`. This works well for form views, where `self` is a singleton. However, since the field `product_id` is present in the list view, which has a domain depending on `suitable_product_ids`, the computation is triggered for all tickets in the list view, making `self` not a sing
Original PR description
## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the…
## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the `commercial_partner_id` of `self`. This works well for form views, where `self` is a singleton. However, since the field `product_id` is present in the list view, which has a domain depending on `suitable_product_ids`, the computation is triggered for all tickets in the list view, making `self` not a singleton. This causes the set of suitable partners to be larger than necessary, as it becomes the collective set for *all* tickets referenced in `self`, leading to false positives where products associated with a specific partner's sales/delivery history might appear suitable for another ticket with a different partner. To address this, we split `self` by `commercial_partner`, as the set of products that could be suitable depends on the partner's sales/delivery history, not on individual tickets. ## Reference opw-4444078 Forward-Port-Of: odoo/enterprise#78765 Forward-Port-Of: odoo/enterprise#78087
### Before this commit: Clicking on a budgetary position opened the list view showing all budget lines, regardless of the selected budgetary position. ### After this commit: Now, clicking on a budgetary position will open the list view filtered to show only the budget lines associated with that specific budgetary position. ### Technical: In `doActionButton`, we use the `args` if the action type is object. so, `domain` is irrelevant in this context. **task-4195738** Forward-Port-Of:
Original PR description
### Before this commit: Clicking on a budgetary position opened the list view showing all budget lines, regardless of the selected budgetary position. ### After this commit: Now, clicking on a budgetary position will open the list view filtered to show only the budget lines associated with that specific budgetary position. ### Technical: In `doActionButton`, we use the `args` if the action type is object. so, `domain` is irrelevant in this context. **task-4195738** Forward-Port-Of: odoo/enterprise#78708 Forward-Port-Of: odoo/enterprise#73785
Versions -------- - 17.0+ Steps ----- 1. Use Belgian localization; 2. create an invoice for a Belgian customer; 3. pay the invoice using SEPA Direct Debit; 4. go to Accounting / Bank; 5. create a bank statement matching the SDD mandate details; 6. go to payment transactions linked to the invoice. Issue ----- The transaction is still pending, and the SDD Mandate hasn't been confirmed. Cause ----- When matching transactions to bank statement lines, it checks whether `tx.refer
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Use Belgian localization; 2. create an invoice for a Belgian customer; 3. pay the invoice using SEPA Direct Debit; 4. go to Accounting / Bank; 5. create a bank statement matching the SDD mandate details; 6. go to payment transactions linked to the invoice. Issue ----- The transaction is still pending, and the SDD Mandate hasn't been confirmed. Cause ----- When matching transactions to bank statement lines, it checks whether `tx.reference == line.payment_ref`. The `tx.reference` is based on the invoice name, whereas `payment_ref` depends on localization, with Belgian payment request being structured as `+++000/0000/12345+++`. Solution -------- When creating a SDD mandate transactions, display `tx.reference` as payment communication. opw-4380832 Forward-Port-Of: odoo/enterprise#78413