Daily updates from Odoo
Tuesday, March 31, 2026
132 changes
25 changes
Resolved issues and error corrections
This update resolves an inconsistency in the tax report when creating vendor bills with mixed vehicle and non-vehicle expense lines. The fix allows for accurate reporting by relaxing a strict matching rule that previously flagged these lines as inconsistent. This ensures all tax calculations are correct.
Original PR description
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other…
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other without a vehicle. * Confirm the vendor bill. * Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report. **Observed behavior:** * The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.' **Cause:** * The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`. * When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`. * The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency. **Fix:** * Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set. * If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines. opw-5956645 Forward-Port-Of: odoo/enterprise#112313 Forward-Port-Of: odoo/enterprise#110616
This update resolves an issue where documents couldn't be opened after their names were changed. The fix corrects a technical error in the document handling system, ensuring that renamed documents can now be successfully opened. This improves the reliability of the documents feature for all users.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Open a document in full screen and click on info icon on top right 3. Edit the name and close full screen document and chatter 4. Try to open the same document Issue: - Traceback occures `TypeError: Cannot read properties of undefined (reading 'insert')` Cause: - In file document_service `this.store.Attachment` was used instead of `this.store["ir.attachment"]` After this commit https://github.com/odoo/odoo/commit/70153559c34ffd18c67b83c39ee397ecb0a90b4a we renamed the Attachment model opw-5483625 Forward-Port-Of: odoo/enterprise#110315 Forward-Port-Of: odoo/enterprise#105602
This update fixes a problem where the system would generate an error and fail to create PDF files when users uploaded empty XML documents. The change skips PDF extraction when raw data is missing, ensuring that PDF files are consistently generated and preventing errors.
Original PR description
Currently an error is generated and the file is not generated when the user uploads an empty XML file (e.g., ref file [1]). Error: `AttributeError: 'bool' object has no attribute 'decode'` This error occurs because the uploaded file contains no raw data. As a result, the system fails to retrieve the file content during PDF extraction from the XML at line [2]. This commit fixes the issue by skipping PDF extraction from the XML when the document has no raw data. The process now returns False early if the document contains no raw content. [1]: https://drive.google.com/file/d/1hRbgEsTL-iWhiAO245z_10HRH6nh3rUQ/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/documents_account/models/documents_document.py#L52 sentry-7173452999 Forward-Port-Of: odoo/enterprise#103801
This update corrects a technical issue related to how the suspense line is calculated in the account accounting module. The change ensures the suspense line is always a valid object, preventing a validation error. This resolves a potential instability in the system.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/ec7299e39c5b89cea86e4dda34894958c560663e change the way the suspense line is computed, and we expect the suspense line to be an object. But since this commit, the suspense line getter can give False the props validator will fail. no task id Forward-Port-Of: odoo/enterprise#112481
This update resolves an issue preventing SBR tax reports from submitting correctly. The commit restores the correct date format and limits the consultant name description to ensure compliance with validation requirements. This ensures accurate tax reporting and avoids submission failures.
Original PR description
Description of the issue this commit addresses: During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible. [^1]: https://www.odoo.com/odoo/967/tasks/6034675 --- Desired behavior after this commit is merged: This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description. [^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie --- task-none Forward-Port-Of: odoo/enterprise#112216 Forward-Port-Of: odoo/enterprise#111817
This update resolves a bug where commission calculations were incorrectly defaulting to 0% when the target completion was set to 0%. The fix ensures that commissions are accurately calculated when the target amount is zero, addressing a previous inconsistency in the system.
Original PR description
Before this commit, when target completion was 0% and the commission was equal to X (where X is not null), the commission could not be equal to X. It would be equal to 0. It was working with target amount equal to 0. Forward-Port-Of: odoo/enterprise#112337
This update fixes an issue where the canteen cost was incorrectly calculated for Belgian employees, even when they had no attendance recorded. The fix ensures that the canteen cost is only applied if the employee has earned money through attendance during the payslip period, preventing incorrect charges.
Original PR description
[FIX] l10n_be_payroll: fix canteen cost computation
Bug reproduction: belgium company -> create a new employee -> new contract (payroll wage > 0) -> canteen_cost = 50 -> create payslip -> allocate time off for full month (such that there will be no attendance) -> recompute payslip -> still canteen cost is calculated
Bug cause:
1 - If l10n_be_canteen_cost is > 0 it was computing the canteen cost line for sure
2 - If result_rules['BASIC']['total'] is > 0 then the canteen cost was 50.
Bug solution:
1 - I add worked_days['WORK100'].amount != 0 to the computation condition.
2 - If there is any earned money from attendance or working in that payslip duration, the canteen cost should be deducted completely
3 - If the employee is absent during the payslip, the employee should not pay the canteen cost.
task - 6045406
Forward-Port-Of: odoo/enterprise#112462
Forward-Port-Of: odoo/enterprise#110991This update resolves a technical issue that caused the Invoicing dashboard to display a traceback error for certain companies. The fix ensures that the system gracefully handles companies without Stripe configured, preventing errors and maintaining dashboard functionality. This improves the user experience for all users.
Original PR description
Steps to reproduce: 1. Install `l10n_ar`. 2. Switch to an AR company. 3. Open the Invoicing dashboard. Issue: Opening the dashboard raises a traceback: `ValueError: Expected singleton: res.currency()` Cause: When Stripe is not configured on the company, `stripe_currency_id` is empty, leading to an invalid currency recordset during formatting. Fix: Fallback to the company currency when `stripe_currency_id` is not set. opw-6049551
This update resolves a critical issue causing receipt generation errors when sending invoices to DIAN (Colombian tax authority). The fix corrects a problem with relative URLs in QR code generation and addresses an outdated code path that was also causing crashes. This ensures accurate receipt creation and compliance with DIAN requirements.
Original PR description
1. When generating the full receipt for a pos order sent to DIAN the receipt generation crashes because the qr code url is a relative path, which makes wkhtmltopdf crash. 2. For invoiced pos orders we were still using old code which would also crash because the `'barcode_src`' key is not returned by `_l10n_co_dian_get_extra_invoice_report_values` anymore
This update resolves a technical issue related to the EU IoT scale certification driver. Following a recent fix to the scale driver, a corresponding checksum update is required to ensure data integrity and compliance. This change is a routine maintenance task.
Original PR description
As we fixed the scale driver, we need to update the checksum. see odoo/odoo#256816
This update fixes an issue where scanning a different serial number than the reserved one during batch processing didn't create a new lot. The fix ensures that the correct lot is always used when scanning a batch, preventing incorrect inventory tracking. This improves the reliability of batch operations.
Original PR description
Issue ----- When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken…
Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.
Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
- Enable Lots/Serial Numbers > Create New
- Create a product
- Barcode 23456789012344
- Tracked by SN
- 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details
> The line used the reserved SN
Cause
-----
The existing line gets matched in `_findLine`
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085
because none of the conditions before
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402
get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.
Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).
-----
Ticket:
opw-5216921
Forward-Port-Of: odoo/enterprise#112210
Forward-Port-Of: odoo/enterprise#109671This update corrects a technical error in the E-Commerce Reporting module (l10n_eg_iot) where a controller was referencing outdated code from a previous Odoo version. This fix ensures the reporting functionality is working correctly and prevents potential disruptions to business processes. It's a routine maintenance update.
Original PR description
`iot_box_setup` override is still calling the previous method names, mistakenly fw ported from 19. This commit fixes it. Forward-Port-Of: odoo/enterprise#112451
This update resolves a previous issue where users interacting with the AI through the file viewer would receive error messages. The fix ensures the correct file ID is passed to the AI, allowing seamless interaction with documents. Additionally, improvements were made to the AI's handling of images to ensure stable performance.
Original PR description
Before this commit, whenever a user tried to interact with the ai regarding a document opened in the file viewer, they would get a traceback with a 404 error. This was caused by the file id that we passed in the `openAIChat` method of the `AIChatLauncher` service. The id is negative on purpose by the documents team - there is a comment stating that it "prevents a reload from resolving to a real record". Also, the id doesn't reflect the attachment_id, but rather another id dedicated to the file_viewer. On the AI side, when using the id to search for the attachment to send to the AI, we get an error because the id is negative. This bubbles up to the user. We fix this by replacing the `this.file.id` with the `this.file.documentData.attachment_id.id` which is the correct value of the id associated with this document's attachment. Task-6030598 Forward-Port-Of: odoo/enterprise#111167
This update resolves a technical issue within the Bank Reconciliation widget that could cause errors when deleting counterpart lines in bank transactions. The fix ensures the system correctly handles data, preventing unexpected errors and improving the reliability of bank reconciliation processes. This change was triggered by internal testing and development.
Original PR description
The `get suspenseAccountLine`` method could return False, which is not valid for the BankRecButtonList component props. This commit ensures the method returns either an object or undefined. Step to reproduce: - Enable developer mode - Open the Bank Reconciliation widget - Create a bank transaction - Reconcile the transaction - Click on the trash icon on the counterpart line - Previously, a traceback would occur due to invalid props opw-6012604 opw-6066531 opw-6066116 opw-6065924 opw-6063884 opw-6062905 opw-6062590 opw-6060781 Forward-Port-Of: odoo/enterprise#112546 Forward-Port-Of: odoo/enterprise#112175
This update resolves an issue where removing a product from an order (SO/PO/Invoice) didn't correctly update the order line. The fix ensures the correct section ID is used, preventing incorrect updates. Additionally, a related test tour was failing, which has been addressed by adding a wait for the catalog to fully initialize before asserting prices.
Original PR description
Steps to reproduce: 1. Create a new SO/PO/Invoice and add a product. 2. Add a new section below the product. 3. Open the catalog and click the Remove button for the added product. Issue: - The…
Steps to reproduce: 1. Create a new SO/PO/Invoice and add a product. 2. Add a new section below the product. 3. Open the catalog and click the Remove button for the added product. Issue: - The product is not removed from the SO/PO/Invoice. Cause: - When removing the product, the 'No section' entry is also removed if it becomes empty. - As a result, `this.env.searchModel.selectedSection.sectionId` point to the first remaining section in the order. - Because of this incorrect reference, the wrong `section_id` is passed in the params, and `update_order_line_info` does not update the intended order line. Fix: - Use `this.env.selectedSectionId` instead of `searchModel.selectedSection.sectionId` to ensure the correct `section_id` is always passed. After applying this fix, `test_catalog_vendor_uom` tour was failing because in tour execution the kanban records are mounted before the search panel finishes initializing the selected section. As a result, the initial section state is not yet stabilized when the price is asserted. To address this: - Update the tour to explicitly wait until the "No section" entry is marked as selected in the search panel before asserting the product price, ensuring the catalog is fully initialized. opw-5960140 Forward-Port-Of: odoo/odoo#250103
This update corrects a previous inconsistency in how sections are handled within Odoo's sale order system. Previously, the behavior of optional sections and hidden sections differed between sale orders and their templates. This change ensures that these settings are consistently applied across all sales order types, improving usability and reducing potential errors.
Original PR description
This commit fixes inconsistencies between section behavior in sale orders and sale order templates. In sale orders: * A section cannot be marked as optional if it is hidden, and vice versa. * Moving an optional subsection into a hidden section resets its optional state. * Enabling 'hide composition' on a section resets the optional state of its subsections. These rules were not consistently enforced in sale order templates, leading to mismatched behavior. This commit aligns template logic with sale order behavior to ensure consistency across both. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256567
This update fixes an issue where Italy's chart of accounts was defaulting to incorrect expense and revenue accounts. The change explicitly sets the correct Italian deferred accounts (`190200` and `270200`) within the chart template, ensuring accurate financial reporting for Italian businesses.
Original PR description
Italy's chart template did not explicitly define deferred expense and revenue accounts, so deferred accounts fell back to the first `asset_current` and `liability_current` accounts in the chart. That could assign incorrect defaults such as `140100` and `220100`. This patch sets the intended Italian deferred accounts to `190200` and `270200` directly in the template to ensure correct configuration during chart loading. task-6076711 Forward-Port-Of: odoo/odoo#256623
This update ensures the 'Looking for Help' timer is consistently displayed to live chat agents, regardless of whether they're already involved in the conversation. Previously, the timer was hidden when an agent joined, hindering their ability to track service level agreements. This fix corrects a server-side issue, guaranteeing accurate timer calculations and improving agent efficiency.
Original PR description
**Description of the issue this PR addresses:** Ensure the `Looking for Help` timer is shown even when the current user is already a member of the livechat channel. **Steps to Reproduce:** 1. Log in…
**Description of the issue this PR addresses:** Ensure the `Looking for Help` timer is shown even when the current user is already a member of the livechat channel. **Steps to Reproduce:** 1. Log in as a visitor and as Mitchell Admin (Live Chat operator). 2. From the visitor side, select I have a pricing question. 3. From the admin side, mark the conversation as Looking for Help. 4. The channel appears in the Looking for Help category. 5. Observe that the timer should be visible there (e.g., 1m). **Current behavior before PR:** - The timer was hidden when an agent was already a member of the conversation, assuming that once an agent joined, the `waiting for help` phase was over. - However, in escalation workflows an analyst may escalate a chat and remain a member while the channel returns to the `Looking for Help` state for another expert. In this case, the escalating analyst could not see the timer needed to track SLA requirements (e.g., creating a ticket after 10 minutes). - Also, the mock server did not recompute `livechat_looking_for_help_since_dt` when `livechat_status` changes, leading to incorrect timer values (e.g., showing 2d instead of < 1m after switching back to Looking for Help). **Desired behavior after PR is merged:** - The timer is displayed whenever the channel is in `need_help` and `livechat_looking_for_help_since_dt` is set, regardless of whether the current user is a member of the channel. - The mock server now mirrors server-side behavior by updating `livechat_looking_for_help_since_dt` when livechat_status changes, prevents missing recomputations and ensuring consistent test behavior. task-[6009851](https://www.odoo.com/odoo/project/1519/tasks/6009851) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252738
This update ensures that when creating new analytic items from the gross margin smart button, the correct analytic account is automatically selected by default. Previously, new items weren't linked to an account, requiring manual setup. This change streamlines the process and improves data accuracy for analytic reporting.
Original PR description
When accessing analytic items from the gross margin smart button on an analytic account, creating a new record does not pre-fill the analytic account field. This happens because the context does not set `default_account_id` for the active analytic account, leading to newly created lines not being linked at creation time. This commit ensures the analytic account is correctly passed through the context, so it is automatically set when creating a new analytic line from this flow. Steps to reproduce: - Open an analytic account - Click on the gross margin smart button - Create a new analytic item Before: analytic account not set by default After: analytic account is pre-filled via context task-3909624 Forward-Port-Of: odoo/odoo#256426 Forward-Port-Of: odoo/odoo#255726
This update resolves a technical glitch that was causing a test tour to fail during product catalog setup. The fix ensures the correct section ID is always used, preventing errors and improving the reliability of the product selection process. This ensures a smoother experience for users adding products to their orders.
Original PR description
Cause: The `selectedSectionId` was not yet updated in the environment when the product was added, resulting in a `None` value being passed to `_update_order_line_info`. Fix: Use `this.env.selectedSectionId` when available, and fall back to `this.env.searchModel.selectedSection.sectionId` only if it is undefined or null. runbot-241960 Forward-Port-Of: odoo/odoo#254374
This update resolves an issue where credit notes created through 'Reverse and create invoice' didn't correctly show the original invoice's source information. The fix ensures that the source document is accurately reflected in the generated invoice PDF, improving reporting and traceability. This ensures consistent financial record keeping.
Original PR description
### Issue before this commit: When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source,…
### Issue before this commit: When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source, the new invoice created after reversal does not, leading to missing information in the report. ### Steps to reproduce the issue: 1. Create a sales order for product A 2. Deliver product A 3. Create invoice 4. Create credit note by clicking on "Reverse and create invoice" 5. The new invoice correctly remains linked to the Sales order 6. However, the source document disapear on the PDF ### Cause of the issue: In the reversal flow, the new invoice is created using copy_data() without explicitly preserving the invoice_origin field. As a result, the newly created invoice does not inherit the source information from the original invoice, even though it is still logically linked. ### Reason to introduce the fix: To ensure consistency between invoices and preserve important traceability information, the invoice_origin field must be propagated to the new invoice created during the reversal process. This guarantees that the Source is correctly displayed in the PDF. opw-6034574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256284 Forward-Port-Of: odoo/odoo#254290
This update fixes a technical issue where the removal of certain tags from Odoo's core reporting system wasn't reflected in the import file. This ensures that the import process correctly reflects the latest changes to Odoo's reporting functionality. It's a minor update focused on data consistency.
Original PR description
`<report>` and `<act_window>` tags has been removed in https://github.com/odoo/odoo/pull/98138, but not in the import_xml.rng file. This commit removes the two tags from the file. Forward-Port-Of: odoo/odoo#220116
This update resolves an issue where default account settings for Swiss businesses in Odoo were incorrectly configured. The change sets clean, accurate default values, ensuring proper accounting and reporting for Swiss users. This improves the reliability and accuracy of financial data.
Original PR description
[IMP] l10n_ch: Set default accounts in Switzerland Some defaults accounts in Switzerland were misconfigured, this commit set clean values by default task-6043978 Forward-Port-Of: odoo/odoo#255350
This update addresses a sporadic validation error that occasionally occurred when managing users within the settings. The issue stemmed from a conflict in how employee data was linked, preventing users from being added correctly. This fix ensures a stable and reliable user management experience.
Original PR description
## Short functional explanation of the error When in settings, we click on Manage users, we sometimes get a validation error. ## Reproduction Steps 1. Go to settings. 2. Click on Manage Users. ###…
## Short functional explanation of the error When in settings, we click on Manage users, we sometimes get a validation error. ## Reproduction Steps 1. Go to settings. 2. Click on Manage Users. ### Expected behavior The list of users is displayed. ### Unexpected behavior Sometimes (around 20% of the time), we get the error: ``` Validation Error The operation cannot be completed: A user cannot be linked to multiple employees in the same company. ``` ## Origin of the issue This validation error is triggered due to a psycopg2 constraint error. Indeed, it occurs because the code tries to create an employee for the current user, when an employee for this user already exists: https://github.com/odoo/odoo/blob/35da8c4d8e86a752cc76d275463a752039465984/addons/pos_hr/models/pos_config.py#L27-L30 In our case, the `group_users` only contains the admin user. This user has an existing corresponding employee in the field `employee_ids`, but not in `employee_id`. __ opw-6066533 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
We've been experiencing an increase in failed payments due to an issue with Flutterwave. This update corrects the way phone numbers are sent to Flutterwave, aligning with a recent change in their API requirements. This resolves the 'invalid billToPhone' error and ensures smoother payment processing.
Original PR description
With are recently seeing an increasing number of payments that fail with an `invalid billToPhone` error. It's unclear if it's a recent change of flutterwave API or of any intermediary payment processor, but the flutterwave v4.0.0-beta API now state to send the phone number "unformatted" - even if there is no such statement for the v3.0.0 API (that we are using), based on testing, sending the phone number "unformatted" do so seems do solve the issue. So this commit, sanitize the phone number to send it unformatted. opw-6074825 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256478 Forward-Port-Of: odoo/odoo#256315
21 changes
Resolved issues and error corrections
This update resolves an issue where documents couldn't be opened after their names were changed. The fix corrects a technical error in the document handling system, ensuring documents can now be reliably opened even after being renamed. This improves the overall usability of the documents feature.
Original PR description
Steps to reproduce: 1. Install `documents` 2. Open a document in full screen and click on info icon on top right 3. Edit the name and close full screen document and chatter 4. Try to open the same document Issue: - Traceback occures `TypeError: Cannot read properties of undefined (reading 'insert')` Cause: - In file document_service `this.store.Attachment` was used instead of `this.store["ir.attachment"]` After this commit https://github.com/odoo/odoo/commit/70153559c34ffd18c67b83c39ee397ecb0a90b4a we renamed the Attachment model opw-5483625 Forward-Port-Of: odoo/enterprise#110315 Forward-Port-Of: odoo/enterprise#105602
This update resolves an issue where the system would generate an error and fail to create PDF files when users uploaded empty XML files. The fix skips PDF extraction when raw data is missing, ensuring consistent file generation and preventing disruptions to the document processing workflow.
Original PR description
Currently an error is generated and the file is not generated when the user uploads an empty XML file (e.g., ref file [1]). Error: `AttributeError: 'bool' object has no attribute 'decode'` This error occurs because the uploaded file contains no raw data. As a result, the system fails to retrieve the file content during PDF extraction from the XML at line [2]. This commit fixes the issue by skipping PDF extraction from the XML when the document has no raw data. The process now returns False early if the document contains no raw content. [1]: https://drive.google.com/file/d/1hRbgEsTL-iWhiAO245z_10HRH6nh3rUQ/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/documents_account/models/documents_document.py#L52 sentry-7173452999 Forward-Port-Of: odoo/enterprise#103801
This update resolves an issue where a validation check for the suspense line was failing due to a change in how the suspense line is calculated. The update ensures the suspense line is correctly formatted, preventing potential errors in the system's financial reporting. This ensures accurate data processing.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/ec7299e39c5b89cea86e4dda34894958c560663e change the way the suspense line is computed, and we expect the suspense line to be an object. But since this commit, the suspense line getter can give False the props validator will fail. no task id Forward-Port-Of: odoo/enterprise#112481
This update corrects an issue preventing the SBR tax reports from being submitted correctly. Specifically, it restores the correct date format and ensures the consultant information is displayed concisely, resolving validation errors. This ensures compliance with tax reporting standards.
Original PR description
Description of the issue this commit addresses: During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible. [^1]: https://www.odoo.com/odoo/967/tasks/6034675 --- Desired behavior after this commit is merged: This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description. [^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie --- task-none Forward-Port-Of: odoo/enterprise#112216 Forward-Port-Of: odoo/enterprise#111817
This update fixes an issue where barcode scanning with a different serial number than the reserved one didn't create a new lot in stock. The fix ensures that the correct lot is always used when scanning a batch, preventing incorrect inventory tracking. This improves data accuracy and reliability within the stock management system.
Original PR description
Issue ----- When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken…
Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.
Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
- Enable Lots/Serial Numbers > Create New
- Create a product
- Barcode 23456789012344
- Tracked by SN
- 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details
> The line used the reserved SN
Cause
-----
The existing line gets matched in `_findLine`
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085
because none of the conditions before
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402
get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.
Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).
-----
Ticket:
opw-5216921
Forward-Port-Of: odoo/enterprise#112210
Forward-Port-Of: odoo/enterprise#109671This update resolves a technical issue within the Bank Reconciliation widget that could cause errors when deleting counterpart lines in bank transactions. The fix ensures the system correctly handles data props, preventing unexpected errors and improving the stability of the reconciliation process. This change impacts the Bank Reconciliation feature.
Original PR description
The `get suspenseAccountLine`` method could return False, which is not valid for the BankRecButtonList component props. This commit ensures the method returns either an object or undefined. Step to reproduce: - Enable developer mode - Open the Bank Reconciliation widget - Create a bank transaction - Reconcile the transaction - Click on the trash icon on the counterpart line - Previously, a traceback would occur due to invalid props opw-6012604 opw-6066531 opw-6066116 opw-6065924 opw-6063884 opw-6062905 opw-6062590 opw-6060781 Forward-Port-Of: odoo/enterprise#112175
This update fixes a warning related to how work orders consume components in manufacturing. Previously, the system would incorrectly flag a lack of lots when component quantities were specified. The change now correctly generates the necessary serials, ensuring accurate tracking of component usage within work orders. This resolves a potential disruption in production workflows.
Original PR description
This commit update the test since the fix commit introduced a new behavior. Before if the manufacturing had qty_producing, it would not set the move to picked and raise an error because there is no lot. With the fix, when the production has qty_producing. It will generate the missing serial. We prefer this behavior to the old ones so we keep it. Forward-Port-Of: odoo/enterprise#106365
This update resolves an issue where AI conversations within the Odoo AI app were sometimes stuck in a self-chat loop, displaying an OOO banner. The fix ensures that AI conversations correctly identify and interact with agents, preserving the intended agent workflows. This improves the overall user experience and reliability of the AI assistant.
Original PR description
Override AI thread correspondent computation to keep the base behavior but clear the correspondent when it resolves to the current user in ai_composer/ai_chat. This avoids self-chat fallback side effects (like OOO banner) while preserving agent flows that rely on a real non-self correspondent. source of this crash: https://github.com/odoo/enterprise/pull/108217 Forward-Port-Of: odoo/enterprise#112164 Forward-Port-Of: odoo/enterprise#111736
This update fixes a technical error that prevented users from correctly updating lot numbers on stock move lines. The change ensures that lot IDs are properly linked within the Odoo system, resolving a potential data inconsistency and preventing errors during inventory adjustments. This improves the reliability of stock tracking.
Original PR description
Since ce2a8f9c929, quality.check.lot_id (Many2one) was changed to lot_ids (Many2many), but the write() override in stock.move.line still assigns a raw integer to the field. This causes a ValueError when changing the lot on an MO move line. With this commit, use Command.link() to properly link the record to the Many2many field. Forward-Port-Of: odoo/enterprise#110180
This update resolves an issue where a test tour within the product catalog feature was failing due to a problem with how product selections were being tracked. The fix ensures the correct section ID is always used, preventing the tour from encountering an error and improving the overall user experience.
Original PR description
Cause: The `selectedSectionId` was not yet updated in the environment when the product was added, resulting in a `None` value being passed to `_update_order_line_info`. Fix: Use `this.env.selectedSectionId` when available, and fall back to `this.env.searchModel.selectedSection.sectionId` only if it is undefined or null. runbot-241960 Forward-Port-Of: odoo/odoo#254374
This update fixes an issue where combo prices were incorrect when multiple quantities were selected. The fix ensures that the combo price accurately reflects the total quantity of items, regardless of the customer or preset selected. This improves the accuracy of point-of-sale transactions.
Original PR description
**Steps to reproduce:** - Open the PoS - Select a combo and choose whatever - Use the numpad or keyboard to set the combo's qty to 10 - Choose another customer or preset - The price is all wrong…
**Steps to reproduce:** - Open the PoS - Select a combo and choose whatever - Use the numpad or keyboard to set the combo's qty to 10 - Choose another customer or preset - The price is all wrong **Why the fix:** Whenever we change the customer or the preset, the **setPriceList** function is triggered. In this function we recompute the combo's children lines' price. Before this commit, we assumed that the combo's parent line's qty would always be one, and the logic was written on this assumption. Meaning that when it's manually changed, the data is wrong. What really happens is that most of the children line's qty end up being treated as an extra price. This happens because in our exemple, the parent and children lines have a qty of 10, but we only set the free qty based on the assumption that the parent line has a qty of 1 on those lines https://github.com/odoo/odoo/blob/f5d5783b6a0c908127aa620ad0ec5b0008d7adf4/addons/point_of_sale/static/src/app/models/pos_order.js#L482-L485 This means that, as the free qty is rapidly depleted, we fall back on the extra products, and their unit price end up becoming the combo's base_price. We now set the right amount in the free qty based on the parent line's qty. When doing this, another problem arises, we have to multiply the children's unit price by the parent's qty, as theunit price's computation was based on the fact that weonly have a qty of one on the parent line. This is because we were still basing the unit_price the the parent's lstPrice, but this price was not using the parent's qty at all, so we need to multiply it by the parent line's qty to make it work. The unit price handling has to be done in the **computeComboItems** function, as we also need to adjust the remaining price accordingly. An access to the parent's qty was added onto the child line, to avoid adding a default parameter to the function, which should be avoided in stable if possible. opw-5266483 Forward-Port-Of: odoo/odoo#255898 Forward-Port-Of: odoo/odoo#244940
This update fixes an issue where Italy's chart of accounts was defaulting to incorrect expense and revenue accounts. The change explicitly defines the correct deferred accounts (`190200` and `270200`) within the chart template, ensuring accurate financial reporting for Italian businesses using Odoo.
Original PR description
Italy's chart template did not explicitly define deferred expense and revenue accounts, so deferred accounts fell back to the first `asset_current` and `liability_current` accounts in the chart. That could assign incorrect defaults such as `140100` and `220100`. This patch sets the intended Italian deferred accounts to `190200` and `270200` directly in the template to ensure correct configuration during chart loading. task-6076711 Forward-Port-Of: odoo/odoo#256623
This update automatically sets the correct analytic account when creating new items from the gross margin smart button within analytic accounts. Previously, new records didn't link to an account, leading to data inconsistencies. This change ensures accurate tracking of financial data within the Odoo system.
Original PR description
When accessing analytic items from the gross margin smart button on an analytic account, creating a new record does not pre-fill the analytic account field. This happens because the context does not set `default_account_id` for the active analytic account, leading to newly created lines not being linked at creation time. This commit ensures the analytic account is correctly passed through the context, so it is automatically set when creating a new analytic line from this flow. Steps to reproduce: - Open an analytic account - Click on the gross margin smart button - Create a new analytic item Before: analytic account not set by default After: analytic account is pre-filled via context task-3909624 Forward-Port-Of: odoo/odoo#256426 Forward-Port-Of: odoo/odoo#255726
This update resolves an issue where credit notes created through 'Reverse and create invoice' didn't correctly show the original invoice's source information. The fix ensures that the source document is accurately reflected in the generated invoice PDF, improving reporting and traceability. This maintains consistent data across invoices and sales orders.
Original PR description
### Issue before this commit: When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source,…
### Issue before this commit: When creating a credit note using “Reverse and create invoice”, the generated invoice loses the Source field. While the original invoice correctly displays the source, the new invoice created after reversal does not, leading to missing information in the report. ### Steps to reproduce the issue: 1. Create a sales order for product A 2. Deliver product A 3. Create invoice 4. Create credit note by clicking on "Reverse and create invoice" 5. The new invoice correctly remains linked to the Sales order 6. However, the source document disapear on the PDF ### Cause of the issue: In the reversal flow, the new invoice is created using copy_data() without explicitly preserving the invoice_origin field. As a result, the newly created invoice does not inherit the source information from the original invoice, even though it is still logically linked. ### Reason to introduce the fix: To ensure consistency between invoices and preserve important traceability information, the invoice_origin field must be propagated to the new invoice created during the reversal process. This guarantees that the Source is correctly displayed in the PDF. opw-6034574 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256284 Forward-Port-Of: odoo/odoo#254290
This update resolves an issue where certain XML tags were not properly removed from the Odoo import file. The change ensures that the import process accurately reflects recent updates by deleting the <report> and <act_window> tags from the import_xml.rng file. This improves the consistency and reliability of Odoo's import functionality.
Original PR description
`<report>` and `<act_window>` tags has been removed in https://github.com/odoo/odoo/pull/98138, but not in the import_xml.rng file. This commit removes the two tags from the file. Forward-Port-Of: odoo/odoo#220116
This update fixes a configuration issue with default accounting accounts for the Swiss (l10n_ch) version of Odoo. The previous misconfiguration has been corrected, ensuring accurate financial reporting for Swiss businesses using this module. This ensures compliance and reliable financial data.
Original PR description
[IMP] l10n_ch: Set default accounts in Switzerland Some defaults accounts in Switzerland were misconfigured, this commit set clean values by default task-6043978 Forward-Port-Of: odoo/odoo#255350
We've been experiencing an increase in payment failures related to an 'invalid billToPhone' error. This update corrects the way phone numbers are sent to Flutterwave, aligning with a recent change in the Flutterwave API that requires unformatted phone numbers. This resolves the payment errors and ensures smoother transactions.
Original PR description
With are recently seeing an increasing number of payments that fail with an `invalid billToPhone` error. It's unclear if it's a recent change of flutterwave API or of any intermediary payment processor, but the flutterwave v4.0.0-beta API now state to send the phone number "unformatted" - even if there is no such statement for the v3.0.0 API (that we are using), based on testing, sending the phone number "unformatted" do so seems do solve the issue. So this commit, sanitize the phone number to send it unformatted. opw-6074825 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256478 Forward-Port-Of: odoo/odoo#256315
This update automatically checks out employees from attendance records when they are archived. Previously, archived employees remained checked in, leading to data inconsistencies. This change ensures accurate attendance tracking and simplifies the process of managing archived staff.
Original PR description
Before: - When an employee was archived, their attendance was not updated. After: - When an employee is archived, if they are currently checked in, they will be automatically checked out at the current timestamp. task-5916700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256083 Forward-Port-Of: odoo/odoo#255524
This update optimizes how the system loads partner data for self-ordering, addressing previous performance issues. By only loading essential information, the system now operates more efficiently, particularly when dealing with partners with extensive data. This results in a smoother and faster self-ordering experience.
Original PR description
Partner data loading for self-ordering was not optimized, leading to performance issues when the partner had a lot of data. This commit optimizes the partner data loading by only loading the necessary fields for self-ordering. Forward-Port-Of: odoo/odoo#256158 Forward-Port-Of: odoo/odoo#253563
This update resolves a potential instability in the testing of one2many fields within the Odoo web application. Specifically, a test was occasionally failing due to an unintended record creation. This fix prevents a second record creation, ensuring the test is more reliable and consistent.
Original PR description
This commit fixes a non deterministic one2many field test by ensuring that we don't quick create the record twice.
Before this commit, it might sometimes happen that the validation of the input ("Enter", by default) produced a second name_create. Note that in practice this is highly unlikely to happen as if the user presses Enter, the "Quick create" item in the dropdown only appears during a single frame, thus making impossible for the user to click on it.
runbot error~242204
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#256582This update significantly speeds up the Inventory Valuation report by correctly handling date comparisons across timezones. Previously, the report would slow down when the user's local time wasn't aligned with the report's UTC date. The change ensures faster report generation, especially for large inventories.
Original PR description
When accessing the Inventory Valuation report, we check if the selected date correspond to the current day:…
When accessing the Inventory Valuation report, we check if the selected date correspond to the current day: https://github.com/odoo/odoo/blob/3610d16ae47e53860e6e047b98de6a60733a5408/addons/stock_account/report/stock_valuation_report.py#L33-L34 If the date is today, the method _run_average_batch() simply computes the value as qty_available * standard_price. But if it is not, it will replay the whole AVCO history which can be heavy. https://github.com/odoo/odoo/blob/3610d16ae47e53860e6e047b98de6a60733a5408/addons/stock_account/models/product.py#L394-L397 The "date" variable used in the comparison is the local date obtained from the browser while fields.Date.today() returns the UTC date. In certain case, when the local timezone is not on the same day as UTC anymore, this causes the report to be very slow to load because it replays the full history when it should not. We propose to use the context_today() method instead to get the date from the user's timezone. Benchmark: | No AVCO Products | Before PR | After PR | |------------------|-----------|----------| | 12000 | > 40 s | 3 s | opw-6050007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255841
5 changes
Resolved issues and error corrections
A test was failing because the test user's security group configuration was incomplete. This update added the necessary `group_production_lot` group, enabling proper line grouping within the stock barcode process and resolving the tour failure. This ensures accurate testing of the packaging feature.
Original PR description
```js ---------- FAILED: [7/19] Tour test_quality_check_packages_lots_tour → Step .o_barcode_line_summary ---------- { 'trigger': '.o_barcode_line_summary', 'run': 'click' },…
```js
---------- FAILED: [7/19] Tour test_quality_check_packages_lots_tour →
Step .o_barcode_line_summary ----------
{
'trigger': '.o_barcode_line_summary',
'run': 'click'
},
------------------------------------------------------------------------
```
The tour `test_quality_check_packages_lots_tour` was failing at the step
waiting for `.o_barcode_line_summary` after calling `o_put_in_pack`.
**Root cause:**
the JS barcode model sets `groupingLinesEnabled` directly from
the `group_production_lot` security group flag returned by the backend:
https://github.com/odoo/enterprise/blob/bd35e9c16a6c0fd743c934024db2821b8ae21fdc/stock_barcode/static/src/models/barcode_model.js#L53
When `groupingLinesEnabled` is false, `groupLines()` skips the grouping
logic entirely and individual move lines are rendered as flat
`LineComponent` instances. The `.o_barcode_line_summary` element only
exists inside `GroupedLineComponent`, which is only rendered when lines
are actually grouped (i.e. a parent line has `line.lines` sublines).
The test setup already granted `group_tracking_lot` (required to show the
`o_put_in_pack` button) but was missing `group_production_lot`. Without
it, after scanning `lot-01` twice and packing, the two lot sub-lines were
never merged into a `GroupedLineComponent`, so `.o_barcode_line_summary`
never appeared in the DOM and the tour timed out.
Fix: add `group_production_lot` alongside `group_tracking_lot` in the
test user's groups so that line grouping is enabled in the JS model,
allowing `GroupedLineComponent` to render `.o_barcode_line_summary` as
expected by the tour.
similar fix - https://github.com/odoo/enterprise/pull/82677/changes/05883b2c9cadb1187df404a4bef638f933922755
---
runbot error:241926
Forward-Port-Of: odoo/enterprise#112268This update resolves an issue where the system would generate an error and fail to create PDF documents when users uploaded empty XML files. The fix skips PDF extraction when raw data is missing, ensuring documents are generated correctly and preventing errors.
Original PR description
Currently an error is generated and the file is not generated when the user uploads an empty XML file (e.g., ref file [1]). Error: `AttributeError: 'bool' object has no attribute 'decode'` This error occurs because the uploaded file contains no raw data. As a result, the system fails to retrieve the file content during PDF extraction from the XML at line [2]. This commit fixes the issue by skipping PDF extraction from the XML when the document has no raw data. The process now returns False early if the document contains no raw content. [1]: https://drive.google.com/file/d/1hRbgEsTL-iWhiAO245z_10HRH6nh3rUQ/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/documents_account/models/documents_document.py#L52 sentry-7173452999 Forward-Port-Of: odoo/enterprise#103801
This update resolves an issue where users couldn't successfully undo rescheduling calendar events. The fix removes a problematic data field ('originId') before the system writes event data to the database, preventing a data error. This ensures the undo functionality now works as expected.
Original PR description
Currently, an error occurs when user tries to undo a calendar event. Steps to replicate: - Install `appointment` with demo data. - Navigate to `Appointments > Schedule > Resource Booking`. - Drag to…
Currently, an error occurs when user tries to undo a calendar event. Steps to replicate: - Install `appointment` with demo data. - Navigate to `Appointments > Schedule > Resource Booking`. - Drag to create a calendar event. - Reschedule the event to a later time (drag and drop forward). - Click Undo on the notification that appears. Error: `ValueError: Invalid field 'originId' in 'calendar.event'` `KeyError: 'originId'` Cause: - The key `originId` was patched in the `getschedule()` [1] and later when user tried to undo the calendar event, the [fallbackschedule] included the key `originId` and made an [orm] call with it. - The [line] tries to write the data into the database where `originId` field doesnt exist and causes the error to occur. Solution: - Remove the `originId` key from `fallbackdata` before the orm call. [1]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/appointment/static/src/views/gantt/gantt_renderer.js#L110-L116 [fallbackschedule]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1425 [orm]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/static/src/gantt_renderer.js#L1473-L1477 [line]: https://github.com/odoo/enterprise/blob/e61eef059983bb0cdec4f156fb9283198b379863/web_gantt/models/models.py#L248 sentry-7020359653
This update resolves an issue where confirming quantities of archived products through the barcode app would cause a system error. The fix ensures that archived products are included in search results, allowing users to accurately add and confirm quantities, maintaining consistent functionality.
Original PR description
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to…
Currently, when a user confirms the quantity of an archived product using the product selector in the barcode app, a traceback error occurs. ## Steps to replicate: - Install Inventory - Go to Settings and enable Multi-Step Routes > Set Warehouse Routes. - Configure 2 steps for outgoing shipments. - Go to Inventory and create a new delivery with - **Source Location:** WH/Stock - **Product:** [E-COM10] Pedal Bin with demand 1 - Mark as Todo then Archive the Pedal Bin product. - Open that delivery in barcode app - Pencil icon > +1 > Confirm ## Observed behavior: TypeError: Cannot read properties of undefined (reading 'qty_available') ## Root cause: After this [commit], an override was added to the product selector. As a result, when [2] calls the `search_read` method, it only retrieves non-archived products Consequently, if the result is an empty array, attempting to access `qty_available` causes the type error mentioned above. ## Solution: Adding` active_test = false `to the context ensures that archived products are included in search results. This prevents empty results and avoids the error. It also allows quantities to be added and confirmed,maintaining the same behavior as when using the increment button followed by validation, ensuring consistency. [commit]: https://github.com/odoo/enterprise/commit/6aa814f59f8641d7b57af160e38b50d5bdfc8a97 [2]- https://github.com/odoo/enterprise/blob/e13b44b353e734a6533f7d627ed69b6e7b033ee2/stock_barcode/static/src/js/stock_barcode_sml_form.js#L40-L45 opw-5980428 Forward-Port-Of: odoo/enterprise#112349 Forward-Port-Of: odoo/enterprise#109204
This update resolves a critical issue where users could cancel documents after all parties had signed, potentially compromising legal records. Now, the cancel button disappears automatically once signing is complete, and backend cancellations are blocked to ensure document permanence and security. This strengthens legal proof of agreements and protects data integrity.
Original PR description
Before this commit, users could cancel documents after everyone had signed. This weakened legal records and proof of agreement. After this commit, the cancel button disappears once signing is complete. We also blocked backend cancellations to keep finished documents permanent and secure. task-5980337 Forward-Port-Of: odoo/enterprise#110539 Forward-Port-Of: odoo/enterprise#109353
15 changes
Resolved issues and error corrections
This update resolves an issue where the system would generate an error and fail to create PDF files when users uploaded empty XML documents. The fix skips PDF extraction when raw data is missing, ensuring that documents are processed correctly and preventing errors.
Original PR description
Currently an error is generated and the file is not generated when the user uploads an empty XML file (e.g., ref file [1]). Error: `AttributeError: 'bool' object has no attribute 'decode'` This error occurs because the uploaded file contains no raw data. As a result, the system fails to retrieve the file content during PDF extraction from the XML at line [2]. This commit fixes the issue by skipping PDF extraction from the XML when the document has no raw data. The process now returns False early if the document contains no raw content. [1]: https://drive.google.com/file/d/1hRbgEsTL-iWhiAO245z_10HRH6nh3rUQ/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/documents_account/models/documents_document.py#L52 sentry-7173452999 Forward-Port-Of: odoo/enterprise#103801
This update fixes an issue where delivery slips incorrectly displayed the quantity of packaged items. The change ensures that the correct quantity (5) is shown when items are delivered in packs, resolving a discrepancy between ordered and delivered amounts. This improves accuracy in inventory management.
Original PR description
Currently, when a user prints a delivery slip for items with different packaging units, the report shows the wrong quantity. ## Steps to replicate: - Install Purchase and Inventory with demo data -…
Currently, when a user prints a delivery slip for items with different packaging units, the report shows the wrong quantity.
## Steps to replicate:
- Install Purchase and Inventory with demo data
- Settings > Enable 'Units of Measure & Packagings' and 'Packages'
- Products > Desk Pad > Purchase > Add a line > Set unit to pack of 6 and set a vendor.
- Create new RFQ with the same vendor for 'Desk pad' having quantity 10
- Confirm RFQ > Go to receipt > Details
- Create and Set Destination Package to
- LOT A 5 pack of 6
- LOT B 5 pack of 6
- Validate Delivery Order and Print the Delivery Slip
## Observed Behavior:
Both the ordered and delivered quantities are showing 30.0 (Pack of 6), but this is incorrect.
The correct quantity ordered and delivered should be 5 (Pack of 6).
## Root cause:
This unintentional behavior occurs after commit [1].
When printing the delivery slip, function [2] is triggered. The packaging quantity is calculated using `move_line.product_uom_id`. In this case, the unit of measure is `pack of 6`, because the user selected a different UoM when setting the Destination Packaging.
As a result, when `_compute_quantity` is called, it reaches condition [3], where it checks whether the unit of measure provided as `self` matches `to_unit` Since both are `pack of 6`, no conversion is performed.
Because of this, the packaging quantity is not converted as expected, and the quantity is set to 30 instead of 5.
[2]-
https://github.com/odoo/odoo/blob/9c9ed6ef00b796d7428e4df6e5f96abb5b95287a/addons/stock/models/stock_move_line.py#L860-L945
[3]-
https://github.com/odoo/odoo/blob/9c9ed6ef00b796d7428e4df6e5f96abb5b95287a/addons/uom/models/uom_uom.py#L87-L88
## Solution:
Use the uom variable instead, as it reflects the unit of measure for the product applied directly on the receipt. This ensures that the unit-of-measure conversion for packaging quantities is handled correctly.
**Before:**
<img width="824" height="244" alt="image" src="https://github.com/user-attachments/assets/ce0ae06b-7cba-46e0-929b-a51aadc0c199" />
**After:**
<img width="833" height="244" alt="image" src="https://github.com/user-attachments/assets/dff563ef-e05c-4b86-bd89-99e89378d152" />
[1]:
https://github.com/odoo/odoo/commit/fa606530235ac413d17dd3d58bdb0921bd811d28
opw-5930343
Forward-Port-Of: odoo/odoo#249779This update resolves an issue where Odoo displayed a misleading warning message to users when uploading files without a password. The change now correctly checks for a password during saving, eliminating the unnecessary warning and improving the user experience. This ensures consistent and accurate behavior.
Original PR description
Before the change, when the user uploads a file, Odoo automatically shown a warning message saying that the content of the file or the password are incorrect. Now the system does not show the warning when a password is not set and checks if the password is set when saving task-6036219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253834
This update allows users to search for inactive accounts using their code, which was previously unavailable. The change corrects a technical issue where the search criteria for inactive accounts was not properly applied. This ensures accurate account retrieval for all account statuses.
Original PR description
# How to reproduce - Go to the chart of account - Archive any record (e.g. Code 101401) - Search with the filters : - Inactive Accounts - Account: 101401 (the code of the record) # The problem The…
# How to reproduce
- Go to the chart of account
- Archive any record (e.g. Code 101401)
- Search with the filters :
- Inactive Accounts
- Account: 101401 (the code of the record)
# The problem
The record that we searched for is not shown
# Cause
The domain for the "Account" filter is the following : https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L147
And this is the domain for "Inactive Accounts":
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/views/account_account_views.xml#L159
This is correct and the search should return what we wanted, but the code's search is overriden by:
https://github.com/odoo/odoo/blob/87c5f562e32ffb58359cf068124e03ead1a5859c/addons/account/models/account_account.py#L383-L384
And the search with the `code_store` domain only explicitely looks for accounts that are active, so our "[('active', '=', False)]" is essentialy ignored
This is fixed in 19.1 because this commit (https://github.com/odoo/odoo/commit/de959adf7c806e09864b52fec78d981e66804280) replaced the custom search by a `compute_sql`
# Proposed solution
We change the search with the `code_store` to look for records that are both active and inactive, since the active value will be handled by the parent search
opw-6059404
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update enhances the process for managing demo transactions in the Point of Sale system. Previously, users were stuck with demo transactions indefinitely. Now, users can easily delete the demo transaction or sync it to the production environment, providing greater control and flexibility.
Original PR description
Before this commit:
- The fields `l10n_jo_edi_pos_{state, return_reason}` were readonly when
`l10n_jo_edi_pos_qr` was set. However, we did not take into account the fact
that `pos.order` cannot be reset once `done/paid/invoiced`; thereby blocking
the user with a demo transaction forever without any alternative.
After this commit:
- The fields `l10n_jo_edi_pos_{state, return_reason}` are readonly when
`l10n_jo_edi_pos_qr and l10n_jo_edi_state == 'sent'`. Additionally, an
onchange is introduced on `l10n_jo_edi_pos_state` to clear
`l10n_jo_edi_pos_qr`. This gives back flexibility to the user to either delete
the demo mode transaction or sync them to the production endpoint.
task-5958427
Forward-Port-Of: odoo/odoo#250808This update resolves an issue where project users couldn't add customers to tasks, resulting in an access error. The fix ensures project users can now correctly update customer information on tasks, improving task management functionality. Security enhancements were also implemented to control who can modify partner phone numbers.
Original PR description
Steps to Reproduce: - 1. Log in with a user having only Project > User access. 2. Create a new task in project. 3. Add a customer on the task. 4. Access error is raised. Issue: - - Project users could not create a task with a customer. - An access error appeared during task creation. Cause: - - When a customer was added to the task, the partner_phone inverse method was triggered. - This method attempted to write on the partner record. Solution: - - Added a check before writing to avoid unnecessary writes. - Used sudo() to update the partner phone securely. - Added view-level restriction using base.group_partner_manager to control who can edit the phone number. task-5039657 Forward-Port-Of: odoo/odoo#252406
This update resolves an issue where Field Service users couldn't add customers to tasks, resulting in an access error. The fix securely updates partner records using sudo() to allow task creation, and adds view-level restrictions to control who can modify customer phone numbers. This ensures Field Service functionality is consistently available.
Original PR description
Steps to Reproduce: - 1. Log in with a user having only "Field Service > User" access. 2. Create a new task in an field service project. 3. Add a customer on the task. 4. Access error is raised. Issue: - - Field service users could not create a task with a customer. - An access error appeared during task creation. Cause: - - When a customer was added to the task, the partner_phone inverse method was triggered. - This method attempted to write on the partner record. Solution: - - Used sudo() in the inverse method to update the partner phone securely, bypassing restricted access. task-5039657 Forward-Port-Of: odoo/enterprise#109668 Forward-Port-Of: odoo/enterprise#93969
This update fixes an issue where refund creation from invoices with similar items would fail due to incorrect line matching. The new algorithm now accurately identifies the best matching invoice lines based on product, price, and quantity, ensuring refunds are processed correctly. This improves the reliability of refund processing for users.
Original PR description
In some cases, the users may have invoices with the same product, price unit, and discount on multiple lines. When they create refunds from such invoices, the lines ids matching algorithm would fail because it would match the first matching line over and over again. Also, lines should not match based on line label, as it can be modified in the refund. This commit solves these 2 issues by 1) Preventing matching an invoice line more than once with refund lines 2) Preventing matching based on line label The new algorithm finds the best match for a refund line from the invoice lines with the following criteria: 1) same product 2) same unit price 3) same discount 4) invoiced quantity should be at least equal to the refunded quantity 5) invoice line should not be matched before 6) from the lines that match previous criteria, we pick the one with the minium quantity task-6004207 Forward-Port-Of: odoo/odoo#256365 Forward-Port-Of: odoo/odoo#252200
This update corrects a visual inconsistency in the sale management module, ensuring that optional product tables display with the standard report table styling. The change was made in the 'web' module to avoid requiring updates for customers, and a layout configuration save is needed to apply the color change.
Original PR description
Issue: In sale_management the optional product table doesn't get the report table styling. This is due to a different DOM and missing classes. This fix applies the styling to match the optional product table structure. While the table is in `sale_management` the change is applied in `web` to avoid having to update the module for customers. Note: the color applied in `report_templates.xml` requires that the user change is layout in the document layout configurator then save again for it to apply. task-6009941 opw-5960426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252430
This update fixes an issue where refund creation from invoices with similar product details would fail due to incorrect line matching. The new algorithm now accurately identifies the best matching invoice lines based on product, price, and quantity, ensuring refunds are processed correctly. This improves the reliability of refund processing for users.
Original PR description
In some cases, the users may have invoices with the same product, price unit, and discount on multiple lines. When they create refunds from such invoices, the lines ids matching algorithm would fail because it would match the first matching line over and over again. Also, lines should not match based on line label, as it can be modified in the refund. This commit solves these 2 issues by 1) Preventing matching an invoice line more than once with refund lines 2) Preventing matching based on line label The new algorithm finds the best match for a refund line from the invoice lines with the following criteria: 1) same product 2) same unit price 3) same discount 4) invoiced quantity should be at least equal to the refunded quantity 5) invoice line should not be matched before 6) from the lines that match previous criteria, we pick the one with the minium quantity task-6004207 Forward-Port-Of: odoo/odoo#256365 Forward-Port-Of: odoo/odoo#252200
This update corrects a visual inconsistency in the optional product table within the sale management module. The fix ensures that this table consistently uses the standard report table styling, improving the overall user experience. A minor user action (configuring the layout) is required to fully apply the color change.
Original PR description
Issue: In sale_management the optional product table doesn't get the report table styling. This is due to a different DOM and missing classes. This fix applies the styling to match the optional product table structure. While the table is in `sale_management` the change is applied in `web` to avoid having to update the module for customers. Note: the color applied in `report_templates.xml` requires that the user change is layout in the document layout configurator then save again for it to apply. task-6009941 opw-5960426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252430
This update fixes an issue where refund processing for invoices with multiple identical lines would fail. The new algorithm now accurately matches refund lines to invoices based on product, price, and quantity, preventing incorrect matching and ensuring accurate credit note processing. This improves the reliability of refund operations.
Original PR description
In some cases, the users may have invoices with the same product, price unit, and discount on multiple lines. When they create refunds from such invoices, the lines ids matching algorithm would fail because it would match the first matching line over and over again. Also, lines should not match based on line label, as it can be modified in the refund. This commit solves these 2 issues by 1) Preventing matching an invoice line more than once with refund lines 2) Preventing matching based on line label The new algorithm finds the best match for a refund line from the invoice lines with the following criteria: 1) same product 2) same unit price 3) same discount 4) invoiced quantity should be at least equal to the refunded quantity 5) invoice line should not be matched before 6) from the lines that match previous criteria, we pick the one with the minium quantity task-6004207 Forward-Port-Of: odoo/odoo#256365 Forward-Port-Of: odoo/odoo#252200
This update corrects a visual inconsistency in the optional product table within the sale management module. The fix ensures that this table consistently uses the standard report table styling, improving the overall user experience. A minor step is required in the document layout configurator to apply the color change.
Original PR description
Issue: In sale_management the optional product table doesn't get the report table styling. This is due to a different DOM and missing classes. This fix applies the styling to match the optional product table structure. While the table is in `sale_management` the change is applied in `web` to avoid having to update the module for customers. Note: the color applied in `report_templates.xml` requires that the user change is layout in the document layout configurator then save again for it to apply. task-6009941 opw-5960426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252430
This update corrects a visual inconsistency in the sale management module, specifically for optional product tables within reports. The fix ensures these tables now match the standard report table styling, improving the overall user experience. A user configuration step is required to apply color changes.
Original PR description
Issue: In sale_management the optional product table doesn't get the report table styling. This is due to a different DOM and missing classes. This fix applies the styling to match the optional product table structure. While the table is in `sale_management` the change is applied in `web` to avoid having to update the module for customers. Note: the color applied in `report_templates.xml` requires that the user change is layout in the document layout configurator then save again for it to apply. task-6009941 opw-5960426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252430
This update corrects a visual inconsistency in the sale management module, specifically for optional product tables within reports. The fix ensures these tables now match the standard report table styling, improving the overall presentation and user experience. A slight user action is required to apply the color change from the report templates.
Original PR description
Issue: In sale_management the optional product table doesn't get the report table styling. This is due to a different DOM and missing classes. This fix applies the styling to match the optional product table structure. While the table is in `sale_management` the change is applied in `web` to avoid having to update the module for customers. Note: the color applied in `report_templates.xml` requires that the user change is layout in the document layout configurator then save again for it to apply. task-6009941 opw-5960426 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252430
1 change
Resolved issues and error corrections
This update fixes translations within the Odoo Enterprise application, specifically for Danish reports (balance sheet and profit & loss). The changes ensure accurate accounting terminology and consistency across all reports, improving clarity and compliance for Danish users.
Original PR description
We used the official Danish terms and improved the English translations to match the correct accounting terminology and be consistent across the report. opw-5976022
20 changes
Resolved issues and error corrections
This update resolves an error that occurred when converting helpdesk tickets to opportunities. The fix ensures the system correctly handles cases where a ticket lacks a partner email, preventing a technical error and allowing users to successfully convert tickets.
Original PR description
Currently, an error occurs when user converts a helpdesk ticket into an opportunity. **Steps to Reproduce:** - Install the `crm_helpdesk` module. - Go to `Helpdesk` > `Tickets` > `All Tickets`. -…
Currently, an error occurs when user converts a helpdesk ticket into an opportunity. **Steps to Reproduce:** - Install the `crm_helpdesk` module. - Go to `Helpdesk` > `Tickets` > `All Tickets`. - Create a `new ticket`, set only the `ticket name`, and `save` the record. - Click on the `Convert to Opportunity` button. **Error:** `TypeError: 'bool' object is not iterable` After this [recent commit], the system attempts to find the partner using the partner email. Since the helpdesk ticket does not have partner email, False is passed as the email [1]. As result, when retrieving emails based on the ticket record, it returns False, and iterating over it raises the error [3]. This commit ensures that the system attempts to find the partner from the email only if the partner email exists. It also passes the partner email as a list, since _partner_find_from_emails_single expects emails in list format. [recent commit]: https://github.com/odoo/enterprise/commit/41aa34b74f59d48c3ad2fc87a5655866fda968c9 [1]- https://github.com/odoo/enterprise/blob/241b2b0174731558795572d8843d9b184d98e2e0/crm_helpdesk/models/helpdesk_ticket.py#L21 [2]: https://github.com/odoo/odoo/blob/6ccdc3b6e6f2957a73eb1539fc37de800a229569/addons/mail/models/mail_thread.py#L2050 [3]: https://github.com/odoo/odoo/blob/6ccdc3b6e6f2957a73eb1539fc37de800a229569/addons/mail/models/mail_thread.py#L2052 sentry-7359614247 Forward-Port-Of: odoo/enterprise#111953
This update resolves an issue where custom payrun filters weren't consistently applied across different payruns. The change ensures that saved filters now correctly apply to the current payrun, providing a more reliable and user-friendly experience when managing payroll data. This prevents users from being directed to the payrun where the filter was originally saved.
Original PR description
Before this commit, when a user saves a custom filter on a payrun in step "payslip", then moved to another payrun, trying to apply the saved filter takes him to the payrun in which the custom filter was saved. Solution: Removing the search default parun id from the context of the action that opens the payslips of a payrun, and instead, adding a domain on the action to only show the payslips of the current payrun to avoid having the filter binded to a specific payrun. task-6075315
This update resolves an issue where the Paid Time Off Allocation wizard appeared empty in the demo data due to a filter requiring a 'dimona' category. The PR sets the 'Other' category as the default for demo employees, ensuring the wizard displays accurate results. This improves the usability of the demo environment.
Original PR description
Due to this PR (https://github.com/odoo/enterprise/pull/103118), the query that is run when using the Paid Time Off Allocation wizard now includes a filter on the dimona category, only returning results with category "Other". The demo data employees don't have a dimona category set and therefore the wizard appears empty: in order to avoid this confusion we set the dimona category of the demo data employees to Other by default. Task: 6067231
This update resolves an issue where the system would generate an error and fail to create PDF files when users uploaded empty XML documents. The fix skips PDF extraction when no raw data is present, ensuring that documents are processed correctly and preventing errors. This improves the reliability of document generation.
Original PR description
Currently an error is generated and the file is not generated when the user uploads an empty XML file (e.g., ref file [1]). Error: `AttributeError: 'bool' object has no attribute 'decode'` This error occurs because the uploaded file contains no raw data. As a result, the system fails to retrieve the file content during PDF extraction from the XML at line [2]. This commit fixes the issue by skipping PDF extraction from the XML when the document has no raw data. The process now returns False early if the document contains no raw content. [1]: https://drive.google.com/file/d/1hRbgEsTL-iWhiAO245z_10HRH6nh3rUQ/view?usp=sharing [2]: https://github.com/odoo/enterprise/blob/00e2e658312eda2d3dae04eb966fd538972e5243/documents_account/models/documents_document.py#L52 sentry-7173452999 Forward-Port-Of: odoo/enterprise#103801
This update resolves a technical issue where the suspense line validation process was failing due to an incorrect data type. The change improves the reliability of the suspense line calculation, ensuring accurate reporting. This primarily affects the account accounting module.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/ec7299e39c5b89cea86e4dda34894958c560663e change the way the suspense line is computed, and we expect the suspense line to be an object. But since this commit, the suspense line getter can give False the props validator will fail. no task id Forward-Port-Of: odoo/enterprise#112481
This update resolves an issue preventing SBR tax reports from submitting due to incorrect date formatting and overly long consultant descriptions. The commit restores the original date format and simplifies the consultant name to only display the abbreviation, ensuring compliance with validation requirements and successful report submission.
Original PR description
Description of the issue this commit addresses: During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible. [^1]: https://www.odoo.com/odoo/967/tasks/6034675 --- Desired behavior after this commit is merged: This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description. [^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie --- task-none Forward-Port-Of: odoo/enterprise#112216 Forward-Port-Of: odoo/enterprise#111817
This update fixes an issue where searching for deliveries by zip code alone resulted in inaccurate location suggestions. The fix ensures that the system correctly includes city information when searching through Sendcloud, leading to more precise delivery options for customers. This improves the overall efficiency of our delivery process.
Original PR description
Issue ----- Searching for locations by only providing a zip code has unexpected results. Steps to reproduce ----- - Set up Sendcloud with Mondial Relay - Create a sale through the website - Get to the delivery part - Select sendcloud delivery - Search for a zip code only (11000) > Points are all in the 12200 area Cause ----- When searching through the wizard, a temporary address is created in https://github.com/odoo/odoo/blob/89e5038c224d58a2f6be8f3001fd0a2932733cbc/addons/delivery/models/sale_order.py#L108-L112 which always has its' city field set to `False`, as all of the wizard's info is interpreted as the zip code. This leads to the address field sent to Sendcloud being '11000 False' instead of the expected '11000', which Sendcloud fails to interpret correctly. ----- Ticket: opw-5999194 Forward-Port-Of: odoo/enterprise#112219 Forward-Port-Of: odoo/enterprise#110459
This update resolves a problem where invoices with discounts and decimal values (over 2 decimals) were failing to send to ARCA. The fix uses a truncated unit price for discount calculations, ensuring accurate decimal comparisons and successful invoice transmission. This prevents errors related to differing decimal amounts.
Original PR description
After changes made in Odoo of how the decimal precision works some of the code we use to prepare the data to create EDI invoices now fails. We already adapt the code to fix the data depending of the expected webserive format but we miss a case related to when invovice has discounts. The problem is that any invoice with lines that has more than 2 decimals and also have a discount will fail when trying send it to ARCA because the computed amount has differences in the decimals. Now we use the truncated unit price to compute the discount instead of the full amount with decimal of the `line.price_unit` value. Forward-Port-Of: odoo/enterprise#111518 Forward-Port-Of: odoo/enterprise#110706
This update resolves an issue where the CFDI invoice reports incorrectly displayed '99 - False' instead of '99 - Por definir' for a specific payment method (99). The fix ensures that the report accurately reflects the payment method used on invoices, particularly those with payment policies.
Original PR description
**PROBLEM** PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'. **STEP TO REPRODUCE** 1. Create an invoice with the mx company. 2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice). 3. Send and generate the invoice using cfdi. opw-5927655 Forward-Port-Of: odoo/enterprise#111661 Forward-Port-Of: odoo/enterprise#107267
This update corrects a minor visual issue in the appointment scheduling forms, specifically aligning the checkbox labels correctly. The recent M3 update caused a slight misalignment, and this change ensures a cleaner and more professional appearance for users. This improves the overall user experience for scheduling appointments.
Original PR description
The js M3 update broke some of the form layouts. this commit fixes a checkbox suffix being displayed on the far right of the column by enforcing w-auto on the checkbox instead of w-100 Task-6048484
This update resolves an issue where commissions weren't correctly calculated when the target completion was set to 0%. The fix ensures that commissions are accurately applied even when the target amount is zero, addressing a previous bug that resulted in incorrect commission values.
Original PR description
Before this commit, when target completion was 0% and the commission was equal to X (where X is not null), the commission could not be equal to X. It would be equal to 0. It was working with target amount equal to 0. Forward-Port-Of: odoo/enterprise#112337
This update fixes an issue where the tax return reports incorrectly included Italian pension fund taxes, leading to discrepancies between the report and the backend view. The change excludes these taxes from the tax return domain, ensuring accurate calculations and consistent reporting for Italian customers.
Original PR description
The "amount to pay" incorrectly included the Pension Fund taxes, causing inconsistencies between the report and what the customer was able to see in the backend. Now we exclude them from the tax return domain. Steps to reproduce: - Create an Italian company with the Italian CoA - Install `l10n_it_edi_withholding` (not necessary in v19) - Create an invoice - Set the 4% INPS or 4% F.Pens taxes on a line, along with with a normal 22% VAT - Create a tax return Ticket [link](https://www.odoo.com/odoo/project.task/5909407) opw-5909407 Forward-Port-Of: odoo/enterprise#111311
This update resolves a technical issue where a controller was incorrectly referencing outdated code from a previous Odoo version. The fix ensures the E-Commerce functionality is working as intended, preventing potential disruptions to the sales process. This is a routine maintenance update.
Original PR description
`iot_box_setup` override is still calling the previous method names, mistakenly fw ported from 19. This commit fixes it. Forward-Port-Of: odoo/enterprise#112451
This update fixes an issue where AI tool responses with non-string data (like dates) were causing errors. By standardizing how tool results are formatted, this ensures consistent and reliable communication between Odoo's AI services and providers like Gemini, improving overall AI performance.
Original PR description
#### Description When a tool returns a non-string result (e.g. a dict containing datetime values), it was passed as-is into the response parts, causing a TypeError for Gemini provider's agents. Move json.dumps with json_default into the shared format_tool_result method so all providers benefit from proper serialization, and remove the now-redundant serialization from the OpenAI provider's `format_tool_result` method. task-id-6072688
This update resolves a bug that prevented users from successfully updating documents. The system was previously crashing due to incorrect handling of PDF data (specifically base64 strings). Now, the system correctly decodes the data into bytes, ensuring smooth document updates.
Original PR description
Before this commit, with the changes from updating a document could crash with a TypeError because the PDF data was passed as a base64 string instead of raw bytes. After this commit, we decode the base64 string into bytes before trying to read the PDF, preventing the crash and allowing the document update. task-6071104
This update resolves an issue where the tax report incorrectly flagged inconsistencies when vendor bills had expense lines with different vehicle assignments. The fix allows for accurate reporting when tax lines are shared across expense lines with and without vehicle assignments, ensuring correct tax calculations.
Original PR description
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other…
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other without a vehicle. * Confirm the vendor bill. * Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report. **Observed behavior:** * The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.' **Cause:** * The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`. * When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`. * The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency. **Fix:** * Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set. * If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines. opw-5956645 Forward-Port-Of: odoo/enterprise#112440 Forward-Port-Of: odoo/enterprise#110616
This update fixes a visual issue with the 'per employee' suffix field in the MRP Workcenter module. The change restores the standard inline display, ensuring a cleaner and more intuitive user experience. This improves the clarity and usability of the workcenter configuration.
Original PR description
This commit restores the correct inline display for the field containing the "per employee" suffix. task-6037387
This update ensures the subtotal row is always visible when calculating taxes externally. Previously, the subtotal was hidden in tax-included scenarios. This change maintains a consistent and clear layout for customers during the checkout process, regardless of how taxes are calculated.
Original PR description
Before this commit: With the tax-included display logic, the subtotal row was hidden in tax-included mode. In the `website_sale_external_tax` module, both total and tax rows are hidden before the payment step when tax is calculated externally. This results in subtotal row being hided in tax-included scenarios. After this commit: Adapted the subtotal row condition to also be visible when `is_tax_computed_externally` is true, ensuring that in external tax flows the subtotal remains visible in both tax-included and tax-excluded modes, keeping the layout consistent. task-5887432 See also : https://github.com/odoo/odoo/pull/251698
This update fixes a minor visual issue in the Odoo test environment related to date fields. The change ensures that date fields are correctly displayed as inputs, not buttons, after the datepicker is closed. This improves the consistency and usability of the test setup.
Original PR description
This commit adapts an iap_test interacting with date and datetime fields, according to the small behavior change done in odoo/odoo#256671. Before, the field was already blured due to the datepicker when it was being edited in the test. Now that the picker isn't open anymore, the field isn't blured, so it is still displayed as an input, not a button, which must thus be correctly targetted to be blured. task~6045658
This update resolves an issue where the Bank Reconciliation widget could crash when deleting a counterpart line. The fix ensures the method returning data from the Bank Reconciliation process is always valid, improving the stability and reliability of this key financial reporting feature. This prevents unexpected errors and ensures accurate reconciliation.
Original PR description
The `get suspenseAccountLine`` method could return False, which is not valid for the BankRecButtonList component props. This commit ensures the method returns either an object or undefined. Step to reproduce: - Enable developer mode - Open the Bank Reconciliation widget - Create a bank transaction - Reconcile the transaction - Click on the trash icon on the counterpart line - Previously, a traceback would occur due to invalid props opw-6012604 opw-6066531 opw-6066116 opw-6065924 opw-6063884 opw-6062905 opw-6062590 opw-6060781 Forward-Port-Of: odoo/enterprise#112546 Forward-Port-Of: odoo/enterprise#112175
3 changes
Resolved issues and error corrections
This update resolves a technical issue related to how the suspense line is calculated within the Odoo Enterprise accounting module. The change improved the validation process, preventing errors that could arise from incorrect data types. This ensures data integrity and stability for financial reporting.
Original PR description
This commit: https://github.com/odoo/enterprise/commit/ec7299e39c5b89cea86e4dda34894958c560663e change the way the suspense line is computed, and we expect the suspense line to be an object. But since this commit, the suspense line getter can give False the props validator will fail. no task id
This update resolves an issue where the General Ledger consolidation feature wouldn't function correctly when multiple companies were selected. The fix ensures the consolidation process works reliably across all company setups, preventing errors and improving data accuracy for multi-company reporting.
Original PR description
### Issue before this commit: When opening the General Ledger consolidation with multiple companies selected, a traceback was displayed with a KeyError: 'account_code'. ### Steps to reproduce the…
### Issue before this commit: When opening the General Ledger consolidation with multiple companies selected, a traceback was displayed with a KeyError: 'account_code'. ### Steps to reproduce the issue: 1. Select two or more companies from multi company menu 2. Accounting / Reporting / Ledgers / General Ledger 3. Posted Entries, Accrual Basis button 4. Pick Consolidation 5. Error ### Cause of the issue: When more than one company is selected, the General Ledger consolidation groups journal entries by multiple parameters in an increasingly strict hierarchy. One of these parameters is account_code, which is required only in a multi-company context (as account_id alone is sufficient when a single company is selected). However, the SQL query was not properly adapted to handle this case. The account_code field was used as a grouping key but was not retrieved from the database, resulting in a KeyError. ### Reason to introduce the fix: To ensure that the General Ledger consolidation can be correctly displayed in a multi-company context and to prevent runtime errors. opw-5933074
This update restricts the invoicing and bank roles in Odoo Enterprise from using the 'Find Missing Transactions' and 'Find Duplicate Transactions' tools. This change enhances security and prevents potential misuse of these functionalities by less privileged users, while maintaining access for bookkeeper and manager roles.
Original PR description
Changed the accessibility of the role invoicing/bank to not be able to use the following functionalities: 'Find Missing Transactions' 'Find Duplicate Transactions' While keeping the access available for bookkeeper/manager roles. task-6076097
7 changes
Resolved issues and error corrections
This update resolves an error that occurred when users added multiple columns with the same label to the Balance Sheet report, preventing the report from opening correctly. The fix ensures stability by prioritizing the first column record when multiple columns share the same expression label, improving report usability.
Original PR description
Currently, an error occurs when user tries to open a report with two or more columns that have same expression labels. Steps to replicate: - Install `accountant`. - Open `Accounting > Reporting > Balance Sheet`. - Turn on debug mode and click on the button with gear icon in the header. - Go to Columns tab > add new column with expression label as `balance` > save. - Now try to open the report Executive Summary. Error: ``` ValueError: Expected singleton: account.report.column(10, 137) ``` Cause: - As the user made a new column with label `balance` we get two records from the result of `filtered()` and when we try to access its `figure_type` we get error from [here]. Solution: - For stable, we just take the first record from the filtered records. [here]: https://github.com/odoo/enterprise/blob/317890e8af3a9f9de086769a2871fcc28a03c783/account_reports/models/account_report.py#L3443-L3444 sentry-7356996739
This update resolves an issue where the 'Load More' button was hidden when the 'Hide if 0' option was enabled in account reports. The fix filters out 'Load More' lines from zero-value lines, ensuring the button remains visible when appropriate. This improves the user experience by allowing users to easily access additional report data.
Original PR description
When activating the 'Hide if 0' option, the 'Load more' line is hidden. Fix: Filtering out the lines with empty columns (Load more lines) from the zero lines. Steps: - Open GL (occurs with other reports as well), and open configuration for this report - Set Load more limit to 1, and hide if zero to optional - Go back to GL report and select the 'Hide lines at 0' option -> Load more lines are hidden as long as the zero lines opw-5953725
This update fixes an error in the Pakistan localization payroll calculation, specifically related to tax brackets. Previously, the system incorrectly calculated tax for employees with annual salaries exceeding PKR 2,200,000. The fix ensures accurate tax computation based on official Pakistani tax regulations, preventing overpayment of taxes.
Original PR description
Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000. ### **Steps to Reproduce:** 1) Install…
Currently, payslip computation for Pakistan localization calculates incorrect tax when the yearly cost exceeds 2,200,000. ### **Steps to Reproduce:** 1) Install `l10n_pk_hr_payroll_account`,`hr_contract_salary` with demo data. 2) Switch to PK company. 3) Create an employee and a running contract with yearly cost 2,200,001 4) Create a payslip and compute it from the Salary Computation tab. ### **Observed Behavior:** 'Tax Bracket Yearly' is computed as `122000.24` ### **Expected Behavior:** 'Tax Bracket Yearly' should be `116000.24` ### **Root Cause:** since [commit](https://github.com/odoo/enterprise/pull/98345/commits/62f5e216518d83317618d7dbc0be4db92d1881a3), the tax computation relies on [_l10n_pk_get_tax](https://github.com/odoo/enterprise/blob/a9656336583a4d5c5b12d4d6120ec62ba1cf9151/l10n_pk_hr_payroll/models/hr_payslip.py#L9-L20) , In this method, the `result` is incorrectly accumulated with `fix` when iterating through brackets, leading to an inflated tax value. [official pakistan document](https://download1.fbr.gov.pk/Docs/20258181281745641WHT-RateCard.pdf) ### **Fix:** Use `result = fix` instead of `result += fix` so that the cumulative tax is correctly reset at each bracket. **opw-5979265**
This update fixes an issue where subscription product details weren't showing the billing period in product snippets on the website. The fix ensures that all product snippets, including those for subscription products, accurately display the billing period, providing a consistent customer experience. This improves clarity and accuracy for customers viewing products on the website.
Original PR description
Steps to reproduce: 1) Go to the Website app. 2) Add a product snippet to any page using the editor. 3) See product card of any subscription product. Issue: - The billing period is not displayed for subscription products in the product snippet, unlike on the shop page. Cause: - `temporal_unit_display` is not included in the `combination_info`which is passed in data used by the product snippet. Fix: - Include `temporal_unit_display` in `combination_info`. opw-6070943
This update fixes an error that occurred when users added multiple columns with the same label to reports, specifically the Balance Sheet. The fix adds a database constraint to prevent this, ensuring reports display correctly and avoids data inconsistencies. This improves report stability and user experience.
Original PR description
Currently, an error occurs when user tries to open a report with two or more columns that have same expression labels. Steps to replicate: - Install `accountant`. - Open `Accounting > Reporting >…
Currently, an error occurs when user tries to open a report with two or more columns that have same expression labels. Steps to replicate: - Install `accountant`. - Open `Accounting > Reporting > Balance Sheet`. - Turn on debug mode and click on the button with gear icon in the header. - Go to Columns tab > add new column with expression label as `balance` > save. - Now try to open the report Executive Summary. Error: ``` ValueError: Expected singleton: account.report.column(10, 137) ``` Cause: - As the user made a new column with label `balance` we get two records from the result of `filtered()` and when we try to access its `figure_type` we get error from [here]. Solution: - Added an SQL constraint that restricts user from making new columns with label same as an existing column in a report. [here]: https://github.com/odoo/enterprise/blob/317890e8af3a9f9de086769a2871fcc28a03c783/account_reports/models/account_report.py#L3443-L3444 sentry-7356996739 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue that could cause tests to fail when dealing with email messages that are empty. The change adds a safety check to ensure the system doesn't attempt to access data from a null mail message, preventing errors and improving test stability. This ensures consistent and reliable email functionality.
Original PR description
This changes https://github.com/odoo/odoo/pull/230766/changes cause the issue. I fix `AttributeError` when `mail_message` is None in `assertNoMail` method. The method was accessing `mail_message.message_id `without checking if `mail_message` is `None` first, causing a potential crash in test cases. Added a conditional check to safely handle None values before accessing the message_id attribute. @qrtl
This update resolves a memory issue that caused server crashes when calculating cumulated balances for large accounting systems. By optimizing the query to process only relevant move lines, the fix significantly reduces memory usage and processing time, leading to improved system stability and performance. This change enhances the overall efficiency of the accounting module.
Original PR description
The _compute_cumulated_balance() method performs a query over every existing move lines to get a dict associating the record id with the cumulated sum at this point. When there is a lot of move…
The _compute_cumulated_balance() method performs a query over every existing move lines to get a dict associating the record id with the cumulated sum at this point. When there is a lot of move lines, the result returned by fetchall() hits the memory limit and the server crashes. We propose to encapsulate the original query to only return the result for the account move lines present in self. Benchmarks --------------- The following benchmarks were generated with a customization of the account.move.line list view to display the cumulated_balance field. Memory usage during the self.env.cr.execute and the dictionary population: | Operation | Before the fix | After the fix | |---------------|----------------|---------------| | populate dict | 1.5 GB | 17.1 MB | | execute query | 430 MB | 8.3 MB | 100 000 lines were displayed at the same time to get a significant size. So the number of records in self is more than 7 000 000 without the fix and 100 000 with the fix. Time spent in the _compute_cumulated_balance method: | No of AML | Before the fix | After the fix | |-----------|----------------|---------------| | 7 000 000 | 10.4 s | 6.8 s | opw-6053720 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255780
3 changes
Resolved issues and error corrections
This update addresses a limitation in how Odoo updates its product UNSPSC codes. Previously, new codes were only added during initial installation, not subsequent updates. Now, an automated upgrade script runs during module updates to ensure the database always reflects the latest UNSPSC codes, without modifying existing records.
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
This update fixes an issue where payment reminder emails for subscriptions were missing key information like the subscription end date and code. The fix ensures that these details are automatically included in the email template when a payment reminder is manually generated through the email composer. This improves the clarity and accuracy of payment reminders for subscription customers.
Original PR description
### Issue before this commit: When sending a payment reminder email for a subscription using the email composer, the template was not correctly populated with the expected dynamic values. In…
### Issue before this commit: When sending a payment reminder email for a subscription using the email composer, the template was not correctly populated with the expected dynamic values. In particular, fields such as the subscription closing date and the subscription code were missing. ### Steps to reproduce the issue: 1. Install subscription and go to that app 2. Open one subscription 3. Send message > Load template: "Subscription: Payment Reminder" 4. Sentence is incomplete: missing end date of the subscription ### Cause of the issue: The issue was caused by the absence of a proper context injection when rendering the email template from the mail.compose.message wizard. The template relied on context variables like date_close, but these values were not being computed nor passed during manual email composition. Unlike automated flows, the composer did not provide the subscription-specific context required by the template. ### Reason to introduce the fix: The fix introduces a dedicated method to dynamically compute and inject the correct context when the payment reminder template is selected in the email composer. It ensures that the logic is only applied for subscription records (sale.order with is_subscription = True) and specifically for the relevant template. opw-6031613 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a technical issue where syncing cancelled events from Microsoft Calendar would cause an error in Odoo. Now, when a cancelled event is synced, Odoo correctly handles the situation, preventing errors and ensuring data consistency. This improves the reliability of event synchronization.
Original PR description
Before this commit, when syncing events from Microsoft, if there was a cancelled event that was not yet synchronized with Odoo, calling browse on event.odoo_id would raise an error as it would be None. opw-5917677 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr