Daily updates from Odoo
Monday, June 8, 2026
263 changes
9 changes
Resolved issues and error corrections
This update fixes a missing translation for the 'Count LoC' report within Odoo's technical menu. Adding this translation ensures consistent and accurate reporting across all supported languages, improving the user experience for international customers.
Original PR description
Before this commit, the technical menu for the 'Count LoC' report was never translated. This commit adds it to the translated terms.
A recent update to Odoo improved memory usage during document uploads, but this caused issues with searching documents using the 'Indexed Content' filter. This fix re-introduced a necessary step to ensure documents are properly indexed, restoring the search functionality. The change optimizes indexing while maintaining memory efficiency.
Original PR description
**Steps to reproduce:** - Install Documents app - Upload a new pdf file - Try to search the file with the 'Indexed Content' filter - Search won't find the file even if the uploaded document contains…
**Steps to reproduce:** - Install Documents app - Upload a new pdf file - Try to search the file with the 'Indexed Content' filter - Search won't find the file even if the uploaded document contains the searched keyword/content **Issue:** After [1] (19.3+) the file upload process was reworked to avoid loading entire files into memory during attachment creation (removed `'raw': file.read()`). But this breaks the index content creation as it was using the `raw` field value during the create to trigger the `_index` function in `_get_datas_related_values`. Also, restoring the previous behavior for the indexation would undo the memory usage improvements that were made. **Fix:** Added the `_index` call in `_upload_file` after the attachment creation. Also optimize the default text index to avoid reducing too much the memory improvements (but for now the other mimetypes can still be impacted by the type-specific `_index_*` and the external libraries performances). [1] https://github.com/odoo/odoo/commit/6222dedaf89a595b6f499679c3f553aa081c46bd opw-6232999
This update resolves an issue where searching for files within the Documents app wasn't working correctly after a recent optimization. The fix ensures that files are properly indexed, allowing users to find documents using the 'Indexed Content' filter. This improves the overall search experience.
Original PR description
**Steps to reproduce:** - Install Documents app - Upload a new pdf file - Try to search the file with the 'Indexed Content' filter - Search won't find the file even if the uploaded document contains…
**Steps to reproduce:** - Install Documents app - Upload a new pdf file - Try to search the file with the 'Indexed Content' filter - Search won't find the file even if the uploaded document contains the searched keyword/content **Issue:** After [1] (19.3+) the file upload process was reworked to avoid loading entire files into memory during attachment creation (removed `'raw': file.read()`). But this breaks the index content creation as it was using the `raw` field value during the create to trigger the `_index` function in `_get_datas_related_values`. Also, restoring the previous behavior for the indexation would undo the memory usage improvements that were made. **Fix:** Added the `_index` call in `_upload_file` after the attachment creation. Also optimize the default text index to avoid reducing too much the memory improvements (but for now the other mimetypes can still be impacted by the type-specific `_index_*` and the external libraries performances). [1] https://github.com/odoo/odoo/commit/6222dedaf89a595b6f499679c3f553aa081c46bd opw-6232999
This update resolves an issue preventing Odoo from correctly validating Turkish VAT invoices when using GİB placeholder VAT numbers. Turkish regulations permit these placeholders for specific invoice types, and this change ensures Odoo accepts them while maintaining existing VAT validation rules and test environment exceptions. This improves compliance for Nilvera users in Turkey.
Original PR description
- Turkish regulations allow the usage of special placeholder identifiers for invoices issued to non-taxpayer end consumers and overseas customers, where providing a real TCKN/VKN is not mandatory. - Although Odoo already referenced these identifiers in the VAT format help message (`11111111111` for TCKN and `2222222222` for VKN), they were still rejected by the Turkish VAT validation logic because they do not pass the standard `stdnum` checks. - This commit extends the Turkish VAT validation to explicitly allow these GİB-approved placeholder identifiers while preserving the existing standard VAT validation behavior and Nilvera test environment exceptions. taskID-6237629
This update resolves an issue where Spanish users were incorrectly interpreting durations entered with decimal separators (e.g., "0,5"). The code was adjusted to properly handle the order of replacing decimal and thousand separators, ensuring durations are now recognized accurately in Spanish. This improves the usability of the Timesheet feature for Spanish-speaking users.
Original PR description
Issue: ---------------------------------------- In Spanish, inputting "0,5" as a duration is recognized as 5 hours instead of 30 minutes. Steps to reproduce: ----------------------------------------…
Issue:
----------------------------------------
In Spanish, inputting "0,5" as a duration is recognized as 5 hours instead of 30 minutes.
Steps to reproduce:
----------------------------------------
- Install Project and Timesheet
- Switch the user language to Spanish
- Open a task, in the "Timesheet" page, create a new line
- Input "0,5" as duration
Cause:
----------------------------------------
In the parser, the value is transformed according to the language decimal point and thousands separator:
```js
value = value
.replaceAll(localization.decimalPoint, ".")
.replaceAll(localization.thousandsSep, "");
```
In Spanish `decimalPoint` is "," and `thousandsSep` is ".". So the first `replaceAll()` changes "0,5" into "0.5", then the second one deletes the point.
Solution:
----------------------------------------
We need to invert the two `replaceAll()`.
As the `thousandsSep` is just removed, this will not create a new issue in another language.
opw-6263523
Forward-Port-Of: odoo/odoo#268461This update corrects a previous issue that limited product options when creating sale orders on mobile devices. It now allows users to add products with `sale_ok=False` and non-rental products to rental orders, expanding flexibility. This change resolves a regression introduced in a prior update.
Original PR description
This commit reverts 6e8a2d9c2d80044f6ee33c96871accf0aa83f4eb which introduce regression by ignoring product domain from `_domain_product_id`. Due to this issue, you can add products with `sale_ok=False` in SOL using a phone. Also you could add non-rental product in rental orders. opw-6218312 Forward-Port-Of: odoo/odoo#268331
This update resolves an issue where the activity rate for Swiss payroll calculations was incorrectly tied to individual employees instead of the Odoo Enterprise version. This change ensures accurate reporting and compliance with Swiss tax regulations by basing the rate on the correct Odoo version.
Original PR description
…ployee Forward-Port-Of: odoo/enterprise#119658
This update fixes an issue where the ICP export generated inconsistent XML reports by using values from multiple company contexts. The change ensures a single, reliable company context is used for identifier values, improving the accuracy and clarity of the exported data. This enhances the reliability of reporting for Dutch VAT compliance.
Original PR description
Description of the issue this commit addresses: The ICP export could mix values from different company contexts. In some cases, the main identifier and the fiscal entity division value did not come from the same source, which could create confusing or inconsistent XML output. --- Desired behavior after this commit is merged: This commit makes the ICP export use one consistent company context for identifier values, reuses precomputed values when available, and avoids overwriting them with unrelated defaults. --- task-6065382 Forward-Port-Of: odoo/enterprise#119549 Forward-Port-Of: odoo/enterprise#112995
This update corrects tax calculations and closing logic for split payments in Italy (l10n_it). Specifically, it removes redundant tax data and ensures accurate tax reporting within the split payment process, leading to more reliable financial records.
Original PR description
with this commit:- - Removing unnecessary 'SP Pos.' taxes. - Adopted correct tax data for 'SP' taxes so that it works correctly in Split Payment case. - By these changes, tax closing entries will become hermetic. task-6116304 Forward-Port-Of: odoo/odoo#268747 Forward-Port-Of: odoo/odoo#264336
13 changes
Resolved issues and error corrections
This update enhances the way Odoo handles errors when connecting to serial devices like scales. Instead of generating excessive error logs, the system now logs warnings with detailed information, reducing unnecessary alerts and improving system performance. This change prevents overwhelming monitoring tools and ensures a smoother user experience.
Original PR description
Instead of logging an exception or an error on probe failure for serial devices, we now log a warning with stack info. This avoids spamming sentry with error logs that only are probe attempts. e.g. if the device plugged is a scale, we will probe for belgian + swedish blackbox first, causing two errors three times (as we retry 3x). see odoo/enterprise#119683
This update adjusts the certification checksum to align with recent changes to the scale driver. The goal is to maintain the integrity and accuracy of our certification process, ensuring continued compliance. This change was necessary due to a streamlining of exception handling within the scale driver.
Original PR description
As we updated the scale driver to reduce the amount of exception caught, we need to update the certification checksum. see odoo/odoo#268796
This update corrects how Italian taxes are calculated and processed during split payments. Specifically, unnecessary tax codes have been removed and the correct tax data is now used, ensuring accurate tax closing entries. This improves the reliability of Italian accounting within the Odoo system.
Original PR description
with this commit:- - Removing unnecessary 'SP Pos.' taxes. - Adopted correct tax data for 'SP' taxes so that it works correctly in Split Payment case. - By these changes, tax closing entries will become hermetic. task-6116304 Forward-Port-Of: odoo/odoo#264336
This update resolves a bug where the size of country flags on the Visitors reporting page would unexpectedly change after installing the Livechat app. Additionally, the system was incorrectly removing image sizes set in Studio, now flags correctly respond to size adjustments. This ensures consistent and accurate flag display.
Original PR description
The website.visitor.view.kanban view uses the o_country_flag class which is not defined anywhere besides livechat_channel_info_list.scss. This causes unintended behavior where the flag size for the kanban view on ' Website > Reporting > Visitors ' changes when installing the livechat app. Additionally, the image_url_field.js file does not address cases when height/width are not set. This results in the flags (or any other image using 'widget="image_url"' disappearing (being set to a 'width: 0px') whenever their Size is set via Studio. This change makes it so that the flags don't disappear when altered in Studio (but does not make them actually respond to size changes) Related tickets: opw-5962151, opw-5995004 Forward-Port-Of: odoo/odoo#251618
This update resolves an issue where the IRN (Invoice Reference Number) wasn't being saved when sending invoices via e-invoicing with email in the Indian localization. The fix ensures the IRN is correctly recorded on the invoice after sending, improving compliance and reporting accuracy. This impacts users utilizing the e-invoicing feature for Indian businesses.
Original PR description
**Issue**: Sending invoice through e-invoicing with email in Indian localization will not save the IRN number on the invoice because of a cache issue on the attachment id. **Steps to reproduce**: Install l10n_in_edi_gstr module. Create an invoice and send it through e-invoicing with email option. The IRN number will not be saved on the invoice. **Causes**: When sending the invoice through e-invoicing with email option, the attachment id is not saved on the invoice before calling the method _l10n_in_edi_send_invoice(). This causes a cache issue and the IRN number is not saved on the invoice. **Fix**: Save the attachment id on the invoice after the creation of the attachement. opw-6243256 Forward-Port-Of: odoo/odoo#268595 Forward-Port-Of: odoo/odoo#268285
This update resolves an issue where applying discounts on products with different taxes caused an endless checkout reload. The fix ensures discount lines are grouped correctly, synchronizing the backend and frontend to prevent this frustrating user experience. It improves checkout stability and reliability for customers using varied product tax configurations.
Original PR description
**Step to reproduce :** 1. Create a deliverable product with a sales tax. 2. Create another product with a different sales tax. 3. Publish both products on the eCommerce website. 4. Create a discount…
**Step to reproduce :**
1. Create a deliverable product with a sales tax.
2. Create another product with a different sales tax.
3. Publish both products on the eCommerce website.
4. Create a discount program.
5. Add both products to the shopping cart.
6. Apply the discount code.
7. Proceed to checkout.
**Issue :**
Applying a discount on multiple products with different taxes causes an infinite reload cycle during checkout.
**Reason :**
The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered.
https://github.com/odoo/odoo/blob/18.0/addons/website_sale_loyalty/static/src/js/checkout.js#L22-L24
After the fix introduced in:
https://github.com/odoo/odoo/pull/248215
However, when a discount is applied to products with different taxes, the corresponding reward lines are still categorized as `discounted_lines` instead of `groupable_lines`. As a result, they continue to be processed individually rather than being grouped by reward.
This leads to a mismatch between the backend, which generates one discount line per tax combination, and the frontend, which expects a single discount entry per reward. Consequently, the checkout page continuously reloads while attempting to synchronize both states.
**Solution:**
When a discount applies to products with different tax configurations, the corresponding reward lines should be included in `groupable_lines` rather than `discounted_lines`. This ensures that discount lines are grouped by
`reward_id` consistently on both the frontend and backend, preventing the checkout reload loop.
opw-6210411
Forward-Port-Of: odoo/odoo#265740This update resolves an issue where the timesheet assistant wouldn't function correctly if a rule was created without a template. The fix ensures that all rules now require a template, preventing errors and improving the accuracy of timesheet display names. This enhancement ensures the timesheet assistant operates reliably.
Original PR description
## [FIX] timesheet_grid: make template field required in AW rule Before this commit, the template field in AW rule was not required and if one rule without any template is set, timesheet assistant will not be able to work correctly to build the display name for the key events found. This commit makes sure the template field is required. ## [FIX] timesheet_grid: ignore rules without template defined Before this commit, when the user creates a rule without any template set, the timesheet assistant will no longer work because it assumes the template is required. This commit adds a condition in the domain when we fetch all AW rules, to ignore the ones without template set. Forward-Port-Of: odoo/enterprise#119411
This update fixes an issue in the Swiss payroll module (l10n_ch_hr_payroll) where the activity rate was incorrectly based on individual employee details. Now, the rate is determined by the Odoo version, ensuring accurate calculations and compliance with Swiss tax regulations. This change improves the reliability of payroll reporting.
Original PR description
…ployee Forward-Port-Of: odoo/enterprise#119658
This update strengthens security by restricting access to sensitive financial data within Odoo. Specifically, it prevents unauthorized users from viewing detailed expense information through reinvoicing and analytic distribution searches. Access to these views is now limited to users with appropriate sales, accounting, or invoicing permissions.
Original PR description
Some financial data were visible to users with no access rights through the customer to reinvoice advanced search and analytic distribution search when creating an expense. This commit ensures that these fields in customer to reinvoice advanced search are invisible if the user doesn't have sales nor accounting nor invoicing access rights, it also modifies the debit/credit/balance columns in the analytic distr bution to be visible to users with accounting or invoicing access rights only. task-5993099 Forward-Port-Of: odoo/odoo#262986
This update corrects a previous issue that limited product options when creating sale orders on mobile devices. It now allows users to add products with `sale_ok=False` and non-rental products to rental orders, expanding flexibility. This change resolves a reported regression.
Original PR description
This commit reverts 6e8a2d9c2d80044f6ee33c96871accf0aa83f4eb which introduce regression by ignoring product domain from `_domain_product_id`. Due to this issue, you can add products with `sale_ok=False` in SOL using a phone. Also you could add non-rental product in rental orders. opw-6218312 Forward-Port-Of: odoo/odoo#268331
This update resolves a technical error that prevented PDFs from being attached to invoices when using the Nilvera e-invoice system. The fix ensures that the system correctly handles the raw PDF data returned by the Nilvera client, aligning with how invoices are processed. This ensures invoices with PDF attachments are correctly generated.
Original PR description
This commit resolves an error encountered when running on Python 3.14, which enforces stricter base64 validation. When adding a PDF to the invoice, the PDF is fetched using the Nilvera client. This client performs an HTTP request and returns a raw binary response, not a base64 representation. However, the Attachment interface handles raw binary data via the 'raw' field, whereas the 'datas' field strictly expects base64-encoded values. runbot-938173 Forward-Port-Of: odoo/odoo#266718
This update fixes an issue where the ICP export generated inconsistent XML reports by potentially using values from multiple company contexts. The change ensures a single, consistent company context is used for identifier values, improving the accuracy and reliability of the reports. This resolves potential confusion and ensures compliance with Dutch tax regulations.
Original PR description
Description of the issue this commit addresses: The ICP export could mix values from different company contexts. In some cases, the main identifier and the fiscal entity division value did not come from the same source, which could create confusing or inconsistent XML output. --- Desired behavior after this commit is merged: This commit makes the ICP export use one consistent company context for identifier values, reuses precomputed values when available, and avoids overwriting them with unrelated defaults. --- task-6065382 Forward-Port-Of: odoo/enterprise#119549 Forward-Port-Of: odoo/enterprise#112995
This update fixes a potential issue where state deductions exceeding employee gross income could result in incorrect, negative taxable income calculations on payslips. The change ensures that taxable income defaults to zero in these scenarios, preventing misinterpretations and ensuring accurate payroll reporting. This improves the reliability of US payroll data.
Original PR description
This commit simply defaults the computed taxable income amount to 0 in case the state deductions are greater than their gross income. Otherwise our payslips would imply that these employees are owed money by the state opw-5137280 Forward-Port-Of: odoo/enterprise#104093 Forward-Port-Of: odoo/enterprise#98114
13 changes
Resolved issues and error corrections
This update resolves a bug where the size of country flags on the Visitors reporting page was unexpectedly changing, particularly after installing the livechat app. The fix also ensures that flags correctly respond to size adjustments made through the Studio customization tool, preventing them from disappearing.
Original PR description
The website.visitor.view.kanban view uses the o_country_flag class which is not defined anywhere besides livechat_channel_info_list.scss. This causes unintended behavior where the flag size for the kanban view on ' Website > Reporting > Visitors ' changes when installing the livechat app. Additionally, the image_url_field.js file does not address cases when height/width are not set. This results in the flags (or any other image using 'widget="image_url"' disappearing (being set to a 'width: 0px') whenever their Size is set via Studio. This change makes it so that the flags don't disappear when altered in Studio (but does not make them actually respond to size changes) Related tickets: opw-5962151, opw-5995004 Forward-Port-Of: odoo/odoo#251618
This update resolves an issue where users were locked out of a document list view after attempting to edit a row. The fix ensures the view correctly exits edit mode when a user clicks away, preventing the system from becoming unresponsive. This improves user experience and data access.
Original PR description
Problem: When a user selects a row, attempts to edit a cell, and then clicks away without saving, the view becomes unusable. The selected row remains highlighted, and the system prevents the selection of other lines. The user is locked out until they click the "Save" or "Discard" buttons. Cause: The UI becomes stuck in edit mode. The `onGlobalClick` event handler within `documents_list_renderer` was missing the method call to exit edit mode. Solution: Updated `onGlobalClick` to correctly trigger the method to leave edit mode. task-6059836 Forward-Port-Of: odoo/enterprise#119319 Forward-Port-Of: odoo/enterprise#113000
This update resolves an issue where the IRN (Invoice Reference Number) wasn't being saved when invoices were sent via e-invoicing with email in the Indian localization. The fix ensures the attachment ID is saved correctly, guaranteeing the IRN is included in the invoice data. This improves compliance with Indian e-invoicing regulations.
Original PR description
**Issue**: Sending invoice through e-invoicing with email in Indian localization will not save the IRN number on the invoice because of a cache issue on the attachment id. **Steps to reproduce**: Install l10n_in_edi_gstr module. Create an invoice and send it through e-invoicing with email option. The IRN number will not be saved on the invoice. **Causes**: When sending the invoice through e-invoicing with email option, the attachment id is not saved on the invoice before calling the method _l10n_in_edi_send_invoice(). This causes a cache issue and the IRN number is not saved on the invoice. **Fix**: Save the attachment id on the invoice after the creation of the attachement. opw-6243256 Forward-Port-Of: odoo/odoo#268595 Forward-Port-Of: odoo/odoo#268285
This update resolves an issue where applying discounts on products with different taxes caused an endless reload cycle during checkout. The fix ensures discount lines are correctly grouped by reward, synchronizing the backend and frontend to prevent this disruption and improve the checkout experience.
Original PR description
**Step to reproduce :** 1. Create a deliverable product with a sales tax. 2. Create another product with a different sales tax. 3. Publish both products on the eCommerce website. 4. Create a discount…
**Step to reproduce :**
1. Create a deliverable product with a sales tax.
2. Create another product with a different sales tax.
3. Publish both products on the eCommerce website.
4. Create a discount program.
5. Add both products to the shopping cart.
6. Apply the discount code.
7. Proceed to checkout.
**Issue :**
Applying a discount on multiple products with different taxes causes an infinite reload cycle during checkout.
**Reason :**
The reload is supposed to sync the discount lines in the back-end with the discount lines displayed during checkout. If the number of lines don't match, a reload is triggered.
https://github.com/odoo/odoo/blob/18.0/addons/website_sale_loyalty/static/src/js/checkout.js#L22-L24
After the fix introduced in:
https://github.com/odoo/odoo/pull/248215
However, when a discount is applied to products with different taxes, the corresponding reward lines are still categorized as `discounted_lines` instead of `groupable_lines`. As a result, they continue to be processed individually rather than being grouped by reward.
This leads to a mismatch between the backend, which generates one discount line per tax combination, and the frontend, which expects a single discount entry per reward. Consequently, the checkout page continuously reloads while attempting to synchronize both states.
**Solution:**
When a discount applies to products with different tax configurations, the corresponding reward lines should be included in `groupable_lines` rather than `discounted_lines`. This ensures that discount lines are grouped by
`reward_id` consistently on both the frontend and backend, preventing the checkout reload loop.
opw-6210411
Forward-Port-Of: odoo/odoo#265740This update corrects a previous error in the Swiss payroll module (l10n_ch_hr_payroll) that incorrectly calculated activity rates based on individual employees. Now, the calculation is based on the Odoo version, ensuring accurate reporting and compliance for Swiss payroll requirements. This change improves the reliability of payroll data.
Original PR description
…ployee Forward-Port-Of: odoo/enterprise#119658
This update addresses a slow file preview issue when handling large files. Previously, users experienced a blank screen while a large file downloaded and rendered, leading to a frustrating experience. Now, a loading indicator provides feedback while the preview is being prepared, significantly improving usability.
Original PR description
When previewing a big file, the download might take long and the rendering might take even more time. The UI is blocked until the iframe is ready, but there is no feedback for the user. This commit adds some loading feedback until the iframe is rendered. Steps to reproduce: - Go to a Knowledge article - Upload a file with `/file` - Add a huge JSON file (~30MB) - Save - Click on the file icon => The preview opened but took ages to be displayed without giving any feedback to the user task-6014223 Forward-Port-Of: odoo/odoo#264136
This update fixes an issue where credit notes for returned dropshipped products incorrectly displayed the wrong lot number on invoices. The fix ensures that the correct lot number (the returned one) is shown, improving accuracy and transparency in inventory tracking and reporting. This resolves a discrepancy between the reported lot and the actual returned product.
Original PR description
**Issue** Printing a credit note for a returned dropshipped tracked product could display the wrong lot/serial number on the invoice report. **Steps to reproduce** - Activate "Display Lots & Serial…
**Issue**
Printing a credit note for a returned dropshipped tracked product could display the wrong lot/serial number on the invoice report.
**Steps to reproduce**
- Activate "Display Lots & Serial Numbers on Invoices"
- Create a product tracked by serial/lot and enable the dropship route
- Create two lots: "lot1" and "lot2"
- Create and confirm a SO for quantity 2
- Confirm the PO and validate the dropship for both lots
- Create and post an invoice
- Return "lot2" from the dropship picking
- Create and post a credit note for quantity 1
- Click on print -> The generated PDF displays "lot1" instead of "lot2"
**Cause**
While rendering `account.report_invoice_with_payments`, the report calls `_get_invoiced_lot_values` to determine which lot/serial numbers should be displayed:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L31-L32 `invoiced_qties = 1` since the credit is on a quantity of 1 https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L44 Three stock move lines are retrieved from the SO:
- the two original dropship deliveries,
- the return move for `lot2`. https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L63 However, none of them are considered as `is_stock_return` because the dropship locations use `supplier` instead of `internal`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L72-L76 As a consequence:
- The two original delivery move lines each keep quantity `1`: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L69 they never pass through the return handling logic: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L77-L80 which would make it as -1 (since `qties_per_lot[sml.lot_id]` is 0 for the first iteration of `sml.lot_id`). Thus, it does not pass by this code (since quantity is greater than 0): https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L87-L90 which would make it as 0.
- for the last one, `is_stock_return = False` as it should be, thus the quantity is 1 as it should be. The quantities are therefore accumulated as:
https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L92
resulting in:
`qties_per_lot = {lot1: 1, lot2: 2}`
instead of:
`qties_per_lot = {lot1: 0, lot2: 1}`
The report then selects the first matching lot and stops: https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/sale_stock/models/account_move.py#L94-L99
opw-6230281
Forward-Port-Of: odoo/odoo#266716This update strengthens security by restricting access to sensitive financial data within Odoo. Specifically, it prevents unauthorized users from viewing detailed expense information through reinvoicing and analytic distribution searches. Access to these views is now limited to users with appropriate sales, accounting, or invoicing permissions.
Original PR description
Some financial data were visible to users with no access rights through the customer to reinvoice advanced search and analytic distribution search when creating an expense. This commit ensures that these fields in customer to reinvoice advanced search are invisible if the user doesn't have sales nor accounting nor invoicing access rights, it also modifies the debit/credit/balance columns in the analytic distr bution to be visible to users with accounting or invoicing access rights only. task-5993099 Forward-Port-Of: odoo/odoo#262986
This update corrects a previous issue that limited product options when creating sale orders on mobile devices. It now allows users to add products with `sale_ok=False` and non-rental products to rental orders, expanding flexibility. This change resolves a reported regression.
Original PR description
This commit reverts 6e8a2d9c2d80044f6ee33c96871accf0aa83f4eb which introduce regression by ignoring product domain from `_domain_product_id`. Due to this issue, you can add products with `sale_ok=False` in SOL using a phone. Also you could add non-rental product in rental orders. opw-6218312 Forward-Port-Of: odoo/odoo#268331
This update resolves an issue where moving Odoo databases automatically deregistered subscription codes due to a default database UUID generation. A new `--move` flag has been added to the `odoo db load` command, allowing users to preserve the original UUID during server-to-server database transfers. This ensures continued access to Enterprise subscriptions.
Original PR description
### What & why `odoo db load` always calls `restore_db(..., copy=True)`, which forces the generation of a new `dbuuid` via `ir.config_parameter.init(force=True)`. That is the right default when…
### What & why `odoo db load` always calls `restore_db(..., copy=True)`, which forces the generation of a new `dbuuid` via `ir.config_parameter.init(force=True)`. That is the right default when *duplicating* a database, but it breaks the intended behaviour when *moving* a database between servers: Enterprise subscription codes are registered against the database UUID, so regenerating it deregisters the moved database. The web database manager already lets the user choose between copying and moving (the `copy` flag of the `/web/database/restore` route), but the CLI exposed no equivalent and forced a copy unconditionally. The CLI is the better tool for server-to-server moves: it isn't subject to reverse-proxy upload/timeout limits and can run unattended or interactively. ### Steps to reproduce the current limitation 1. On server A: `odoo db dump mydb mydb.zip` (Enterprise DB registered to its UUID) 2. On server B: `odoo db load mydb mydb.zip` 3. `database.uuid` has changed → the subscription is deregistered ### Fix Add a `--move` flag to `odoo db load` that maps to `restore_db(copy=False)`, keeping the original UUID. The default remains `copy=True`, so existing behaviour is unchanged. ```sh odoo db load mydb mydb.zip # unchanged: restore as a copy (new UUID) odoo db load --move mydb mydb.zip # new: restore as a move (keep the UUID) ``` ### Backport request This would be greatly appreciated as a backport to 18.0, 17.0, and 16.0 as well. Those are precisely the versions that ship the `odoo db` CLI subcommand, so the fix is applicable to all of them — which is why the backport range is 16.0 → 19.0 and stops at 16.0. Forward-Port-Of: odoo/odoo#268501
This change resolves an upgrade issue where the Hungarian chart template reload triggered a failed upgrade due to dependency on external NAV service connectivity. The fix bypasses the credential validation step during the migration, allowing upgrades to proceed without relying on a live NAV connection. This improves upgrade stability and reliability.
Original PR description
Steps to Reproduce: * Create a Hungarian company on 19.0 (or earlier). * Configure NAV credentials through Settings. * Upgrade the database to saas~19.2. Issue: * The upgrade fails while reloading…
Steps to Reproduce:
* Create a Hungarian company on 19.0 (or earlier).
* Configure NAV credentials through Settings.
* Upgrade the database to saas~19.2.
Issue:
* The upgrade fails while reloading the Hungarian chart template.
```python3
Traceback (most recent call last):
File "/home/odoo/src/odoo/saas-19.2/odoo/service/server.py", line 1626, in preload_registries
registry = Registry.new(dbname, update_module=update_module, install_modules=config['init'], upgrade_modules=config['update'], reinit_modules=config['reinit'])
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/odoo/tools/func.py", line 65, in locked
return func(inst, *args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/registry.py", line 202, in new
load_modules(
File "/home/odoo/src/odoo/saas-19.2/odoo/modules/loading.py", line 502, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/saas-19.2/odoo/modules/migration.py", line 215, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, version)
File "/home/odoo/src/odoo/saas-19.2/odoo/modules/migration.py", line 253, in exec_script
mod.migrate(cr, installed_version)
File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu/migrations/3.1/end-migrate_update_taxes.py", line 7, in migrate
env['account.chart.template'].try_loading('hu', company)
File "/home/odoo/src/odoo/saas-19.2/addons/account/models/chart_template.py", line 181, in try_loading
return self._load(template_code, company, install_demo, force_create)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/template_hu.py", line 11, in _load
company._l10n_hu_edi_configure_company()
File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/res_company.py", line 79, in _l10n_hu_edi_configure_company
res_config_id = self.env['res.config.settings'].create({
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/decorators.py", line 363, in create
return method(self, vals_list)
^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/saas-19.2/hr_payroll/models/res_config_settings.py", line 39, in create
return super().create(vals_list)
^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/odoo/orm/decorators.py", line 363, in create
return method(self, vals_list)
^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/res_config_settings.py", line 48, in create
record.company_id._l10n_hu_edi_test_credentials()
File "/home/odoo/src/odoo/saas-19.2/addons/l10n_hu_edi/models/res_company.py", line 107, in _l10n_hu_edi_test_credentials
raise UserError(
odoo.exceptions.UserError: Helytelen NAV hitelesítő adatok! Ellenőrizze, hogy a cég adószáma helyesen van-e beállítva.
Hiba részletei: HTTPSConnectionPool(host='api.onlineszamla.nav.gov.hu', port=443): Max retries exceeded with url: /invoiceService/v3/tokenExchange (Caused by NewConnectionError('<urllib3.connection.HTTPSConnection object at 0x798a970f1fd0>: Failed to establish a new connection: [Errno 111] Connection refused'))
```
Cause:
* Since the introduction of the Hungarian tax migration using `account.chart.template.try_loading('hu', company)` in saas~19.1, upgrades reload the Hungarian chart template.
* When `l10n_hu_edi` is installed, chart template loading triggers `_l10n_hu_edi_configure_company()`, which performs NAV credential validation through `_l10n_hu_edi_test_credentials()`.
* The credential validation performs a live request to the NAV service, making the upgrade dependent on an external service. https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_hu_edi/models/res_company.py#L99-L109 https://github.com/odoo/odoo/blob/saas-19.2/addons/l10n_hu_edi/models/template_hu.py#L11
Fix:
* Bypass NAV credential validation during the migration.
* The migration only updates localization data and does not modify the configured EDI credentials.
* This prevents temporary NAV connectivity issues from aborting the upgrade process.
see https://github.com/odoo/odoo/pull/253556
opw-6253523
upg-4326247
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-prThis update fixes an issue where the growth comparison percentage in financial reports was incorrectly changing when users switched the order of reporting periods. The fix ensures the calculation remains consistent regardless of the period order, providing more reliable growth data. This improves the accuracy of financial reporting.
Original PR description
The feature had originally been implemnted at a time where the period_order couldn't be modified, and always corresponded to what we call 'descending' now. Because of that, we assumed the column at index 0 was always the most recent period ; which caused the growth comparison percentage to change when switching period order. Forward-Port-Of: odoo/enterprise#119212 Forward-Port-Of: odoo/enterprise#118835
This update fixes a reporting issue by now logging a specific message when new business partners are created through Google or Microsoft Calendar synchronization. Previously, all new partners received a generic message. This change provides clearer tracking of partners originating from calendar integrations, aiding in troubleshooting and reporting.
Original PR description
Before we were logging the new created partners default message. Now we log custom message indicating that this partner was created from Calendar sync. task-6177363 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#264392
4 changes
Resolved issues and error corrections
This update corrects a previous issue in the Swiss payroll module (l10n_ch_hr_payroll) that incorrectly calculated activity rates based on individual employees. Now, the calculation is based on the Odoo version, ensuring consistent and accurate reporting for Swiss payroll accounting. This change improves the reliability of payroll data.
Original PR description
…ployee
This update fixes a bug that allowed internal transfer validation to proceed without scanning the destination location for each product. The fix ensures that users receive a notification and are prompted to scan the location before validation, improving data accuracy and preventing incorrect transfers. This resolves a critical issue related to barcode scanning workflows.
Original PR description
Currently, when a user deletes a line and validates internal movement in the barcode system, the system allows validation even though specifying the destination location after each scan is required.…
Currently, when a user deletes a line and validates internal movement in the barcode system, the system allows validation even though specifying the destination location after each scan is required. ## Steps to produce: - Install the Inventory module - Go to Settings and enable Storage Locations. - Inventory > Configuration > Operation Types > Internal Transfers > Barcode App - Configure the Destination Location to require scanning after each product. - Create an Internal Transfer for Pedal Bin, demand 1. - Mark the transfer as To Do and open it in the Barcode app. - Add quantity using +1, then scan the barcode for the Pedal Bin(Barcode: 6016478556493). - Delete the newly added line and attempt to Validate. ## Observed Behavior: The system should prevent transfer validation when the destination location has not been scanned and display a notification to the user, similar to the behavior before user deleted the newly added line. ## Root cause: This issue occurs because when the delete button is pressed, the deleteLine function [1] removes the line, but the deleted line becomes the selected line due to [2] being triggered before the UI updates. As a result, the selected line is now undefined. Since the selected line is undefined, it fails to meet the condition at [3] during validation. This prevents notifications from being triggered and allows the transfer to be validated before the destination location has been scanned. [1]: https://github.com/odoo/enterprise/blob/3476d15bf8e75eb6530658dd623861b60963ab40/stock_barcode/static/src/models/barcode_model.js#L826-L836 [2] : https://github.com/odoo/enterprise/blob/327d4478128f33fb2e0c477533bd4983178abf17/stock_barcode/static/src/components/line.js#L129-L133 [3]: https://github.com/odoo/enterprise/blob/6ff158ca3a6d2d2b3d285a7f8317622844811688/stock_barcode/static/src/models/barcode_picking_model.js#L945-L948 ## Solution: We can prevent users from validating if any line has an unscanned destination location when destination-location scanning is mandatory after scanning each product. To enforce this behavior, we can track whether a line has been modified and whether a destination location has been scanned and applied to that line. This allows us to identify which lines still require destination location scanning before validation can proceed. However, line state information is currently discarded and recreated on every save. As a result, information about lines that were updated and already had their destination location scanned is lost. This may incorrectly require users to rescan the destination location, even though it was previously scanned. To address this, we preserve the destination-scanned and modified state by carrying it forward from existing lines to their corresponding newly created versions using a loop. This ensures that destination location scan status is retained and users are not asked to rescan unnecessarily. opw-6069614 Forward-Port-Of: odoo/enterprise#119363 Forward-Port-Of: odoo/enterprise#113618
This update fixes a bug where credit limit warnings were incorrectly triggered by outstanding bank payments. The system now accurately calculates outstanding balances by including bank payments, ensuring credit limits are displayed correctly and preventing unnecessary warnings. This improves the accuracy of financial reporting and reduces potential customer alerts.
Original PR description
Before this fix: The credit limit warning calculation only considered credit notes but ignored outstanding bank payments when computing the partner's effective outstanding balance. For example, if a…
Before this fix: The credit limit warning calculation only considered credit notes but ignored outstanding bank payments when computing the partner's effective outstanding balance. For example, if a customer had a credit limit of 1,000 and an invoice of 2,000 was created, then a bank payment of 1,500 was received, the warning would still incorrectly appear showing the customer exceeded their limit (2,000 > 1,000), even though the actual outstanding amount was only 500. After this fix: The credit limit warning now properly includes outstanding bank payments in the calculation. Two cases are handled: - Bank payments received but not yet matched to any invoice, these are identified by their open suspense account entry and deducted from the partner's outstanding exposure. - Bank payments already matched to the invoice, the reconciled amount is read from the invoice's receivable line and deducted accordingly. So with this fix, after a 1,500 bank payment, the system correctly recognises the outstanding amount as 500 and does not show a warning since it is within the 1,000 credit limit. task-5427613 Forward-Port-Of: odoo/enterprise#118957
This update addresses a change in how Chrome 148 displays Sundays when using the th_TH locale. The fix adjusts the test to accommodate the browser's Intl API output, ensuring consistent and accurate date formatting for Thai users. This maintains correct date presentation without requiring any new functionality.
Original PR description
Chrome 148 changed the display format for Sundays in the th_TH locale. This commit modifies the test to expect either the full or abbreviated day name, depending on what the browser Intl API actually returns.
4 changes
Resolved issues and error corrections
This update addresses a slow file preview issue when handling large files. Previously, users experienced a blank screen while a large file downloaded and rendered, leading to a frustrating wait. Now, a loading indicator provides feedback to the user while the preview is being prepared, improving the overall experience.
Original PR description
When previewing a big file, the download might take long and the rendering might take even more time. The UI is blocked until the iframe is ready, but there is no feedback for the user. This commit adds some loading feedback until the iframe is rendered. Steps to reproduce: - Go to a Knowledge article - Upload a file with `/file` - Add a huge JSON file (~30MB) - Save - Click on the file icon => The preview opened but took ages to be displayed without giving any feedback to the user task-6014223 Forward-Port-Of: odoo/odoo#264136
This update fixes an issue where certain configuration settings, specifically a 'bin_path' option, weren't being saved to the system's configuration files when using the '--save' command. This change ensures that any custom settings defined in a configuration file are consistently preserved across saves, maintaining the desired system setup. This improves the reliability of the system's configuration.
Original PR description
Have a configuration file with a "bin_path" entry. Use that config file and --save it. The "bin_path" entry is removed from the new config file, it should had been persisted. The problem is common to all "undocumented options", options that did not exist in `config.py` before ConfigCleaner(7) and that were not created upon --save. We can argue about creating or not those options upon --save with the default config, but what's sure is that when the option be set in the config file, then it must be persisted across saves. Task-6106771 Reference-to: 80007415d621 ([REF] core: ConfigCleaner(7) remove deprecated options) 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#258377
This update resolves an issue where moving Odoo databases via the command line would inadvertently deregister subscription codes. The new `--move` flag ensures the database's original UUID is retained during a move, maintaining the user's subscription. This improves the reliability and usability of server-to-server database transfers.
Original PR description
### What & why `odoo db load` always calls `restore_db(..., copy=True)`, which forces the generation of a new `dbuuid` via `ir.config_parameter.init(force=True)`. That is the right default when…
### What & why `odoo db load` always calls `restore_db(..., copy=True)`, which forces the generation of a new `dbuuid` via `ir.config_parameter.init(force=True)`. That is the right default when *duplicating* a database, but it breaks the intended behaviour when *moving* a database between servers: Enterprise subscription codes are registered against the database UUID, so regenerating it deregisters the moved database. The web database manager already lets the user choose between copying and moving (the `copy` flag of the `/web/database/restore` route), but the CLI exposed no equivalent and forced a copy unconditionally. The CLI is the better tool for server-to-server moves: it isn't subject to reverse-proxy upload/timeout limits and can run unattended or interactively. ### Steps to reproduce the current limitation 1. On server A: `odoo db dump mydb mydb.zip` (Enterprise DB registered to its UUID) 2. On server B: `odoo db load mydb mydb.zip` 3. `database.uuid` has changed → the subscription is deregistered ### Fix Add a `--move` flag to `odoo db load` that maps to `restore_db(copy=False)`, keeping the original UUID. The default remains `copy=True`, so existing behaviour is unchanged. ```sh odoo db load mydb mydb.zip # unchanged: restore as a copy (new UUID) odoo db load --move mydb mydb.zip # new: restore as a move (keep the UUID) ``` ### Backport request This would be greatly appreciated as a backport to 18.0, 17.0, and 16.0 as well. Those are precisely the versions that ship the `odoo db` CLI subcommand, so the fix is applicable to all of them — which is why the backport range is 16.0 → 19.0 and stops at 16.0. Forward-Port-Of: odoo/odoo#268501
This update resolves an issue where the commission report displayed empty groups when linked to inactive commission plans. By excluding these plans from the report, the report now accurately shows populated groups, providing a cleaner and more reliable view of commission achievements. This ensures accurate reporting for sales teams.
Original PR description
Steps to reproduce: 1. create a commission plan 2. invoice an SO with the linked salesperson to the plan to progress towards the target 3. Archive the commission plan 4. Go to Sales > Commissions > Commissions 5. Remove all filters The `sale.commission.report` includes empty groups for `sale.commission.achievement.report` that are linked to inactive commission plans By excluding said plans from the initial join, the report would display populated groups only without the clutter. opw-6177132 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#117615
2 changes
Enhancements to existing features
This update enhances the synchronization of sales transactions with Fiskaly, the payment processing system. It separates flows for retail (short transactions) and restaurant (long transactions) to ensure accurate and timely data transfer. This improves the reliability of payment processing and reporting.
Original PR description
In this commit: ------------------ - Maintain separate Fiskaly transaction flows for retail (short tx) and restaurant (long tx) orders as discussed with the Fiskaly team. - `Initialize order…
In this commit: ------------------ - Maintain separate Fiskaly transaction flows for retail (short tx) and restaurant (long tx) orders as discussed with the Fiskaly team. - `Initialize order transactions` with an empty payload when the `first product` is added. - Start `receipt transactions` with an empty payload when the `first payment line` is added. - For retail flows, no intermediate order updates are sent to Fiskaly before finalization. - For restaurant flows, create additional transaction updates during kitchen synchronization. Ensure already synchronized products are not resent, and only newly added or updated quantities are included in the payload. - `Finalize order and receipt transactions` with complete order lines and payment details when we validate the order. task: 6208963 Reference: <img width="1863" height="1285" alt="de_tss_flow" src="https://github.com/user-attachments/assets/9140788e-7948-4a08-9f11-27197b22ca8b" /> Forward-Port-Of: odoo/enterprise#117526
Resolved issues and error corrections
This update ensures that tax details are now included in test orders sent to UrbanPiper. Previously, test orders lacked this crucial information, causing a test failure. The fix involved adding a tax to the discount product in the test environment to ensure consistent behavior across both demo and non-demo setups.
Original PR description
Commit 1: ======== Before this commit: =================== - Test orders sent to UrbanPiper did not include tax details for order items. After this commit: ================== - Tax details are now included in the order item payload of test orders. Task-6013007 --- Commit 2: ======== Cause: ====== In the `without demo` environment, the discount product does not have any `taxes_id`, causing the test assertion to fail. Fix: ==== Set a tax on the discount product in the test to ensure the same behavior in both `with demo` and `without demo` environments. Error-241138
4 changes
New functionality added to Odoo
This update introduces two new demo branches – a Belgian office and a restaurant – within the Odoo Enterprise Belgian payroll module. It includes sample employee data (Bernice Jensen, Ramona Franklin, Eduardo Kelly, Max Durand) to demonstrate payroll processing for different business types. This enhances the demo's realism and usability for testing and training.
Original PR description
Add two branches to the Belgian demo company with their employees: - My Belgian Office (JC 200, cat. 010): Bernice Jensen, Ramona Franklin - My Belgian Restaurant (JC 302, cat. 017): Eduardo Kelly, Max Durand task-6197243
Enhancements to existing features
This update improves the My Planning feature by automatically assigning the current user to a shift when a resource is selected during creation. This simplifies the scheduling process for users, aligning with their typical workflow of self-scheduling. It reduces manual effort and ensures users are immediately associated with the shifts they create.
Original PR description
When creating a shift from My Planning, users are usually scheduling their own work. So it makes sense that they should be automatically assigned to the shift when their resource is selected. task-6178388
This update enhances the timesheet report by standardizing its formatting and presentation across different models. The changes include clearer titles, improved table layout, and adjustments to data display to provide a more user-friendly and informative view of timesheet data, particularly for sales orders and invoices.
Original PR description
In this PR: - formatting the table - displaying 'project & task' or 'project & ticket' for the second column if we are in the context of a specific task/ticket - changed 'total (hours)' into 'total' - Displayed a main 'Timesheets' title at the top of the report then secondary 'ticket: drawer's...' titles above each table - change 'timesheets for the S00080 - Customer Care (Prepaid Hours) Sales Order item' -> 'Order S00080 - Customer Care (Prepaid Hours)' - also for invoices -> changed the title to 'Invoice INV/2024/00021' - hiding the Sales order Item column in all reports if the table belongs to single Sales Order Item - task report > indicate the name of the project in smaller under the name of the task - the generated document should be in landscape instead of portrait mode (so that we have more room to display the different columns) - the column titles should be in bold task-3704612
Features or functions removed from Odoo
This update removes outdated VAT and WHT tax return types from the Odoo Enterprise Pakistan localization. This change aligns the system with current Sales Tax Act requirements, streamlining reporting processes and ensuring compliance. The update was coordinated with related community and upgrade PRs.
Original PR description
As part of the broader restructuring of the Pakistan localization's tax engine to align with the Sales Tax Act, 1990, the percentage-based VAT and WHT tax return types have been removed. Related Community PR: https://github.com/odoo/odoo/pull/264703 Related Upgrade PR: https://github.com/odoo/upgrade/pull/10241 task-6044680
2 changes
Resolved issues and error corrections
This update prevents managers from clearing the assigned manager on card expenses when an expense is approved. The change makes card expenses more reliable by ensuring manager assignments persist, simplifying expense tracking and reducing manual intervention.
Original PR description
**Issue** If a manager was manually set on a card expense after it was created, it would be cleared when the expense was approved. **Change** Make the field readonly for card expenses, the idea is that the manager shouldn't need to approve card expenses since they are able to control them via the card itself. opw-6045587
This update addresses a warning during the Odoo migration process related to account identifiers. The previous attempt to fix this issue was ineffective and has been reverted. This change ensures that account identifiers are correctly available during migration, preventing errors and maintaining data integrity.
Original PR description
This reverts commit 2d4baefedfa4bce570a37195abf5c830517b2435. The commit failed to solve the issue it was trying to solve. In 19.0, accounts a4121 and a4521 were added in the belgian chart template of the community module and are being directly used in the partner template and reco model of the enterprise module. The issue is that during the migration, the xmlids of the freshly created accounts are not available for use that soon and the migration raises warnings for impossible to resolve xmlids. The first fix, the reverted commit, did not successfully solve the error as it targeted the accounts creation instead of the resolving of the xmlids and is now a commit that serves no purpose and complexifies the code with useless logic. See runbot-[233845](https://runbot.odoo.com/odoo/error/233845)
5 changes
Resolved issues and error corrections
This update fixes an issue where discounted vendor bills (UBL format) were incorrectly processed, leading to incorrect quantity and discount calculations. The change ensures that a 'LineExtensionAmount' of 0, representing a 100% discount, is correctly handled, improving the accuracy of imported invoice data.
Original PR description
When importing a Peppol/UBL vendor bill containing a line with a 100% discount, the line was created in Odoo with quantity=1 and discount of 100*original_qty, instead of the expected…
When importing a Peppol/UBL vendor bill containing a line with a 100% discount, the line was created in Odoo with quantity=1 and discount of 100*original_qty, instead of the expected quantity=qty_original and discount=100%. This happened because the line-level branching in `_import_ubl_invoice_line_add_price_unit_quantity_discount` relied on the truthiness of `line_extension_amount` to detect whether the `LineExtensionAmount` node was present in the XML. a line with a genuine `<cbc:LineExtensionAmount>0</...>` was indistinguishable from a line where the node was missing, and fell through to the fallback branch intended for incomplete XML. That fallback reconstructs the quantity from `<cbc:BaseQuantity>`, ignoring `<cbc:InvoicedQuantity>`, and then computes the discount percentage against the wrong denominator. a `LineExtensionAmount` of 0 is the only legal way to express a fully discounted line, so this case must be distinguished from the node being absent. the fix is simply checking if the line exist not if its True opw-6176349 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where purchase order confirmations would fail when a delivery type was configured to not use a warehouse. The fix ensures that the system correctly identifies the final destination location, even when a warehouse isn't associated with the delivery type, preventing a TypeError. This improves the reliability of purchase order processing.
Original PR description
Bug introduced in: https://github.com/odoo/odoo/commit/e2efdf75f67e631ed7622bb01c127120e639f6c5 Steps to reproduce: Clear the Warehouse field (set it to False) Create a purchase order Set "Deliver…
Bug introduced in: https://github.com/odoo/odoo/commit/e2efdf75f67e631ed7622bb01c127120e639f6c5
Steps to reproduce: Clear the Warehouse field (set it to False) Create a
purchase order Set "Deliver To" to the operation type with no warehouse
Add any product Confirm the PO → TypeError is raised
Steps to reproduce the bug:
- Have at least 2 warehouses
- Go to Inventory > Configuration > Operation Types > Receipts
- Clear the Warehouse field (set it to False)
- Create a purchase order:
- Set "Deliver To" to the operation type with no warehouse
- Add any product
- Try to confirm the PO
Problem:
A traceback is triggered:
``` return self.parent_path.startswith(other_location.parent_path)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: startswith first arg must be str or a tuple of str, not bool
```
`_get_final_location_record` computes `wh_stock_loc` from
`picking_type_id.warehouse_id.lot_stock_id`. When `warehouse_id`
is False (a valid configuration, operation types can be detached from
any warehouse), `lot_stock_id` short-circuits to False
Solution:
guard the _child_of call with not wh_stock_loc. When the
picking type has no warehouse, wh_stock_loc is falsy and there is
nothing to compare against, so the method falls back to
default_location_dest_id (the only destination available).
opw-6253817This update prevents Odoo from generating empty ICS calendar files when users attempt to add open shifts to their calendars. Previously, an empty file was created when a matching time slot wasn't found, which caused confusion. Now, the ‘Add to Calendar’ button is hidden and ICS files are only generated when a valid shift is linked to an employee.
Original PR description
**Step:** - install planning - create a resource - create an open shift for a future date - in Gantt view: - publish shift and select the created resource - click “Publish & Send” - check the email and click “Add to Calendar” **Issue:** Currently, clicking “Add to Calendar” generates an empty ics file. **Reason:** During ics file generation, the planning token to find a slot using the planning date and employee. but, no matching slot is found, so the process returns an empty slot, resulting in an empty ics file. **Fix:** Generate the `planning_url_ics` only when a slot is linked with an employee. Otherwise, hide the “Add to Calendar” button and do not generate the ics file.
This update resolves an issue where the French VAT report generation incorrectly included " False" in XML files when the street address was short and 'street 2' was not used. This prevented the reports from processing correctly. The change ensures accurate XML output for French VAT reports, improving report generation reliability.
Original PR description
When the street field is shorter than 30 char and street 2 is false, we end up with " False" in the xml, which will return an error in aspone. no task id
This update fixes an error in the Colombian DIAN invoice processing that incorrectly flagged invoices due after 5 PM Bogota time. The change ensures the system uses local Bogota time for date calculations, resolving a validation issue and improving the accuracy of DIAN reporting. This prevents delays and errors when submitting invoices.
Original PR description
**Steps to reproduce:** * Install `l10n_co_edi` module with DEMO DIAN mode enabled. * Go to Accounting > Vendor > Bills and create a new bill. * Select any Colombian partner different from…
**Steps to reproduce:** * Install `l10n_co_edi` module with DEMO DIAN mode enabled. * Go to Accounting > Vendor > Bills and create a new bill. * Select any Colombian partner different from `Consumidor Final`. * Set the invoice date to 6 days in the past. * Select the DIAN Support Documents journal and a product with UNSPSC category. * Confirm the bill and click `Send Support Document to DIAN` after 5 PM Colombia time. **Observed behavior:** * An error is raised stating the issue date cannot be older than 6 days or more than 6 days in the future, even though the invoice date is within the allowed window in Colombia local time. **Cause:** * The date window validation in `_check_move_configuration` used `fields.Datetime.now()` which returns UTC time. Since Colombia is UTC-5, after 5 PM local time the UTC clock has already rolled over to the next calendar day, making a 6-day-old invoice appear 7 days old and failing the validation incorrectly. **Fix:** * Convert the current UTC datetime to the `America/Bogota` timezone and extract its local date before computing the allowed date window. * Compare directly against `move.invoice_date` (a `date` field) instead of using `fields.Datetime.to_datetime()`, keeping the comparison consistent as `date` vs `date`. opw-6011502
7 changes
Resolved issues and error corrections
This update resolves an issue where international UPS shipments were failing due to incorrect commercial invoice addresses. The fix now uses the delivery address for the invoice, but a fallback mechanism is in place to handle country mismatches, along with a user warning to ensure accuracy. This ensures compliant UPS shipments and avoids delivery delays.
Original PR description
Issue ----- When making an international delivery to a partner with different invoice and delivery addresses, we send the delivery address as the `Sold To` address as well. Problematic case 1 ----- -…
Issue ----- When making an international delivery to a partner with different invoice and delivery addresses, we send the delivery address as the `Sold To` address as well. Problematic case 1 ----- - Create a belgian company - Setup UPS - Create a French customer - Add a different french delivery address - Create a product (with some weight) - Create a SO (with UPS delivery) to the customer & confirm - Validate the transfer > Commercial invoice `Sold To` uses the delivery address Solution for case 1 ----- Use the delivery address' `commercial_partner_id`. This leads to another issue in some edge cases... Problematic case 2 (caused by case 1 fix) ----- - Create a belgian company - Setup UPS - Create a French customer - Add a delivery address in Switzerland - Create a product (with some weight) - Create a SO (with UPS delivery) to the customer & confirm - Validate the transfer > UPS error `The Sold To party's country code must be the same as the Ship To party's country code with the exception of Canada and satellite countries.` Solution for case 2 ----- Default back to delivery address for the `Sold To` field when countries don't match, as this is a limitation of the UPS API. Warn the user, either on the SO or the transfer itself (if no SO). Warning looks like this (on SO): <img width="1914" height="716" alt="image" src="https://github.com/user-attachments/assets/f7aa73c4-f24c-42da-8f3e-6a58765ef020" /> ----- Ticket: opw-6200263
This update removes a specific message from invoices when they aren't sent via PEPPOL, which was inappropriate for Business-to-Consumer (B2C) customers. By removing this footer for invoices with empty or '/' VAT numbers, we ensure a cleaner and more professional experience for our B2C clients.
Original PR description
Currently, if the invoice was not sent through PEPPOL, it is indicated in the mail footer. However, this message is not appropriate for B2C customers. To avoid this, we remove this footer for customers with empty or '/' VAT (B2C). task-6167439
This update simplifies invoice sending by no longer automatically selecting the 'By Peppol' method for customers in Greece, Italy, Poland, Puerto Rico, and Romania. Previously, this setting was incorrectly applied to these countries, causing unnecessary complexity for users. Now, the 'By Peppol' method will only be used for customers in designated default countries.
Original PR description
Current behavior before PR: - If the customer has a valid Peppol endpoint, the 'By Peppol' invoice sending method is selected by default. - For countries like 'GR,' 'IT,' 'PL,' 'PO,' and 'RO,' peppol is not mandatory or not used for sending invoice. It brings noise and it bothers the users. Desired behavior after PR is merged: - The 'By Peppol' invoice sending method is set to true by default only for customers from PEPPOL_DEFAULT_COUNTRIES. Changes Implemented: - Moved the countries 'GR', 'IT, 'PL', 'PO', and 'RO' from PEPPOL_DEFAULT_COUNTRIES to PEPPOL_LIST. - Added condition to set 'By Peppol' invoice sending method to true when customer is from PEPPOL_DEFAULT_COUNTRIES. task-6072935
This update fixes a warning related to how Odoo generates PDFs using the PyPDF library. The change ensures the PDF generation process is compatible with newer versions of PyPDF, preventing potential errors and maintaining stable PDF output. This improves the reliability of our PDF reports.
Original PR description
In recent versions of PyPDF, modifying a `PageObject` directly from a `PdfFileReader` instance triggers a `PageObject.replace_contents` deprecation warning. As identified in the pypdf library's architecture updates (specifically PR #3638 [^1] and PR #3669 [^2]), a reader's page is intended to be read-only. Mutating it directly (e.g., using `mergePage` or `compressContentStreams`) before attaching it to a writer can break internal object references and cause `NullObject` errors. This commit resolves the warning by inverting the order of operations to ensure we only mutate writable objects. The fix implements the following flow: 1. Add the unmodified source page directly to the `PdfFileWriter`. 2. Retrieve the newly created, writable output page. 3. Apply `mergePage` and `compressContentStreams` exclusively to the writer's copy of the page. [^1]: https://github.com/py-pdf/pypdf/pull/3638 [^2]: https://github.com/py-pdf/pypdf/pull/3669
This update fixes a bug that caused duplicate vendor bills to be created when importing XML bills with identical filenames. The issue stemmed from incorrect attachment linking during the initial document creation process. This ensures accurate bill generation and avoids redundant records.
Original PR description
Fixup of https://github.com/odoo-dev/odoo/commit/3fc85b6ed7936956abbaf8e8364bb2b288cbe289 Issue 1 - Import XML bill into documents app - Create vendor bill from the document Issue: Only the main attachment would be found in the created bill opw-6267888 Issue 2 - From the accounting app import XML bill containing two identically named documents Issue: Two bills were created opw-6231265
This update fixes an issue where users without HR access rights were seeing a placeholder image instead of their avatar in the timesheet kanban view. The fix ensures all users can see their avatar, improving the user experience and visual consistency within the HR timesheet module.
Original PR description
Steps to reproduce: ------ - Install the hr_timesheet module - Create a user without HR access rights - Create a timesheet - Log in with the above user - Open the kanban view Issue: ------- Instead of showing the employee's avatar, a placeholder image is displayed. Reason: --- The user does not have access to the hr.employee model. Fix: -------- In this commit, if the user does not have access to hr.employee, we fetch the image from the hr.employee.public model. task: 4461272
This update resolves an issue preventing users from sending Peppol invoices in demo mode. The change allows the system to assume any document type is acceptable during demo, bypassing the usual partner acceptance checks. This ensures seamless testing and demonstration of the Peppol integration.
Original PR description
1. Activate Peppol Demo; 2. Enable "Self-Billing" on the purchase journal; 3. Create a bill and send it via Peppol; 4. Error message: "The partner has indicated it does not accept this document type, so you cannot send this invoice via Peppol". In _peppol_lookup_participant we always return None if we are in demo mode. For the _can_receive_self_billing, we will assume that in demo mode, the partner can accept any document type. opw-6250067 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