Friday, March 21, 2025
43 changes · 18.0
New functionality added to Odoo
Spanish localization now includes dedicated Canary Islands accounting templates, tax settings, and the Modelo 420 tax report. This helps companies operating in the Canary Islands apply the correct regional accounting and tax rules more automatically.
Original PR description
This commit adds Canary Island CoA from OCA's l10n_es_igic module.
The initial migration was done using the script from: `https://github.com/william-andre/transform_coa`
Along that, we also applied few more things:
- use the english translations in `name` and moved the spanish names in `name@es`
- added auto-apply on canary's fiscal position based on zip codes
- adapt `-100` taxes on some of the taxes in canary
- refactored the template flow
From now on, the flow of the template dependencies will be like the following:
```
es_canary_common es_common_mainland
| |
(canary-assoc/full/pymes) (assec/full/pymes/coop_pymes)
```
task-id: 3354514
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-prEnhancements to existing features
Opening the vendor bills list is now much faster when Odoo checks for possible duplicate bill references. This reduces waiting time for accounting teams, especially on large databases with many bills.
Original PR description
Description: ------------ Following commit 4e7b5e44b292dc41217e4c50048b8bb8408246f5, the list view for bills now shows a colored highlight on the bill's reference if there is a potential duplicate, and the matching on the invoice date was relaxed to include potential bills from the same year. This caused a performance regression, as the index on `invoice_date` could no longer be used since the year is now extracted from it. This patch adds a partial 'btree' index on the `ref` field specifically for bills, as it is the most discriminatory factor when identifying potential duplicates. Benchmark: ---------- On a database with 6M `account_move` records, 230k of which are `'in_invoice'` & `'in_refund'`, `_fetch_duplicate_reference`, triggered when opening the list view of bills, took: | Before | After | Speedup | |--------|-------|---------| | 19.8s | 20ms | 990x | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Resolved issues and error corrections
This fixes a visual issue in the Discuss sidebar where pinned thread entries were all treated as the first item in the list. The change restores the intended styling so users can scan pinned conversations more clearly.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/200310 PR above made a small typo: it removed `isCategoryOpen` which was alias for `thread.discussAppCategory.open` in template, but this was still mistakenly used in the `isFirst` props of a sub-thread template. As a result, the list of pinned thread was not shown correctly, as all items we wrongly flagged as the first item. Before / After  
Miscellaneous changes
This reverts commit 43041dfd66e984978ad743c4f720e580f82bd1aa. It looks like Google and Microsoft flag custom headers as Spam. opw-4439329 opw-4458057 opw-4471333 opw-4492740 opw-4501103 opw-4503823 opw-4507802 opw-4517232 opw-4523135 opw-4529415 opw-4547995 opw-4556927 opw-4557754 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 a
Original PR description
This reverts commit 43041dfd66e984978ad743c4f720e580f82bd1aa. It looks like Google and Microsoft flag custom headers as Spam. opw-4439329 opw-4458057 opw-4471333 opw-4492740 opw-4501103 opw-4503823 opw-4507802 opw-4517232 opw-4523135 opw-4529415 opw-4547995 opw-4556927 opw-4557754 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 Forward-Port-Of: odoo/odoo#202812 Forward-Port-Of: odoo/odoo#200193
This update improves Odoo's internal Hoot testing framework and related unit tests, making test results clearer and reducing cases where tests are accidentally skipped or behave inconsistently. These changes are limited to the test ecosystem, helping developers maintain quality without affecting normal business operations.
Original PR description
## Pull Request HOOT (PRHOOT) 29 This pull requests brings various improvements and fixes to Hoot and the Odoo unit test ecosystem. See the different commit messages for more details. Note: these changes are made in stable to avoid having to support multiple versions of the HOOT API. As such, these changes are intended to be strictly limited to unit tests as to not put the rest of the code base at risk. Enterprise: https://github.com/odoo/enterprise/pull/81834 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Product and combo configurator cards now show larger, clearer images and cleaner attribute details. The layout is also adjusted for smaller screens, making product selection easier for customers on mobile devices.
Original PR description
Increase image size from 128 to 256 for combo items in the configurator opw-4630831 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The website editor now shows the Donation Button preview correctly while it is being dragged. This prevents extra prefilled donation buttons from appearing in the drag preview, making the editing experience clearer and less confusing.
Original PR description
**[FIX] website_payment: fix donation button preview on drag** Steps to reproduce: - Enter edit mode. - If not already installed, click the "Donation Button" in the snippet menu to install the "website_payment" app. - Start dragging the "Donation Button" without dropping it onto the page to display its preview. - Bug: Prefilled buttons are displayed in the preview when they shouldn't be. This bug was introduced by commit [1], where the prefilled buttons were added to the "s_donation" snippet template so that they would be visible in the "s_donation" preview in the snippets dialog. Unfortunately, this change also made them visible for the inner "Donation Button" snippet, which shouldn't be the case. [1]: https://github.com/odoo/odoo/commit/edf81c13d8f2f6d29a77d68cbfa0dc9216da3c2a
This fixes an error that occurred when selling a physical gift card in Point of Sale after removing the expiration date. Staff can now create valid physical gift cards with no expiry date, avoiding checkout interruptions.
Original PR description
Creating a physical gift card in the PoS without an expiration date led to an Odoo error.
Steps to reproduce:
-------------------
* Open a PoS
* Add a gift card
* Click on Sell physical gift card?
* Input a unique code and a value
* Remove the default expiration date
* Click on Add Balance
> Observation:
TypeError: value.toFormat is not a function
at serializeDate
Why the fix:
------------
the addBalance() method was trying to format the expiration date with serializeDate(this.state.expirationDate) without verrifing that it exists.
opw-4623141
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prOn mobile devices, pressing Enter in Discuss now creates a new line instead of sending the message. This prevents accidental message sending and makes writing multi-line messages possible for mobile users.
Original PR description
The composer should not send the current input on Enter key when being on a mobile device, since it is impossible for them to create a new line with either ctrl-Enter or alt-enter. [FIX] mail: Discuss on Mobile - Enter key behavior The composer should not send the current input on Enter key when being on a mobile device, since it is impossible for them to create a new line with either ctrl-Enter or alt-enter. Task-4209142
This update fixes an automated sales test so it confirms a quotation using the visible confirmation button instead of relying on a navigation shortcut that is unavailable in the test flow. This improves reliability of the test coverage for quotation handling without changing day-to-day user behavior.
Original PR description
Follow-up of https://github.com/odoo/odoo/pull/194593 This PR added test coverage for the fix, but it failed at the last step '.o_menu_brand' to confirm the quotation. The intent is to save to quotation, but it relies on implicit action to quit (and save) the record from the app icon, which acts as a "go to main page of app". This button is not present in tours for some reasons, hence the step failing. This commit fixes it by manually confirming the quotation by clicking on the dedicated button, which is present in practice and in the tour. runbot-161274 In practice  In tour <img width="558" alt="Screenshot 2025-03-21 at 11 13 11" src="https://github.com/user-attachments/assets/8013a70a-0a0a-4a73-8820-d49678af84a5" />
The eCommerce product combo configurator no longer shows internal product reference codes to website visitors. This keeps backend-only information out of the storefront and presents a cleaner shopping experience.
Original PR description
This reference should only be shown in the backend.
Mobile sales order entry now includes the required price information to calculate quantity-based discounts correctly. This ensures customers using mobile views see the expected discounted unit price when order quantities meet pricelist rules.
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Create a pricelist with any discount on all products with a minimum quantity of 5; 2. Create a new sale order in mobile view; 3. Create a new sale order line, select any product and set a quantity higher than 5. Issue ----- The price unit isn't discounted as expected. Cause ----- `_compute_price_unit` needs `technical_price_unit` which is missing from the mobile view. Solution -------- Add `technical_price_unit` to mobile sale order views. opw-4569731 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
Canceled order lines in Point of Sale are now included on preparation tickets. This helps kitchen or preparation teams see cancellations clearly and avoid preparing items that customers no longer want.
Original PR description
- Fix issue where canceled orderlines were not printed on the preparation ticket. task-id: 4663618 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Rental orders for kit-based products can now be picked up without incorrectly trying to update stock for the kit itself. This prevents a blocking error and ensures the system handles the kit's components as expected during rental pickup.
Original PR description
Steps to reproduce the bug:
- Create a storable product “P1”:
- Can be rented: True
- tracked by quantity
- BoM:
- type: kit
- component: C1
- Create a rental order with one unit of P1
- confirm it
- Click on pickup:
- validate the wizard
Problem:
A user error is triggered:
"You should update the components' quantity instead of directly updating the quantity of the kit product."
This happens because the system attempts to update the available quantity of the kit product in the quants.
opw-4572337Draft invoice PDFs now show only the draft invoice label instead of including a temporary placeholder invoice number. This prevents customers or staff from seeing misleading invoice numbers before an invoice is finalized.
Original PR description
### Steps to reproduce: - Create a new draft invoice - In the actions click "PDF without Payment" - In the PDF the name is "Draft Invoice INV/2023/0001" - It should only be "Draft Invoice" ### Cause: "INV/2023/0001" is the placeholders in the XML. It is displayed because the name for draft moves is no longer '/' but null. ### Solution: Change the condition to also check if `o.name` exists. opw-4607518
This fixes a point of sale issue where a global discount could remain in the order even after all products were removed. It prevents customers from checking out a cart that contains only a discount, improving order accuracy and reducing payment mistakes.
Original PR description
## Current behavior before PR: The global discount (if configured) in the POS module persist in the order line (summary order) even when there is no product present in it. ## Steps to reproduce / Description of the issue feature this PR addresses: - Install `POS` module - Go to `POS` -> `Configuration` -> `Settings` - Search for `Global Discount` check the tick mark and save it - Open that particular shop for which Global Discount is configured - Add some products to the cart - Apply Global Discount to the order(`Actions` -> `Discount`) - Remove all the products from the cart except the discount and then checkout that cart, it will let you do the payment. ## Desired behavior after PR is merged: If global discount is applied to the cart and if user removes the product then discount order line won't persist anymore. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Gift card activity is now recorded correctly when a card is used in a point-of-sale order. This helps businesses keep accurate customer loyalty and gift card records, reducing confusion during balance checks or customer service follow-up.
Original PR description
Loyalty history for gift cards was not working properly. The history was not being updated when a gift card was used in a POS order. Steps to reproduce: ------------------- * Create some gift cards * Use one in the PoS to make an order > Observation: The history is not updated accordingly Why the fix: ------------ Instead of relying only on `coupon_updates` we check that card id provided exist before creating the history record. opw-4546985-1
Italian e-invoice XML exports now convert unit prices into the company currency when invoices are issued in a foreign currency. This keeps unit prices aligned with total prices and avoids incorrect electronic invoice values for Italian companies.
Original PR description
Requirements: l10n_it_edi, IT company - Change the exchange rate between EUR and USD (or any foreign currency) to 2. - Create an invoice in USD with one product priced at 100, then generate the XML.…
Requirements: l10n_it_edi, IT company - Change the exchange rate between EUR and USD (or any foreign currency) to 2. - Create an invoice in USD with one product priced at 100, then generate the XML. In the XML, PrezzoUnitario (price unit) is not equal to PrezzoTotale (price total), even though there is only one quantity. When using a currency other than the company currency, PrezzoUnitario is in the foreign currency (here, USD). Both PrezzoTotale and PrezzoUnitario should be in the company currency. The test test_export_foreign_currency xml has also been updated to reflect recent changes. Specifically, in the XML export: - The price unit is recorded as 1068.11(USD). - To total price is recorded as 841.49(EUR) which was converted from 907.49(USD). - Knowing there is a 15% discount, the correct unit price should be 841.49(EUR) / 0.85 = 990(EUR) (similar logic to justify changing the other xml) opw-4593300 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When a bank statement line is disconnected from an invoice, Odoo now correctly resets the related payment status instead of leaving it marked as paid. This helps accounting teams avoid misleading payment records after reconciliation changes.
Original PR description
Before this commit, when doing the reconciliation of a statement line with an invoice without a journal entry, we were trying to find a matching payment for that statement line and setting it as paid. However, it didn't do the opposite when breaking the matching between the invoice and the statement line. This commit adds that opposite behavior.
This fixes sale orders so global or fixed discount lines are automatically removed when all product lines are deleted. It prevents leftover discounts from remaining on empty orders, keeping order totals and records cleaner for sales teams.
Original PR description
## Description of the issue/feature this PR addresses: Ensured that the discount line is removed when all products are deleted from the sale order. ## Current behavior before PR: have a look at [this](https://excalidraw.com/#json=FsEs8xRNq5druyUCVA0yF,8aHZoS4w1p8SWKRPr4WPEQ) ## Desired behavior after PR is merged: Discount(Global/Fixed) lines will be deleted if there are no products in the order line --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The system automatically fill the Bank Account info on invoices, however this does not work as expected when the move type is changed after creation Steps to reproduce: - Create an invoice, set partner with bank account defined - Switch to credit note - Check 'Other info' tab Issue: Bank Partner will be left blank, but it should be the partner bank account opw-4640629 Forward-Port-Of: odoo/odoo#202369
Original PR description
The system automatically fill the Bank Account info on invoices, however this does not work as expected when the move type is changed after creation Steps to reproduce: - Create an invoice, set partner with bank account defined - Switch to credit note - Check 'Other info' tab Issue: Bank Partner will be left blank, but it should be the partner bank account opw-4640629 Forward-Port-Of: odoo/odoo#202369
**Steps to reproduce:** - Install Accounting and l10n_sa_edi - Switch to a Saudi Arabian company (e.g. SA Company) - Duplicate "Customer Invoices" journal: * Default Income Account: 500001 Sales Account * Electronic invoicing: [disabled] - Create a retention tax: * Name: Retention 10% * Amount: -10.00000% * Is Retention: [checked] - Create an invoice: * Customer: [a Saudi Arabian contact] (e.g. ARAMCO Medinah Branch) * Journal: Customer Invoices * Invoice Lines:
Original PR description
**Steps to reproduce:** - Install Accounting and l10n_sa_edi - Switch to a Saudi Arabian company (e.g. SA Company) - Duplicate "Customer Invoices" journal: * Default Income Account: 500001 Sales…
**Steps to reproduce:**
- Install Accounting and l10n_sa_edi
- Switch to a Saudi Arabian company (e.g. SA Company)
- Duplicate "Customer Invoices" journal:
* Default Income Account: 500001 Sales Account
* Electronic invoicing: [disabled]
- Create a retention tax:
* Name: Retention 10%
* Amount: -10.00000%
* Is Retention: [checked]
- Create an invoice:
* Customer: [a Saudi Arabian contact] (e.g. ARAMCO Medinah Branch)
* Journal: Customer Invoices
* Invoice Lines:
- Price: 100.00
- Taxes: "Sales Tax 15%" + "Retention 10%"
- Confirm the invoice
- Print the invoice
- Scan the QR code on the invoice with an app like "E-invoice QR Reader"
=> In the QR code, the total amount of the invoice with VAT included is 115.00 and the total amount of the VAT is 15.00.
The amount of the retention tax is excluded from the total and the VAT amounts, which is the expected behavior.
- Create the exact same invoice with the duplicated journal without electronic invoicing
- Confirm the invoice
- Print the invoice
- Scan the QR code on the invoice
**Issue:**
In the QR code, the amount of the retention (-10.00) is taken into account.
The total amount of the invoice with VAT included is 105.00 and the total amount of the VAT is 5.00.
The QR code should provide the same amounts either the used journal has "Electronic invoicing" enabled or not.
**Cause:**
Depending on the presence of an electronic invoice document or not, the QR code is generated by the overriding compute method from "l10_sa_edi" or the original one in "l10n_sa".
However, the "Is Retention" field of the "account.tax" model is introduced by "l10n_sa_edi" module and when the QR code is computed by the original method, this field is not taken into account and the corresponding retention tax is wrongly handled like any other tax.
**Solution:**
Use the same total amounts than the ones computed in "l10n_sa_edi" (where retention tax are excluded) in the original compute method if "l10n_sa_edi" is installed.
**Issue 2:** (revealed by the fix)
In "_get_invoice_line_allowance_vals_list" method, a variable can be used without being assigned (i.e. "fixed_tax_charge_vals_list").
opw-4525519
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#196640If the target url had duplicate keys in its query params, the redirect url would only contain the key-value pair corresponding to the first occurrence of the key. This is incorrect, as a shop url typically contains multiple attribute values in its query params. The issue was caused by an accidental cast from MultiDict to Dict when handling the query params. opw-4466925 Forward-Port-Of: odoo/odoo#202744 Forward-Port-Of: odoo/odoo#199570
Original PR description
If the target url had duplicate keys in its query params, the redirect url would only contain the key-value pair corresponding to the first occurrence of the key. This is incorrect, as a shop url typically contains multiple attribute values in its query params. The issue was caused by an accidental cast from MultiDict to Dict when handling the query params. opw-4466925 Forward-Port-Of: odoo/odoo#202744 Forward-Port-Of: odoo/odoo#199570
Issue ===== When product's code is computed, which is depend of the product's suppliers since each supplier can have a specific code, the first supplier is taken regardless if this supplier info is specific to another product variant which can cause to use the wrong code if there is multiple supplier with the same vendor but for different variants of the same product template. How to reproduce ================ 1. Install Puchase and Barcode; 2. Create a product with at least 2 variants;
Original PR description
Issue ===== When product's code is computed, which is depend of the product's suppliers since each supplier can have a specific code, the first supplier is taken regardless if this supplier info is…
Issue ===== When product's code is computed, which is depend of the product's suppliers since each supplier can have a specific code, the first supplier is taken regardless if this supplier info is specific to another product variant which can cause to use the wrong code if there is multiple supplier with the same vendor but for different variants of the same product template. How to reproduce ================ 1. Install Puchase and Barcode; 2. Create a product with at least 2 variants; 3. In the "Purchase" tab of this product, add two vendor pricelists with the same vendor but each for a different product variant and each with a different code; 4. Go in Purchase, create a new RFQ for this vendor, add a PO line for each variant and confirm the order; 5. Go in Barcode and open the PO's receipt -> You can see both lines have the same vendor's code (from the first pricelist) regardless the pricelist's product variant. Cause of the issue ================== In `_compute_product_code`, it uses the first product (template) supplier info regardless the product variant. Solution ======== In `_compute_product_code`, we skip a supplier info if it concerns another variant, and we break the supplier info loop only if it concerns the current product variant. Miscellaneous ============= The check of the `product.supplierinfo` `read` access right is moved outside of the loop so it is done only one time. [OPW-4589073](https://www.odoo.com/odoo/project/49/tasks/4589073) Forward-Port-Of: odoo/odoo#201900 Forward-Port-Of: odoo/odoo#201753
The aim of this commit is to allow non-users employee to be considered as "forwarding" vendor bills instead of sending it in their name, as the vendor would be the company anyway Steps to reproduce: - Create a fresh db with the mailing aliases setup and employee and account apps installed - Choose a demo data employee that has no user and set the parent_id as the db company. - Make sure the company doesn't have an email set. - Send an email from that employee work_email to the email alias
Original PR description
The aim of this commit is to allow non-users employee to be considered as "forwarding" vendor bills instead of sending it in their name, as the vendor would be the company anyway Steps to reproduce: - Create a fresh db with the mailing aliases setup and employee and account apps installed - Choose a demo data employee that has no user and set the parent_id as the db company. - Make sure the company doesn't have an email set. - Send an email from that employee work_email to the email alias of the Vendor Bills journal. Problem, the created bill has the employee set as the vendor. Expected behavior is that no vendor is set. opw-4516730 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 Forward-Port-Of: odoo/odoo#202667