Daily updates from Odoo
Thursday, May 7, 2026
359 changes
4 changes
Resolved issues and error corrections
This update resolves an issue where a key form element, `.o_input_box`, was removed from the Odoo system. The change adapts the form views for the MRP and POS Self-Order modules to ensure proper functionality and data input. This ensures these features continue to operate as expected.
Original PR description
`.o_input_box` doesn't exist anymore, and this commit adapts the form view accordingly. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update removes unnecessary code that previously handled multiple formats for receiving electronic invoices from Belgium (BE). Previously, the system was unsure which format to use, leading to complexity. Now, the system consistently uses the standard 0208 format, simplifying the process and improving efficiency.
Original PR description
When adding peppol, we didn't know if we needed to use the 9925:BE or 0208. Therefore, we switched between them if the endpoint was not found. This has no more use today as we use 0208. opw-5976574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261307 Forward-Port-Of: odoo/odoo#258297
This update fixes a limitation in how Odoo Enterprise updates its UNSPSC product codes. Previously, new codes required a full module installation, but now an upgrade script automatically adds missing codes to the database during module updates. Existing codes remain unchanged.
Original PR description
**Problem:** Periodically, the UNSPSC codes may be updated and they must be added to existing databases. Normally this is done by module update, however, since there are thousands of UNSPSC codes, a CSV imported via SQL is used instead of XML files. This import is only implemented on module install and not module update, so there is no way to update the UNSPSC codes in existing databases. **Solution:** An upgrade script based on the post-init hook has been added, which will add the new codes to the database, if any. Note that: - The version of this upgrade script should be bumped any time the codes list is updated. - Existing records will not be updated opw-5943366 Forward-Port-Of: odoo/enterprise#116063 Forward-Port-Of: odoo/enterprise#112652
This update fixes an issue where the 'Time Remaining' value in task timesheets was incorrectly highlighted in red, even when the time was positive. The fix ensures the color accurately reflects negative time values, improving the clarity and usability of the timesheet. It also corrects alignment of time remaining on sales orders.
Original PR description
_* = sale_timesheet **Steps to reproduce:** - Open form view of any task. - Go to the Timesheets tab. - Observe the Time Remaining value. - Observe the Time remaining on SO. **Issue:** - The Time Remaining value becomes red even when the value is positive, which incorrectly suggests a warning. - The Time remaining on SO is not properly aligned. **Issue from :** - https://github.com/odoo/odoo/pull/192366 **Fix:** - Adjusted the logic to ensure the Time Remaining value is highlighted in red only when the value is negative. - Positive values now display with normal styling. - Adjusted the logic to ensure Time remaining on SO is displayed properly. **Task-id: 5404009** Forward-Port-Of: odoo/odoo#239610
3 changes
Resolved issues and error corrections
This update fixes a limitation in how Odoo Enterprise updates its UNSPSC product codes. Previously, new codes could only be added during initial module installation. Now, an upgrade script automatically adds any new UNSPSC codes to the database, ensuring the system remains current with industry standards. Existing codes are not modified.
Original PR description
**Problem:** Periodically, the UNSPSC codes may be updated and they must be added to existing databases. Normally this is done by module update, however, since there are thousands of UNSPSC codes, a CSV imported via SQL is used instead of XML files. This import is only implemented on module install and not module update, so there is no way to update the UNSPSC codes in existing databases. **Solution:** An upgrade script based on the post-init hook has been added, which will add the new codes to the database, if any. Note that: - The version of this upgrade script should be bumped any time the codes list is updated. - Existing records will not be updated opw-5943366 Forward-Port-Of: odoo/enterprise#116063 Forward-Port-Of: odoo/enterprise#112652
This update eliminates a misleading warning message that appeared when sequences didn't begin with the number 1. Sequences can legitimately start at any number, and this change ensures users aren't unnecessarily alerted to a standard configuration. It improves the user experience by removing irrelevant notifications.
Original PR description
We don't want to warn users about their sequence not starting at 1 as it is a perfectly valid case. This removes the warning both in the list view and in the dashboard. task-5253768 Forward-Port-Of: odoo/odoo#263117 Forward-Port-Of: odoo/odoo#235117
This update corrects a visual issue where the 'Time Remaining' value in task timesheets was incorrectly highlighted in red, even with positive values. The fix ensures accurate color display based on the actual time remaining, improving the clarity and usability of the timesheet feature. It also addresses alignment problems with time remaining data on sales orders.
Original PR description
_* = sale_timesheet **Steps to reproduce:** - Open form view of any task. - Go to the Timesheets tab. - Observe the Time Remaining value. - Observe the Time remaining on SO. **Issue:** - The Time Remaining value becomes red even when the value is positive, which incorrectly suggests a warning. - The Time remaining on SO is not properly aligned. **Issue from :** - https://github.com/odoo/odoo/pull/192366 **Fix:** - Adjusted the logic to ensure the Time Remaining value is highlighted in red only when the value is negative. - Positive values now display with normal styling. - Adjusted the logic to ensure Time remaining on SO is displayed properly. **Task-id: 5404009** Forward-Port-Of: odoo/odoo#239610
8 changes
New functionality added to Odoo
This update backports a key feature for Poland (l10n_pl_bank_verification) that automatically verifies bank accounts against government APIs. This ensures compliance with Polish regulations and streamlines the process for users adding bank details in the Odoo system. It builds upon previous work tracked in odoo/odoo#250400.
Original PR description
[ADD] l10n_pl_bank_verification: Backport bank account verification Backport of the feature that implements PL Bank Account Verification against the government API See odoo/odoo#250400 task-4637086 Forward-Port-Of: odoo/odoo#262518
Resolved issues and error corrections
This update fixes an issue where child contact zipcodes were incorrectly overriding manually entered zipcodes, even when a parent contact had a defined city and zipcode. The change ensures child contact zipcodes now accurately reflect the parent's city zipcode, improving address consistency and data accuracy.
Original PR description
Currently, when a res.parter is given a parent, base_address_extended runs _onchange_city_id. This sees the city change and alters the zipcode to match the city's zipcode. However, this field can be…
Currently, when a res.parter is given a parent, base_address_extended runs _onchange_city_id. This sees the city change and alters the zipcode to match the city's zipcode. However, this field can be manually altered to differ from the city's zipcode. Thus, when a parent has a city, the zipcode will override the manually entered zipcode for a child contact. This commit solves this by checking for the parent's zipcode before blindly setting it to the city's zipcode. Steps to reproduce: 1. Install `base_address_extended` 2. Enable "Enforce Cities" on a country `(res.country)` 3. Add a city to that country with a zipcode of 123 4. Create a new contact (parent) and select the configured country 5. Select the city (the zipcode will fill in from the city's zipcode) 6. Overwrite the zipcode with 456 7. Save the contact (parent) 8. Create a new contact (child) 9. Set the company to the parent contact and save 10. The zipcode of the child will be the city's zip (123), not the parents' zip (456), thus the addresses will be different, and the child contact type will be 'other' opw-6131280 closes #262651
This update fixes an issue where sales tax reports for 7% and 5% Maltese taxes were incorrectly displayed with negative values and grouped under the 18% line. The fix ensures that all tax reports accurately reflect the correct tax amounts for each invoice, improving the accuracy of financial reporting.
Original PR description
### Issue before this commit: Sales taxes at 7% and 5% were incorrectly mapped to the same tax report tags as the 18% sales taxes, causing them to be reported under the 'Taxable Goods/Services at…
### Issue before this commit: Sales taxes at 7% and 5% were incorrectly mapped to the same tax report tags as the 18% sales taxes, causing them to be reported under the 'Taxable Goods/Services at 18%' line. In addition, the 7% and 5% report lines displayed negative amounts instead of positive ones. ### Steps to reproduce the issue: 1. Install l10n_mt 2. Create invoices using 18%, 7%, 5% taxes 3. Go to Accounting > Reporting > Tax Report 4. See the amounts for Taxable Goods/Services at 18% is negative and all the invoices are reported into the Taxable Goods/Services at 18% even if the tax applied to the invoice is 5% or 7% ### Cause of the issue: An automatic script (https://github.com/odoo/odoo/pull/225252) missed to invert sign of formulas for the 7% and 5% lines, so their values were displayed with the wrong sign. Moreover it is assigned to the 7% and 5% Malta sales taxes the III.1_base and III.1_tax tags, which belong to the 18% tax report line. ### Reason to introduce the fix: The tag mapping must match the tax report structure so that 18%, 7%, and 5% sales taxes are reported in their respective lines. The report formulas for the 7% and 5% lines must also use the proper sign convention to display positive amounts consistently. opw-6015509 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254894
This update ensures that if a Stripe terminal payment capture fails, the payment status in Odoo POS is correctly marked as 'retry' instead of 'done'. Previously, a successful authorization could lead to a misleading 'done' status, hiding payment issues. This prevents inaccurate reporting and ensures payments are properly tracked.
Original PR description
Before this commit, a Stripe terminal payment could still be marked as `done` even if the capture step failed. This happens when the card authorization succeeds, `processPayment` returns a payment…
Before this commit, a Stripe terminal payment could still be marked as `done` even if the capture step failed.
This happens when the card authorization succeeds, `processPayment` returns a payment intent, but the subsequent `stripe_capture_payment` RPC fails and `capturePaymentStripe()` returns `false`. The capture flow did not guard that return value and still fell through to `line.set_payment_status("done")`.
In practice, this can happen for example if the Odoo server cannot resolve `api.stripe.com` while capturing the payment intent. Stripe then keeps the payment in `requires_capture`, while the POS line is still synced as paid.
Guard the failed capture path and stop the flow before marking the line as done. In that case, the payment line is put back to `retry` so the failure is visible in the POS instead of silently creating a paid, uncaptured payment.
opw-6075384
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#261521This update removes a redundant process in our account management system that was previously used to handle electronic invoices from Belgium (BE). Previously, the system was uncertain about which invoice format to use, leading to unnecessary calculations. Now that we consistently use the 0208 format for BE invoices, this fix streamlines the process and improves efficiency.
Original PR description
When adding peppol, we didn't know if we needed to use the 9925:BE or 0208. Therefore, we switched between them if the endpoint was not found. This has no more use today as we use 0208. opw-5976574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261307 Forward-Port-Of: odoo/odoo#258297
This update adds a new upgrade script that automatically adds the latest UNSPSC codes to the Odoo database. Previously, these codes could only be added during initial module installation, creating a delay in updating existing data. This change ensures that Odoo always reflects the most current UNSPSC classifications.
Original PR description
**Problem:** Periodically, the UNSPSC codes may be updated and they must be added to existing databases. Normally this is done by module update, however, since there are thousands of UNSPSC codes, a CSV imported via SQL is used instead of XML files. This import is only implemented on module install and not module update, so there is no way to update the UNSPSC codes in existing databases. **Solution:** An upgrade script based on the post-init hook has been added, which will add the new codes to the database, if any. Note that: - The version of this upgrade script should be bumped any time the codes list is updated. - Existing records will not be updated opw-5943366 Forward-Port-Of: odoo/enterprise#116063 Forward-Port-Of: odoo/enterprise#112652
This update fixes an error in how Odoo calculates product costs when using FIFO stock accounting and lot-based valuation, particularly in complex branch setups. The fix prevents incorrect cost calculations (potentially leading to inflated values) by ensuring the correct lot price is used, improving inventory accuracy.
Original PR description
Databases that are configured to have products be evaluated by lot and FIFO can experience weird behavior when the product's cost or `standard_price` is updated. The current code doesn't account for the fact that we allow users to dip into negative quantities and there aren't enough safeguards against this. This leads to the following bug that I found: The FIFO algorithm can't be calculated when there is no quantity. Odoo uses a fallback cost whenever quantity is less than zero, but this is incorrect when the product is evaluated by lots. Current behavior would calculate the fallback based on the product's standard price instead of the lot's standard price, leading to self-propagating calculation errors (e.g. cost going up to the trillions) Videos of the bug: Bug: ( Lot value defaults back to the product's standard price ) https://drive.google.com/file/d/1gUtjzdLpjeJts8HcxbTZ9MG4bSjRYmeT/view?usp=drive_link Related tickets: opw-6011189 Forward-Port-Of: odoo/odoo#256113
This update enhances the Point of Sale system's ability to track and record errors. By mirroring critical IndexedDB errors to local storage, even if the primary error logging system is temporarily unavailable, important troubleshooting information is preserved. This will help our support team quickly diagnose and resolve issues impacting the POS experience.
Original PR description
Add a `persistToStorage` flag to `logPosMessage` that mirrors critical IndexedDB errors to `localStorage["pos_idb_errors"]` in addition to the posLogger. This ensures error traces are preserved even when the IndexedDB daemon itself is unavailable. opw-6150816 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263093
3 changes
Resolved issues and error corrections
This update resolves an issue where DIAN XML files (AttachedDocument type) were not being imported correctly, leading to data loss. The fix ensures the system correctly identifies and processes these files, aligning with DIAN documentation and allowing for accurate data extraction.
Original PR description
### Issue: Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data This issue only occurs for `AttachedDocument` files According to the DIAN…
### Issue: Some DIAN XML files of type `AttachedDocument` are incorrectly imported, resulting in no extracted data This issue only occurs for `AttachedDocument` files According to the DIAN documentation, the `ProfileID` should contain the literal `Factura Electrónica de Venta` https://www.dian.gov.co/impuestos/factura-electronica/Documents/Anexo-Tecnico-Factura-Electronica-de-Venta-vr-1-9.pdf However, no strict validation is enforced, so variants should still be supported ### Cause: When importing a DIAN document of type `AttachedDocument`, `_get_import_file_type()` searches for a node starting with `DIAN 2.1:` This causes issues with documents structured like: ```xml <AttachedDocument> <CustomizationID>Documentos adjuntos</CustomizationID> <ProfileID>DIAN 2.1: Factura Electrónica de Venta</ProfileID> </AttachedDocument> ``` In this case, `DIAN 2.1:` is detected first, causing the file to be identified as `account.edi.xml.ubl_dian` As a result, the `<AttachedDocument>` wrapper is ignored and the importer tries to parse the file using the wrong structure, preventing any data extraction The import should first detect the `<AttachedDocument>` structure, then unwrap and process the embedded document ### Steps to reproduce: - Install `l10n_co_dian` - Go in Bills and import the test document: `import_attached_document_2` Before the fix, nothing it extracted from the xml opw-6083523
This update fixes a limitation in how Odoo updates its UNSPSC product codes. Previously, new codes could only be added during initial installation, not subsequent updates. A new upgrade script now automatically adds the latest UNSPSC codes to the database, ensuring our product data remains current. Existing product codes are not modified.
Original PR description
**Problem:** Periodically, the UNSPSC codes may be updated and they must be added to existing databases. Normally this is done by module update, however, since there are thousands of UNSPSC codes, a CSV imported via SQL is used instead of XML files. This import is only implemented on module install and not module update, so there is no way to update the UNSPSC codes in existing databases. **Solution:** An upgrade script based on the post-init hook has been added, which will add the new codes to the database, if any. Note that: - The version of this upgrade script should be bumped any time the codes list is updated. - Existing records will not be updated opw-5943366 Forward-Port-Of: odoo/enterprise#116063 Forward-Port-Of: odoo/enterprise#112652
This update resolves an error that occurred when the Account Followup module was installed without the Payment module. The fix prevents a template rendering issue caused by attempting to access a missing 'payment.method' field, ensuring payment reminders function correctly.
Original PR description
Repro steps: 1. Initialize a new DB 2. Install account_followup module without payment module 3. Go to Email templates > Payment reminder 4. Click on Preview You will get an error Failed to render QWeb template for Mail Template: 'Payment Reminder' (ID: 9) Target Model: res.partner Language context: en_US Error: Error while render the template KeyError: 'payment.method' Root cause: The method `_show_pay_now_button` that was being called in the template email_template_followup_1 was using self.env['payment.method'] even tho payment module is not a dependency of account_followup Fix: The introduced fix ensures that 'payment.method' model exists before attempting to use it build_error-243030 Forward-Port-Of: odoo/enterprise#116443 Forward-Port-Of: odoo/enterprise#116079
7 changes
New functionality added to Odoo
This update backports a new feature that allows businesses to automatically verify Polish bank accounts against government data. This improves compliance with local regulations and streamlines the process of onboarding new customers by reducing manual verification efforts. The change was previously developed and tracked in odoo/odoo#250400.
Original PR description
[ADD] l10n_pl_bank_verification: Backport bank account verification Backport of the feature that implements PL Bank Account Verification against the government API See odoo/odoo#250400 task-4637086 Forward-Port-Of: odoo/odoo#262518
Enhancements to existing features
This update ensures Odoo complies with Belgian regulations requiring a legal note on invoices when using the 'Co-Contractant' tax scheme. It adds the necessary fields to capture tax exemption reasons and codes, aligning with legal requirements. This change is important for accurate financial reporting and compliance in Belgium.
Original PR description
It is mandatory in BE to add a legal note on the invoice when using a "Co-Contractant" tax task-5905176 Forward-Port-Of: odoo/odoo#262496 Forward-Port-Of: odoo/odoo#251797
Resolved issues and error corrections
This update corrects a bug where company-owned products weren't visible in the ecommerce shop. The issue stemmed from inconsistent website domain retrieval, leading to incorrect filtering of products based on company ID. By standardizing the website domain, this fix ensures all products, regardless of their ownership, are correctly displayed.
Original PR description
## Description ### Problem [sale_product_domain](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/models/website.py#367-376) uses `self.get_current_website()` for the website domain…
## Description
### Problem
[sale_product_domain](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/models/website.py#367-376) uses `self.get_current_website()` for the website domain
but `self.company_id` for the company domain. This causes two issues:
1. **`company_id` is `False` when called from [models](https://github.com/odoo/odoo/blob/b011c1e3cc4597c713dfe7041c58dc224f8f758d/addons/website_sale/models/product_template.py#L278)**: Methods like
[_get_website_accessory_product](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/models/product_template.py#198-203) and [_get_website_alternative_product](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/models/product_template.py#204-207) call
`self.env['website'].sale_product_domain()` — an empty recordset where
`self.company_id.id` evaluates to `False`. The resulting company domain
[('company_id', 'in', [False, False])](file:///home/imanie/Documents/IRC/18.0/odoo/addons/website_sale/controllers/main.py#757-802) filters out all company-owned
products.
https://github.com/odoo/odoo/blob/b011c1e3cc4597c713dfe7041c58dc224f8f758d/addons/website_sale/models/product_template.py#L279
2. **Inconsistent website references**: Even when `self` is a real website
record, `get_current_website()` could return a different website, leading to
the website domain and company domain referring to different websites.
### Steps to reproduce
1. Add accessory products to a product template
2. Visit the product page on the ecommerce shop
3. Accessory products belonging to the website's company may not appear
### Solution
Store the resolved website in a local variable (`self or self.get_current_website()`),
preferring `self` when it is a real record and falling back to
`get_current_website()` otherwise. Use this single variable for both the website
domain and the company domain.
```diff
def sale_product_domain(self):
- website_domain = self.get_current_website().website_domain()
+ website = self or self.get_current_website()
+ website_domain = website.website_domain()
if not self.env.user._is_internal():
website_domain = expression.AND([website_domain, [
('is_published', '=', True),
('service_tracking', 'in', self.env['product.template']._get_saleable_tracking_types()),
]])
- company_domain = [('company_id', 'in', [False, self.company_id.id])]
+ company_domain = [('company_id', 'in', [False, website.company_id.id])]
return expression.AND([self._product_domain(), website_domain, company_domain])
```
https://github.com/odoo/odoo/pull/260138
Forward-Port-Of: odoo/odoo#263185This pull request updates the core spreadsheet component, addressing several bugs and improving stability. It fixes issues related to chart visibility, error messages, and button functionality within the spreadsheet interface. The update also includes code improvements for consistency and dependency management.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d88c24e795 [FIX] chart: ensure chart values remain visible (remove clipping) [Task:…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/d88c24e795 [FIX] chart: ensure chart values remain visible (remove clipping) [Task: 5993132](https://www.odoo.com/odoo/2328/tasks/5993132) https://github.com/odoo/o-spreadsheet/commit/d854983ab3 [FIX] Gauge chart: error message in the side panel [Task: 6179300](https://www.odoo.com/odoo/2328/tasks/6179300) https://github.com/odoo/o-spreadsheet/commit/49d0b4dffa [FIX] grid overlay: unhide buttons visibility [Task: 6127335](https://www.odoo.com/odoo/2328/tasks/6127335) https://github.com/odoo/o-spreadsheet/commit/dd00c1135e [REF] lint: enforce braces for all control statements [Task: 6140827](https://www.odoo.com/odoo/2328/tasks/6140827) https://github.com/odoo/o-spreadsheet/commit/e2e096d9cb [FIX] package: add missing types dependency [Task: 6140820](https://www.odoo.com/odoo/2328/tasks/6140820) https://github.com/odoo/o-spreadsheet/commit/b24082bd32 [FIX] pivot: `getPivotCellFromPosition` will throw on invalid formula [Task: 6109696](https://www.odoo.com/odoo/2328/tasks/6109696) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update ensures that if a Stripe terminal payment capture fails, the payment status in Odoo POS is correctly set to 'retry' instead of being marked as 'done' silently. This prevents inaccurate payment records and ensures that payment issues are visible and addressed within the POS system.
Original PR description
Before this commit, a Stripe terminal payment could still be marked as `done` even if the capture step failed. This happens when the card authorization succeeds, `processPayment` returns a payment…
Before this commit, a Stripe terminal payment could still be marked as `done` even if the capture step failed.
This happens when the card authorization succeeds, `processPayment` returns a payment intent, but the subsequent `stripe_capture_payment` RPC fails and `capturePaymentStripe()` returns `false`. The capture flow did not guard that return value and still fell through to `line.set_payment_status("done")`.
In practice, this can happen for example if the Odoo server cannot resolve `api.stripe.com` while capturing the payment intent. Stripe then keeps the payment in `requires_capture`, while the POS line is still synced as paid.
Guard the failed capture path and stop the flow before marking the line as done. In that case, the payment line is put back to `retry` so the failure is visible in the POS instead of silently creating a paid, uncaptured payment.
opw-6075384
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#261521This update removes a redundant process in our account EDI system that was previously used to handle different data formats for electronic invoices from Belgium (BE). Previously, the system was switching between two formats, but now we exclusively use the standard 0208 format. This simplifies the system and improves efficiency.
Original PR description
When adding peppol, we didn't know if we needed to use the 9925:BE or 0208. Therefore, we switched between them if the endpoint was not found. This has no more use today as we use 0208. opw-5976574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#261307 Forward-Port-Of: odoo/odoo#258297
This update resolves an issue where payment reminders wouldn't display correctly when the 'Payment' module wasn't installed. The fix ensures the system checks for the necessary 'payment.method' model before attempting to use it, preventing a template rendering error.
Original PR description
Repro steps: 1. Initialize a new DB 2. Install account_followup module without payment module 3. Go to Email templates > Payment reminder 4. Click on Preview You will get an error Failed to render QWeb template for Mail Template: 'Payment Reminder' (ID: 9) Target Model: res.partner Language context: en_US Error: Error while render the template KeyError: 'payment.method' Root cause: The method `_show_pay_now_button` that was being called in the template email_template_followup_1 was using self.env['payment.method'] even tho payment module is not a dependency of account_followup Fix: The introduced fix ensures that 'payment.method' model exists before attempting to use it build_error-243030 Forward-Port-Of: odoo/enterprise#116443 Forward-Port-Of: odoo/enterprise#116079
17 changes
New functionality added to Odoo
This update introduces a new button within the subscription and rental modules, allowing sales users to quickly create quotations using pre-defined templates. This streamlines the quotation process and improves efficiency. The change will be enabled once the sale_management module is installed.
Original PR description
This PR completes the override of the New button, allowing users to see a custom New button and directly select a template from it. This new button will be enabled as soon as the sale_management module (which contains the templates) is installed. These changes are applied in both the subscription app and the rental app (for list and kanban and form views). Community PR: https://github.com/odoo/odoo/pull/258679 Upgrade PR: https://github.com/odoo/upgrade/pull/9913 task-6088445
Enhancements to existing features
This update enhances how rental prices are calculated by considering the full rental duration and applying prices at regular intervals (hourly, daily, etc.). This change introduces a slight complexity in price calculations due to rounding, and also optimizes the shop page performance by disabling search-based rental price computations.
Original PR description
With the replacement of rental rules by price rules in 2a934b799eb5f6d774ff6de86726b3887f1d8dab, we allowed users to use Availability dates to set specific prices for rental based on the rental…
With the replacement of rental rules by price rules in 2a934b799eb5f6d774ff6de86726b3887f1d8dab, we allowed users to use Availability dates to set specific prices for rental based on the rental period.
Doing so, we introduced a limitation as we currently take only the rule that matches the starting date/time of the rental.
This commit updates rental price computation to sum the price at each `rent_periodicity` step (hour/day/night/week) over the full rental duration.
Two drawbacks to this changes:
1. Formula-based rules may now behave differently. Rounding is applied per periodicity. For example, with a product priced at $99.99/day and a rule applying a 10% discount rounded to the nearest .99, starting on Monday till Tuesday (included). The price for a rental from Monday to Wednesday becomes:
```python
# Monday to Tuesday (included) + Wednesday
(round($99.99 - 10%) - $0.01) * 2 + $99.99
= $89.99 * 2 + $99.99
= $279.97
```
2. The shop page previously computed rental prices of each products based on the current search query. If the base loading times without rental was already slow, adding rental products won't help. An `ir.config_parameter` was added to disable the computation of rental prices based on the search query.
task-6020137
See also:
- https://github.com/odoo/odoo/pull/257618
### Bench
- Best of 5 GET request times on a 1096 days period (maximum allowed by the rental date picker on the shop)
- 21 products (5 by hours, 15 by days/nights, 1 by weeks)
- Hardware: MacBook M4 Pro (so very fast, much faster than SaaS in single core perf)
- Script to generate the DB can be found in [POC](https://github.com/odoo/enterprise/pull/110156)
- Command: `for i in {1..5}; do curl 'http://localhost:8069/shop?start_date=2026-03-23+17%3A00%3A00&end_date=2029-03-22+18%3A00%3A00' -o /dev/null -s -w "%{time_total}\n"; done | sort -g | head -n 1 | awk '{print "best: "$1"s"}'`
| No pricelist | Empty pricelist | Complex pricelist
-- | -- | -- | --
POC approach (diff [here](https://github.com/odoo/enterprise/pull/110693#issuecomment-4178075093)) | 3.841549s | 37.388301s | 126.696783s
Final approach | 1.835127s | 1.837871s | 1.913034sResolved issues and error corrections
This update enhances the automatic closing of expiring subscriptions by now considering outstanding upsell invoices. Previously, subscriptions would close prematurely even if the customer could still pay the upsell. This change ensures subscriptions are only closed when all invoices, including upsells, are within the payment timeframe, improving customer experience and payment processing.
Original PR description
Before this commit, if a subscription reached its due date but its upsell invoices didn't, the cron would close it anyway. This is not ideal because the customer might be willing to pay the upsell invoice. From now on, we will also consider upsell invoices in the EARLIEST closing date calculation for expiring subscriptions. After this commit, we don't let the cron auto-close the subscription if its upsell invoice is within the payment limit for its invoice lines. We are explicitely using the 'date_maturity' field of the invoice lines to calculate this due date range extension (as done before). task-4164026
This update fixes an issue where payment reminders weren't being sent to newly duplicated subscriptions. The root cause was a shared 'last_reminder_date' field preventing new reminders from triggering. The fix sets this field to 'false' for copied subscriptions, ensuring reminders are sent as expected.
Original PR description
Payment reminders are not sent to the duplicate of a subscription when a reminder has already been sent for the original subscription Steps to reproduce: 1. Install Subscriptions 2. Create a new…
Payment reminders are not sent to the duplicate of a subscription when a reminder has already been sent for the original subscription Steps to reproduce: 1. Install Subscriptions 2. Create a new subscription for customer Acme Corporation with product Office Cleaning Service (SUB), a Monthly recurring plan and in the Other Info tab, set the subscription Start Date to one week ago 3. Confirm the subscription 4. Go to Scheduled Actions and run the action "Sale Subscription: send reminder for subscriptions with no token" 5. Go back to the previously created subscription (see that a reminder email has been added in the chatter) 6. Duplicate the subscription and confirm the duplicate 7. Run the action "Sale Subscription: send reminder for subscriptions with no token" again 8. There are no reminder for the duplicate subscription Issue: The copy of a subscription uses the same `last_reminder_date`, preventing payment reminders to be sent here https://github.com/odoo/enterprise/blob/5a2ab62254cd5f684a3b1a0d7c0001b888c70d08/sale_subscription/models/sale_order.py#L2114-L2120 Solution: Set `copy=False` on the field `last_reminder_date` opw-6167356 Forward-Port-Of: odoo/enterprise#116335 Forward-Port-Of: odoo/enterprise#115509
This update fixes a problem where demo data in the Odoo test database caused ESG report tests to fail. The team adjusted the report's date and related records to an ancient date, eliminating interference from external data and ensuring reliable test results. This improves the stability of the ESG reporting process.
Original PR description
There was an issue when setting in draft all the account moves of the test DB before running the ESG report tests. In that process, some account moves were actually removed, which results in a 'Not found' record error. As the ESG report searches for all the account moves given a period (in all companies of the DB), some demo data could make the test to fail. We handle that issue by changing the date of the report and the related records to a very ancient date, to ensure that no external data will disturb the test. We also make that change for tests related to the HR part of the ESG report. runbot-error: https://runbot.odoo.com/odoo/runbot.build.error/242321 Forward-Port-Of: odoo/enterprise#116257
This update fixes a minor issue in the Swiss payroll module (l10n_ch_hr_payroll) related to the calculation of minimum income tax (min-IS) during the reversal of Quebec Sales Tax (QST). The change ensures accurate tax reporting, aligning with Swiss tax regulations and improving financial reporting accuracy.
Original PR description
opw 6133391 Fix for the source tax correction following PR #114463 Forward-Port-Of: odoo/enterprise#115585
This update fixes an error in the manufacturing report that incorrectly calculated quantities and costs when products were produced in different units of measure (e.g., Kg vs. Ton). The fix ensures accurate reporting by correctly converting quantities from move UoM to product UoM, leading to consistent and reliable cost data.
Original PR description
Steps to reproduce:
- Create a product W1 with UoM = Kg with the following BoM:
- Component C1: 1 unit, cost = $1
- Create and confirm MO1:
- Produce 1 Kg of W1 → total cost = $1
- Create and confirm MO2:
- Produce 1 Ton of W1 → total cost = $1000
- Open the Manufacturing Report and group results
Problem:
- qty_produced ≈ 1.001 instead of 1001
- unit_cost average ≈ 1000 instead of 1
Expected behavior:
- qty_produced = 1001
- unit_cost average = 1 (consistent across MOs)
The manufacturing report (`mrp.report`) incorrectly converts quantities from move UoM to product UoM, leading to wrong `qty_produced` and `qty_demanded` values when different units of measure are used
The current implementation uses:
sm.quantity / uom.factor * uom_prod.factor
This inverts the conversion ratio. As a result:
- 1 Ton is converted to 0.001 Kg instead of 1000 Kg
opw-6097098
Forward-Port-Of: odoo/enterprise#116322
Forward-Port-Of: odoo/enterprise#113979This update resolves an issue where multiple signed documents with the same subject were not being correctly downloaded into a single zip file. The fix ensures that all documents with identical subjects are included in the generated zip file, improving the user experience and preventing data loss. This change was made to maintain consistent behavior across versions.
Original PR description
## Issue In the *Sign* app, when attempting to download multiple documents with similar subjects, only one document appears in the resulting zip file. ## Steps to reproduce 1. Install *Sign* (`sign`)…
## Issue
In the *Sign* app, when attempting to download multiple documents with similar subjects, only one document appears in the resulting zip file.
## Steps to reproduce
1. Install *Sign* (`sign`)
2. Sign a same template twice, using the same subject S1. This gives us Documents D1 an D2.
3. (Optionally), sign the same template a third time, using a different subject S2, creating document D3.
4. In Sign > Documents, select the 2 (3) signed documents and click *Download*.
5. **In the resulting zip file, there's one folder S1 containing a single pdf document (D1) (and one folder S2 containing D3). Document D2 is missing from the zip file.**
## Cause
When generating the zip file, the path used for each document is `{subject}/{doc_name}`.
https://github.com/odoo/enterprise/blob/863abc99469c12acdebcab05788d566c370bb46f/sign/controllers/main.py#L276-L286
Neither of this attribute are unique, which means that two signed documents with the same name and subject can be downloaded simultaneously, but will then overwrite each other.
## Fix
Before version 18.3, the zip file would contain folders named with the (unique) request id, which would consistently make them distinct from one another. This behavior was changed by https://github.com/odoo/enterprise/commit/4254542e8fb4ce3b2b9b46c624d86f7fcac8df7b to use the `sign_request.subject` instead. This commit adds the `request.id` after the subject to keep the clarity of the subject, and add the uniqueness of the id.
opw-6143128
Forward-Port-Of: odoo/enterprise#116179
Forward-Port-Of: odoo/enterprise#116013This update removes unnecessary padding from the AI systray button, resulting in a cleaner and more consistent look. The change was made to streamline the styling and ensure the button's design aligns with the overall application theme. This is a minor visual improvement.
Original PR description
Remove the `btn` class because it adds additional padding, and eliminate the other unnecessary classes since the rules have already been applied in the `navbar.scss` file. task-5079952 Forward-Port-Of: odoo/enterprise#116509 Forward-Port-Of: odoo/enterprise#116423
This update resolves a problem where a tour element was incorrectly triggered in the VoIP feature, causing unexpected behavior. The fix narrows the trigger to only the keypad tab, ensuring the tour initiates correctly when users switch to that mode. This improves the user experience for VoIP calls.
Original PR description
Similar as [1], trigger `.o-voip-Softphone .o-voip-countryFlag` can be found on both recent and keypad tab. It's possible to find it before dom actually change to keypad tab. In this commit, we narrow down the trigger so that it can only be found on keypad tab. [1]: d838dd6dccdaeb8e9d6676ef4ccb5bbced4441a9 Forward-Port-Of: odoo/enterprise#116535
This update resolves a few minor issues related to appointment scheduling within the Enterprise module. Specifically, it ensures resources are correctly filtered based on appointment types, addresses a warning in the search filter, and corrects a problem where the wrong customer form was used when booking appointments from the Gantt view. These changes enhance the user experience and data accuracy.
Original PR description
1. Filter resources based on the appointment type When adding a closing day from the Gantt view, every resource could be selected, even those not related to the current appointment type. Now, if a default appointment type is set in the context, resources are filtered to only show those related to that appointment type. 2. Warning with PosAppointmentSearchFilter A console warning was logged because the empty props of the PosAppointmentSearchFilter component were not explicitly declared. 3. Change partner form view when booking from the Gantt view When creating or editing a booking from the Gantt view, we could select a customer, but the default partner form was used instead of the one already created for the PartnerList component. --- Task: https://www.odoo.com/odoo/project/1737/tasks/6147711 Forward-Port-Of: odoo/enterprise#114677
This update resolves an issue where invoices were incorrectly assigned to lower follow-up levels in reminder attachments. The change ensures that invoices are always linked to the appropriate follow-up level, improving the accuracy of reminder processes. This prevents mismatched follow-up levels and ensures timely invoice reminders.
Original PR description
Previously(https://github.com/odoo/enterprise/commit/105d3bff49d486b8ecd943e77d635fe011b5e361), `_update_followup_line_on_move_lines` could downgrade AMLs when executed with a lower follow-up level, as all lines were recomputed without considering their current level. Additionally, invoices with a higher follow-up level were also included in lower level reminder attachments. With this commit, `unreconciled_aml_ids` are filtered to exclude lines that already have a higher follow-up level, preventing downgrade and aligning the attachments with the triggered follow-up level. Forward-Port-Of: odoo/enterprise#114566
The Gantt view now accurately displays operation durations in hours instead of minutes. This change was necessary to ensure that production planning timelines are presented correctly, improving the reliability of work order scheduling. This fix resolves a discrepancy identified during a recent formatting update.
Original PR description
Issue ----- In the gantt view, operation duration is displayed as minutes but is actually in hours. Steps to reproduce ----- - Enable work orders - Create a product with a BoM - Add an operation with some duration on the BoM - Creation a MO for the product, confirm & plan - Open the gantt view > Duration is displayed in minutes Cause ----- Overlooked by the rework of formatter done in b764335. Value is in hours but unit is set to "minutes". https://github.com/odoo/enterprise/blob/8281fe6c830dce94ca851bf4bd5c768443721f17/mrp_workorder/static/src/mrp_workorder_gantt_renderer.js#L46-L49 ----- Ticket: opw-6109524 Forward-Port-Of: odoo/enterprise#113829
This update resolves an issue preventing correct submission of Dutch VAT returns (SBR) when using multiple companies within a single VAT unit. The fix ensures that only the relevant return company's closing entry is used, avoiding an error that previously blocked the process. This improves the reliability of the Dutch VAT reporting functionality.
Original PR description
In a multi-company/multi-branch setup where multiple entities form a single VAT unit, Odoo generates a closing entry for each branch/company during the tax closing process. When attempting to submit the Dutch VAT return via Digipoort (SBR), the wizard gathers these entries via `closing_move_ids`. However, the code subsequently tries to set the resulting recordset as `closing_entry_id` on `l10n_nl_reports.sbr.status.service`, which results in a traceback: `ValueError: Expected singleton: account.move(id1, id2, ...)` This occurs because `closing_entry_id` is a `Many2one` which requires a single record (singleton), but the system provides all closing moves from the tax group. This commit fixes the issue by filtering the closing moves to only target the one associated with the return company, ensuring a singleton is passed to the message posting logic. Issue introduced by: 647699eeb4b8a1cc37ca074fa57844871c5086c1 opw-6106081 Forward-Port-Of: odoo/enterprise#116237
This update fixes an issue where a blank box was sometimes visible on smaller screens when rental dates weren't being entered. We've adjusted the display logic to ensure the box only appears when rental dates are actually selected, improving the user experience. This change focuses on the 'sale' module.
Original PR description
Previously, the `<div>` was displayed even when its content was hidden due to the "invisible" attribute. To fix this, we move the visibility condition to the parent. This works since the `<button>` (in charge of updating rental line prices) already has a stricter invisibility condition. Note that `.o_input_box` doesn't exist anymore. Related commit: https://github.com/odoo/enterprise/commit/7cdfe5bd1541380d746f3208bc198fb89f7cb22a Forward-Port-Of: odoo/enterprise#116429
This update resolves an issue where inactive reports were appearing in report search results, and a bug related to the VAT Return (CZ) report. The fix ensures accurate report filtering and prevents crashes when selecting reports, improving the user experience for financial reporting.
Original PR description
When searching for reports through the search panel inactive reports still show up in the result, this change hide the inactive variant reports from the search result. Also, fixes a minor bug related the l10n_cz, When search for VAT Return (CZ) it would cause a bug due to missing the target report to look into. task: 6149101 Forward-Port-Of: odoo/enterprise#115500
This update automatically adds new UNSPSC codes to the Odoo database when the product module is updated. Previously, these codes could only be added during initial installation, creating a delay in reflecting the latest industry standards. This change ensures our product data remains current and accurate.
Original PR description
**Problem:** Periodically, the UNSPSC codes may be updated and they must be added to existing databases. Normally this is done by module update, however, since there are thousands of UNSPSC codes, a CSV imported via SQL is used instead of XML files. This import is only implemented on module install and not module update, so there is no way to update the UNSPSC codes in existing databases. **Solution:** An upgrade script based on the post-init hook has been added, which will add the new codes to the database, if any. Note that: - The version of this upgrade script should be bumped any time the codes list is updated. - Existing records will not be updated opw-5943366 Forward-Port-Of: odoo/enterprise#116063 Forward-Port-Of: odoo/enterprise#112652
4 changes
Resolved issues and error corrections
This update resolves an issue where free FSM services with prepaid invoicing were not appearing on invoices. The change adjusts a calculation to ensure these services are correctly reflected when creating invoices, allowing for accurate billing and reporting. This improves the functionality for handling service-based sales.
Original PR description
Changed _compute_qty_to_invoice in industry_fsm_sale, SaleOrderLine to no longer set qty_to_invoice to 0 for free services with prepaid invoicing. Previous changes seem intended for goods. Steps to reproduce: - Create service product with 0 price, prepaid invoice policy, creates FSM task - Create/Confirm sales order with created product - Attempt to create invoice, get 0 quantity to invoice error Current Behavior: Free services linked to FSM tasks do not appear on invoices due to compute 0 qty_to_invoice Expected Behavior: Prepaid Invoice Services linked to FSM tasks appear on invoices. Other invoice policies can be invoiced through the generated sales order lines (timesheets, delivered quantity, etc.) opw-6047992 Forward-Port-Of: odoo/enterprise#116413 Forward-Port-Of: odoo/enterprise#113718
This update resolves a technical issue preventing users from correctly booking appointments with flexible scheduling and capacity limits. The fix addresses a problem where the system incorrectly processed boolean values during the appointment slot calculation, leading to a booking error. This ensures appointments with multiple participants and capacity management now function as expected.
Original PR description
### Steps to reproduce: - Download "Appointment" and "Website" - Configure an appointment to be booked by resource with multiple seats and manage capacity - Set the schedule to be flexible and configure valid time slots - Go to the booking page and select the number of participants > Traceback: cannot unpack non-iterable bool object ### Cause of Issue: The `_get_appointment_slots` method unpacks the `appointment_slots_force_month` directly: https://github.com/odoo/enterprise/blob/4ca3dddaeadeb6c937d555cc4da8fb4bb61fea35/appointment/models/appointment_type.py#L871 Since the `appointment_slots_force_month` value was explicitly set to `False` in https://github.com/odoo/enterprise/blob/4ca3dddaeadeb6c937d555cc4da8fb4bb61fea35/appointment/controllers/appointment.py#L1063-L1070 the unpacking operation failed because it tried to unpack a boolean instead of a tuple. opw-6197653
This update resolves an issue where duplicate serial numbers appeared in the picking view after using the barcode scanner. The fix ensures that the system correctly handles new serial numbers created during barcode scanning, preventing data inconsistencies and improving the accuracy of inventory tracking. It addresses a UI display problem related to barcode processing.
Original PR description
Problem: When entering the barcode interface from a picking and scanning a different serial number than one already reserved, a new line gets created in certain situations. When exiting the barcode…
Problem: When entering the barcode interface from a picking and scanning a different serial number than one already reserved, a new line gets created in certain situations. When exiting the barcode interface without validating the picking, both serial numbers show up on the picking view. However, the first serial number’s `stock.move.line` was deleted, so only one serial number should be there. When exiting the barcode interface a call to `post_barcode_process` is made, where the extra `stock.move.line` is deleted, but it doesn’t wait for the call to finish. https://github.com/odoo/enterprise/blob/d5a52cb79c9c41d792685d2858cfeb6aee147642/stock_barcode/static/src/models/barcode_picking_model.js#L1896 Purpose: By overriding `beforeQuit` to add the `_onExit` call, the component now waits for the `post_barcode_process` call to finish before navigating back to the picking view. This helps ensure the UI displays the updated data. Steps to reproduce on Runbot: Create a product tracked by serial numbers. Have 2 units on hand: serial 001 with a package, and serial 002 without a package. (This is needed so the barcode app will create a new line). Create a delivery for 1 unit of our test product and mark it as todo. Ensure that serial 001 is reserved. Click the Barcode smart button and scan the barcode for serial 002. Click the back button. Observe that both serial numbers are shown on the picking. Refresh the page and observe only serial 002 is now shown. opw-6105740
This update fixes a limitation in how Odoo updates its UNSPSC product codes. Previously, new codes weren't automatically added after module updates, requiring manual imports. Now, an upgrade script runs during module updates to add missing codes from a CSV file, ensuring the system always has the latest product classifications.
Original PR description
**Problem:** Periodically, the UNSPSC codes may be updated and they must be added to existing databases. Normally this is done by module update, however, since there are thousands of UNSPSC codes, a CSV imported via SQL is used instead of XML files. This import is only implemented on module install and not module update, so there is no way to update the UNSPSC codes in existing databases. **Solution:** An upgrade script based on the post-init hook has been added, which will add the new codes to the database, if any. Note that: - The version of this upgrade script should be bumped any time the codes list is updated. - Existing records will not be updated opw-5943366 Forward-Port-Of: odoo/enterprise#116063 Forward-Port-Of: odoo/enterprise#112652
8 changes
Resolved issues and error corrections
This update addresses a technical issue within the Odoo spreadsheet component, specifically related to chart visibility. The changes ensure that chart values remain fully visible by removing clipping, improving the user experience. This update also includes standard code improvements for consistency and stability.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/24a7e5513f [FIX] chart: ensure chart values remain visible (remove clipping) [Task:…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/24a7e5513f [FIX] chart: ensure chart values remain visible (remove clipping) [Task: 5993132](https://www.odoo.com/odoo/2328/tasks/5993132) https://github.com/odoo/o-spreadsheet/commit/f36e6ce39f [REF] lint: enforce braces for all control statements [Task: 6140827](https://www.odoo.com/odoo/2328/tasks/6140827) https://github.com/odoo/o-spreadsheet/commit/17db4384c7 [FIX] pivot: `getPivotCellFromPosition` will throw on invalid formula [Task: 6109696](https://www.odoo.com/odoo/2328/tasks/6109696) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update resolves an issue where partners sharing the same VAT number were incorrectly excluded from VAT reports if their individual turnover was below €250. The change ensures all partners with a shared VAT number and exceeding the €250 threshold are now included in the report, improving data accuracy for tax reporting.
Original PR description
Reverts a problematic commit and adds a clean commit to fix the original issue.
This update fixes an issue where HR leave requests with 'both' approval types didn't send notifications to the designated responsible parties. The change ensures that notifications are correctly sent to the 'Notified Time Off Officer' when this approval type is selected, improving the accuracy of leave request workflows.
Original PR description
…cer') no fallback for responsible_ids
Issue:
When ('both','By Employee's Approver and Time Off Officer') is selected on a new HR Leave Type it does not fall back to the responsible_ids or “Notify HR”.
Steps:
1) Setup a neutralized outgoing mail server
2) install hr_holidays
3) make a new hr.leave.Type (Approval) with ('both','By Employee's Approver and Time Off Officer') and select a 'Notified Time Off Officer'(responsible_ids) 4) select an emplyee with a reelated user and remove the coach, manager, and responsible 'Time Off'. 5) save
6) Sign in as the employee, make a time off request under the new Type 7) No email
Fix:
Add a conditional with the lowest priority to fall back to responsible_ids
opw-6101637
Forward-Port-Of: odoo/odoo#261853This update resolves an issue where product revaluations incorrectly included default tax amounts. This was caused by how the system handled accounts with pre-set taxes, particularly in localization modules. The fix ensures that revaluations accurately reflect the product's cost without unnecessary tax calculations.
Original PR description
Issue ----- If the account on which stock revaluation is registered has a default tax, the account moves generated by changing the price of the product include the tax. For context, the issue was…
Issue ----- If the account on which stock revaluation is registered has a default tax, the account moves generated by changing the price of the product include the tax. For context, the issue was reported because some l10n modules use accounts with default taxes (eg l10n_de). Steps to reproduce ----- - Install a localisation to have default accounts set up - Create a product category (Cat1) - Set Inventory Valuation to "Automated" - Set a default tax on the Expense Account - Create a product Prod1 - Storable - Category set to Cat1 - Cost set to 500 - Update the on hand quantity of Prod1 to 1 - Change the price of Prod1 to 300 - Go to Accounting > Accounting > Journal > Journal Entries --> There is an AM for 200 + tax instead of just 200 Discussion ----- When manually changing the cost of the product, we call https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/stock_account/models/product.py#L354 Where we create the AMs https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/stock_account/models/stock_valuation_layer.py#L294 This creates the corresponding debit/credit AMLs. Afterwards, we go through https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move.py#L3210 Which calls `_sync_tax_lines` where AMLs are created for the taxes https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move.py#L3088 Solution ----- The AML's `tax_ids` field is precomputed https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move_line.py#L192-L198 and takes the taxes from the account https://github.com/odoo/odoo/blob/09c366dcfa5fe550a1afef813faa79f43767d0a5/addons/account/models/account_move_line.py#L894 By explicitly stating an empty value when we create the AM in `_change_standart_price_accounting_entries`, we avoid the compute so tax lines don't get created. ----- Ticket: opw-5929774
The budget report now accurately displays data without duplicate analytic lines. This issue stemmed from a recent performance optimization that inadvertently created duplicate entries. The fix ensures unique reporting by using a more precise query structure.
Original PR description
#### Issue: The budget report displays duplicate analytic lines. #### Steps to reproduce: In a new company: - Create a budget with one budget line (Analytic Account A). - Create one analytic item…
#### Issue: The budget report displays duplicate analytic lines. #### Steps to reproduce: In a new company: - Create a budget with one budget line (Analytic Account A). - Create one analytic item (linked to Analytic Account A). - Open the budget report and remove the default "open budget" filter. Duplicate amounts appear in the pivot view and duplicate lines appear in the list view. #### Cause: In #104299, the query in `_get_aal_query` was refactored for performance to avoid a single query with an OR condition in the LEFT JOIN. It was replaced by two separate queries combined with `UNION ALL`. This caused some lines to be captured by both queries, resulting in duplicates in the final report. #### Fix: Use three separate queries, each with specific filter conditions to guarantee unique results: Q1 - Analytic lines with no matching budget line. Q2 - Analytic lines matched to a budget line with no company (null-company). Q3 - Analytic lines matched to a company-specific budget line. OPW-6051696
This update fixes an issue where project update descriptions incorrectly showed inflated budget totals due to summing all budget revisions, regardless of their status. Now, project updates accurately reflect only the active, confirmed budget revision, ensuring accurate reporting and financial data. This improves the consistency of budget information displayed to users.
Original PR description
**Problem:** When a project analytic budget is revised, the project update description shows an inflated total budget — the sum of both the original and the revised amounts — instead of reflecting…
**Problem:** When a project analytic budget is revised, the project update description shows an inflated total budget — the sum of both the original and the revised amounts — instead of reflecting only the active (confirmed) revision. **Steps to reproduce:** 1. Create a project with an analytic account 2. Create an analytic budget of $10,000 and confirm it 3. Create a revision of that budget for $15,000 and confirm it 4. Create a new project update 5. The update shows "$25,000" as the total budget instead of "$15,000" **Current behavior:** The project update displays the sum of all budget revisions ($25,000), regardless of their state. **Expected behavior:** Only the active confirmed budget ($15,000) should be used. **Cause of the issue:** `_compute_budget` queries all `budget.line` records matching the project's analytic account without filtering by the parent `budget.analytic` state. When a budget is revised, the original transitions to state `revised` while the new one becomes `confirmed`. Because `_compute_budget` has no state filter, it sums both, producing an inflated `total_budget_amount`. This field is then used in the project update template to compute the displayed budget total and percentage. By contrast, `_get_budget_items` — used for the detail rows — already applies `state in ['confirmed', 'done']`, so the two methods were inconsistent. **Fix:** Applying the same state filter to `_compute_budget` as already present in `_get_budget_items` ensures both methods draw from the same set of active budgets, keeping the project update totals consistent with the budget detail rows. opw-6128855
This update fixes an issue where the shipping weight in package creation was incorrectly calculated, using the total weight of all delivery lines instead of just the selected ones. This ensures accurate weight calculations for package preparation, leading to more precise shipping costs and inventory management. The change impacts the stock delivery module.
Original PR description
Issue ----- When putting a subset of lines in a pack, the wizard computes the weight as if all of the picking's lines were selected. Steps to reproduce ----- - Enable packages - Create a packaging type for carrier "No carrier integration" (std delivery) - Create 2 products with different weights - Create a delivery - Add a demand for both products - Additional Info > Carrier: Standard delivery - Mark as Todo - Open the moves view - Select one of the 2 lines - Click Put in pack - Select the package type > The "Shipping Weight" is the picking's weight instead of the selected line's ----- Ticket: opw-6125285
This update fixes an issue where some UBL invoices were being incorrectly processed. The change ensures that invoices with a valid CustomizationID are prioritized, improving the system's ability to correctly interpret UBL invoices. A fallback mechanism remains in place for unknown formats to maintain compatibility.
Original PR description
Some UBL invoices we receive both have a node CustomizationID signifying that it's a bis3 and a UBLVersionID 2.1 (which should be illegal). We don't block malformed bis3 invoices. But we should try to guess that it's a bis3 if it has the perfect customization. We can keep the fallback in case it's an unknown bis3 format. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#263285
5 changes
Resolved issues and error corrections
This update fixes a minor error in the Norwegian tax settings. The tax rate for code 32 was incorrectly set to 11.0. This change ensures that Odoo accurately reflects the latest official Norwegian tax rates, improving financial reporting accuracy.
Original PR description
The tax rate(`amount`) for code 32 was mistakenly set to '11.0'. To properly align with the official Norwegian tax rates, it needs to be updated to '11.11'. Related Enterprise PR: https://github.com/odoo/enterprise/pull/110792 task-6033027
This update resolves an issue where product variants were automatically created when viewing products on the eCommerce site. The change ensures variants are only generated when a Sales Order is placed, aligning with the intended Dynamically attribute behavior. This improves the user experience and prevents unnecessary variant creation.
Original PR description
For now, when a product is created with a Dynamically attribute, a variant is automatically created when viewing the product on the eCommerce site. However, the Dynamically behavior is supposed to create a variant only when a Sales Order (SO) is created. This PR fixes the issue by preventing the variant from being created when simply viewing the product on the eCommerce site. opw-6060733
This update fixes an issue where some UBL invoices were being incorrectly processed. The change ensures that invoices with a valid CustomizationID are prioritized, improving the accuracy of UBL invoice handling. A fallback mechanism remains in place for unknown UBL formats to maintain compatibility.
Original PR description
Some UBL invoices we receive both have a node CustomizationID signifying that it's a bis3 and a UBLVersionID 2.1 (which should be illegal). We don't block malformed bis3 invoices. But we should try to guess that it's a bis3 if it has the perfect customization. We can keep the fallback in case it's an unknown bis3 format. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a bug that prevented accurate reconciliation of inventory items when selling kits containing components. The issue stemmed from how valuation layers were handled, leading to repeated reconciliation attempts. This ensures correct accounting and reporting for products sold as kits.
Original PR description
Steps to reproduce ----- - Modules: Sale, Purchase, Mrp, Accounting - Enable automatic accounting & anglo-saxon valuation - Create an AVCO Product category (AVCO automatic valuation) - Create a Kit…
Steps to reproduce
-----
- Modules: Sale, Purchase, Mrp, Accounting
- Enable automatic accounting & anglo-saxon valuation
- Create an AVCO Product category (AVCO automatic valuation)
- Create a Kit product storable & AVCO
- Kit bom
- Comp as a component (storable & AVCO)
- Settings > Decimal Accuracy > Product Price > set to 4 digits
- Purchase 3 units of Comp at 3.3333 piece & validate reception
- Make 2 sales for 1 unit of Comp each & validate both deliveries
- Create a SO for 1 Kit and 1 Comp & confirm
- Create & confirm invoice
- Go to the delivery, force quantity on the component and try to validate delivery
> Error message: "You are trying to reconcile some entries that are already reconciled."
/!\ Fun(?) fact: this error doesn't occur if the order of the moves is inverted.
Cause
-----
When the purchase delivery is validated, a stock valuation layer is created for 3 units with a value of 10. As they are sold individually, these 3 units generate a valuation layer for 3.33 per unit summing to 9.99.
When we validate the last delivery, the 0.01 difference is detected and an adjustment is made on the valuation layer in `_prepare_out_svl_vals`.
However this adjustment is made for the product when the invoice line concerns the kit. As a result, the first reconciliation fails and the line is added to the list to be reconciled later.
Then, when handling the line for COMP2, it will successfully reconcile the lines while it is still in the pool to be reconciled, resulting in an error when attempting to reconcile it later.
This is caused by `_stock_account_anglo_saxon_reconcile_valuation` where the `product_stock_moves` only contains the kit move when called with the kit product as argument, but it contains both moves when called with the component itself as argument. This leads to the same AML being reconciled twice.
https://github.com/odoo/odoo/blob/f0b9f4c234cd0101f5cb259e58620e1cf65bb2b7/addons/stock_account/models/account_move.py#L222-L225
-----
Ticket:
opw-5722072Code cleanup and technical improvements
This update ensures the o_spreadsheet library used in our spreadsheet functionality is running the latest version. This improves stability and performance, and addresses minor code improvements for better maintainability. It's a routine maintenance update.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/79ef1d87e8 [REF] lint: enforce braces for all control statements [Task: 6140827](https://www.odoo.com/odoo/2328/tasks/6140827) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>