Daily updates from Odoo
Wednesday, March 25, 2026
294 changes
19 changes
Enhancements to existing features
This update adapts the French accounting import process to changes in how data is delivered from the system. Instead of downloading entire files, data is now streamed, improving efficiency and reducing download times. This ensures accurate and timely reporting for French-speaking customers.
Original PR description
This commit aims to adapt the usage of 'account.fr.fec' to the changes made in community. In particular `fec_data` field is not used any more. and we use `_get_fec_stream` to stream the content of the file. task-5404142 Forward-Port-Of: odoo/enterprise#111153 Forward-Port-Of: odoo/enterprise#102783
Resolved issues and error corrections
This update fixes a previous issue where users couldn't access worksheet properties within the Quality Check process. The changes now display the relevant worksheet tab and add a simple 'Validate' button, streamlining the workflow and improving the overall user experience. This enhances efficiency and clarity for users managing quality checks.
Original PR description
- Display the Worksheet tab to user in Quality Check and Maintenance Request form views when a worksheet template is set. Previously, the tab was hidden, preventing users from viewing or accessing the worksheet properties. - Added a Validate button in the Quality Check form view for worksheet-based checks, allowing users to validate directly based on worksheet property values Removed the Pass and Fail buttons in this case to streamline the validation flow and reduce user confusion. - Remove the worksheet template title from the Quality Check wizard when displaying worksheet properties to provide a cleaner interface. These changes ensure that users can easily access relevant worksheet properties and improve overall UI clarity. Community PR: [254794](https://github.com/odoo/odoo/pull/254794) Task Id: 5955976
This update ensures that future appraisals automatically disappear when an employee leaves the company. It also removes the employee from appraisal roles and archives their personal goals, streamlining the process and preventing outdated data from appearing.
Original PR description
Currently, when an employee leaves the company, their future appraisals remain active and can still be completed. This fix ensures that, upon employee departure: - all future appraisals are removed - the employee is removed from appraisals where they are an appraiser - all their personal goals are archived - only active (non-archived) appraisals are counted in the employee’s smart button task: 6036427
This update resolves a technical error that prevented users from successfully checking out timesheets within the Enterprise version of Odoo. The issue stemmed from an outdated reference to a renamed function, and this fix ensures a smooth and reliable check-out process. This improves usability for sales teams.
Original PR description
Steps to reproduce: - In the home menu of a database, click on the ActivityMenu at top of page (red dot) - Click check in - Click ActivityMenu (green dot) again and click check out Current behavior: - Traceback saying this.displayAllowBillable is not a function Expected behavior: - No error Note: displayAllowBillable was renamed to displayIsBillable in this commit https://github.com/odoo/enterprise/pull/110708 opw-6061392
This update corrects a rounding error in the US payslip PDF that was causing incorrect overtime rates for very short work durations (like seconds). The fix now calculates the rate directly from the work entry, ensuring accurate overtime pay is displayed. This improves the reliability of payroll reports.
Original PR description
The Rate column on the US payslip PDF is computed as amount / hours, but amount is a Monetary field rounded to 2 decimals. For small hour values (e.g. seconds from the attendance app), the rounding error causes us to compute the wrong rate. For example, working 6 seconds of overtime at an hourly rate of $26 with a 1.5x overtime multiplier results in this calculation: $26/hour * 1.5 * 0.00166667 hour = $0.065 ≈ $0.06 We then attempted to calculate the rate in reverse for the PDF: $0.06 / 0.00166667 hour = $35.9999 ≈ $36.00 Because of the rounding that happened, it doesn't show the expected $39/hour rate ($26 * 1.5). We now compute the rate directly from hourly_wage * multiplier on the work entry type instead. This is a manual forward-port of the work in Odoo 18 [1], to instead use the new amount_rate field on hr.work.entry.type instead. task-6052711 [1] https://github.com/odoo/enterprise/pull/111540 Forward-Port-Of: odoo/enterprise#111733
This update fixes a persistent error that occurred when attempting to activate payments through Odoo. The issue stemmed from discrepancies between payment activation status on the provider side and Odoo, leading to a misleading error message. This change ensures payments are correctly activated within Odoo, improving payment processing reliability.
Original PR description
It may be possible that payments are activated on provider side / odoofin side and not on Odoo side, in that case when we want to activate the payments it leads to an userError but the value is never changed on the db so the error will continue to happen indefinitelly. task-5490817
This update resolves an issue where invoices for foreign customers (e.g., from Colombia) generated by Peruvian companies resulted in errors from SUNAT. The change ensures a default 'schemeID' of '0' is used for the receiver identification type, preventing invalid UBL/QR files and ensuring compliance.
Original PR description
In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an…
In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an empty l10n_pe_vat_code, since there are no cross-country dependencies between LATAM identification types. In that case, the generated UBL leaves the receiver identity type empty and SUNAT returns an error like: ``` 2015/2015 - El XML no contiene el tag o no existe informacion del tipo de documento de identidad del receptor... (missing schemeID value). ``` Odoo already defines schemeID = 0 for some foreign identification types in l10n_pe data, but it cannot cover identification types coming from other countries’ localizations (e.g. Colombia): https://github.com/odoo/odoo/blob/18.0/addons/l10n_pe/data/l10n_latam_identification_type_data.xml#L4 This change ensures that, when the partner is not from Peru and the PE VAT code is missing, we fallback the receiver identification type to "0" in: - PartyIdentification/ID/@schemeID - AccountingCustomerParty/AdditionalAccountID - the QR payload identification type field This prevents generating invalid UBL/QR content for foreign customers in multi-country setups. Forward-Port-Of: odoo/enterprise#110324 Forward-Port-Of: odoo/enterprise#105115
A recent update to Odoo Enterprise prevented new approval rules created through the Studio interface from being properly saved, leading to their deletion from the database. This issue arose during the upgrade from version 18.0 to 19.0 and has now been corrected. The fix ensures that newly created approval rules are correctly managed.
Original PR description
Server and automated actions created by the ORM for the purpose of revoking approval rights are created without `noupdate=True` which leads to said records being removed by the ORM becuase of not being found in the source. Such records created on the fly should have `noupdate=True` to prevent that from happening. This bug can be reproduced by going to Settings > Technical > User Interface > Studio Approval Rules and creating a new record from there and updating `web_studio`. The update will drop the record from the database. Issue originally detected in the upgrade process from 18.0 to 19.0. This fix will be complemented by an upgrade script that fixes erronous records. Forward-Port-Of: odoo/enterprise#110065
This update fixes an issue where project budget totals were incorrectly summing expenses and revenue. The fix adjusts how budget amounts are calculated to ensure accurate totals are displayed on the project dashboard, reflecting the true financial status of the project. This improves reporting accuracy and financial oversight.
Original PR description
### Steps to reproduce: - Create a billable project - Create two budgets one expense and the other revenue or both each for 100$ - Create a vendor bill with the analytic account of the created project - Notice in the project dashboard the two budgets are summed up in the total ### Cause: When calculating the total spent and total allocated we add up the amount whether it is an expense or revenue. https://github.com/odoo/enterprise/blob/1dccb87a48ac44735da4c78594e37d4783789cd6/project_account_budget/models/project.py#L120-L121 ### Fix: Set the expense budget to -ve and the revenue/both to +ve amount when calculating the total spent and total allocated opw-5488131 Forward-Port-Of: odoo/enterprise#106504
This update ensures that document creation times are displayed accurately for users, regardless of their location. Previously, times were inconsistent due to a failure to convert dates from UTC to the user's local timezone. Now, all times are correctly formatted, providing a more reliable and user-friendly experience.
Original PR description
Step to reproduce: 1. Install `documents` 2. Upload a document and open the tree view 3. Compare the field `Created On` and the time from the `Manage Versions` action Issue: - The displayed time is inconsistent between the tree view and the dialog Cause: - The datetime used in Manage Versions is formatted without converting it from UTC to the user’s timezone Solution: - Use timezone-aware datetime helpers so values are converted from UTC to the user’s timezone. Before: <img width="1328" height="81" alt="image" src="https://github.com/user-attachments/assets/2a02f03c-714d-417d-a805-fd0dd7c52753" /> <img width="636" height="297" alt="image" src="https://github.com/user-attachments/assets/c4514469-2f51-493f-8991-32371fb7f338" /> After: <img width="641" height="312" alt="image" src="https://github.com/user-attachments/assets/3979ece8-635a-4b54-9b53-d8b28b3336ec" /> opw-5467782 Forward-Port-Of: odoo/enterprise#104443
This update resolves an issue where reports were failing due to missing account IDs in migrated databases. The fix adds a backup system to automatically use account codes when XMLIDs are unavailable, ensuring reports run smoothly without warnings. This improves the reliability of financial reporting.
Original PR description
Description of the issue this commit addresses: On some migrated BE databases, account template refs a4121/a4521 are missing as XMLIDs. l10n_be_reports then fails to recover partner/reconcile account refs and logs warnings during post-init load. --- Desired behavior after this commit is merged: This commit adds a fallback in BE report chart template data to resolve a4121/a4521 by account code when XMLIDs are missing, preventing recovery warnings while keeping normal XMLID behavior unchanged. --- runbot-[233845](https://runbot.odoo.com/odoo/runbot.build.error/233845) Forward-Port-Of: odoo/enterprise#111325
This update corrects a legal requirement for invoices generated using the l10n_gt_edi module. Previously, essential 'complementos' data were missing from the PDF invoices for specific document types (FCAM, FCAP, FESP), while they were present in the XML files. This ensures compliance with Guatemalan tax regulations.
Original PR description
**PROBLEM** For some documents types, the "complementos" are not present in the pdf while they are present in the xml. It's legally required that they are added in the pdf. **STEP TO REPRODUCE** 1. Install l10n_gt_edi. 2. Create an customer invoice. 3. Set the document type to FCAM, FCAP, or FESP. 4. Send the invoice using the cfdi. 5. download the xml and the pdf, notice the complementos are in the xml, but not in the pdf. opw-5970285 Forward-Port-Of: odoo/enterprise#109061
This update fixes a potential issue where a user could indirectly change an employee's work email through salary configuration. Now, the work_email field is protected and won't be reset if the employee is linked to a user, ensuring data integrity and preventing unintended email updates.
Original PR description
Due to https://github.com/odoo/enterprise/pull/106974,the employee's work_email may be reset to False when creating or updating an offer. This behavior is acceptable if the employee does not have a linked user. However, if the employee is linked to a user, resetting work_email can allow a user to indirectly modify their own work_email through salary confi. To prevent this, we now ensure that work_email never changes if employee has a user linked to it. Steps to reproduce: - Hire an applicant from Recruitment (the employee has no work_email). - Set a random work_email and create a user for the employee. - Open the hired applicant and create a new offer to update the contract. - work_email should not be modified, even after new contract. task: 6033382 Forward-Port-Of: odoo/enterprise#111815 Forward-Port-Of: odoo/enterprise#110810
This update corrects an issue preventing Romanian SAFT reports from passing validation. The team restored a key data element and used a sanitized bank account number, ensuring compliance with Romanian tax regulations. This resolves a technical problem that could have impacted report accuracy and processing.
Original PR description
Problem --------- In odoo/odoo#184131 and odoo/enterprise#72206, UOM's categories where removed. Along side the removal, the Description tag in the Romanian SAFT UOM table tag. However, without this node, the SAFT is flagged as invalid by validator in Romanian. Furthermore, in the RO SAF-T, we use the bank account number and not the sanitized one, which may lead to some spaces in the document. Spaces that are not accepted either. Solution --------- Add back the Description node and use the UOM name instead of category. Use the sanitized account number. opw-5956277 Forward-Port-Of: odoo/enterprise#111664
This update resolves a bug where custom snippets created in the website builder didn't correctly display their dynamic content in the preview. The fix ensures that dynamic content is properly reflected when previewing custom snippets, addressing a previous issue related to the website builder refactor. This improves the user experience when creating and testing dynamic website content.
Original PR description
The interaction for filling the dynamic content of dynamic snippets did not run inside the iframe to preview the snippet to add. This is not an issue for the initial dynamic snippet, as they are…
The interaction for filling the dynamic content of dynamic snippets did not run inside the iframe to preview the snippet to add. This is not an issue for the initial dynamic snippet, as they are filled with fake content. But when saving a custom snippet, the dynamic content is cleared, and they seem empty when previewed. This is the case since the [website builder refactor] as the previous builder re-used the preview of the initial snippet. This commit adds the interaction to fill dynamic content in the preview iframe, and changes the interaction to avoid emptying the fake content from initial dynamic snippets during preview. Steps to reproduce: - Open website builder - Add a dynamic snippet (for example "Events") - Save the snippet as a custom snippet - Click on "Custom" snippet category - Bug: The preview for the custom snippet does not have the dynamic part (there is no event, just the title) [website builder refactor]: 9fe45e2b7ddbbfd0445ffe25a859e67a316d02b2 task-5427353 Forward-Port-Of: odoo/enterprise#110696 Forward-Port-Of: odoo/enterprise#108912
This update enables companies to create equity transactions in currencies other than the default USD. Previously, the system was locked to USD, limiting flexibility. Now, the equity currency can be set on the first transaction, ensuring accurate tracking regardless of the company's base currency.
Original PR description
### Issue: When a company is set in USD, it was not possible to create equity transactions in another currency (e.g., EUR) ### Cause: The equity_currency_id is initialized with the company currency at partner creation (or module installation) However, there was no way to override this value when creating transactions ### Fix: It is now possible to set the equity currency on the first transaction Subsequent transactions reuse this currency and the field becomes read-only ### Steps to reproduce: - Install `equity` with demo data (currency and equity_currency default to USD) - Enable the EUR currency - Create an equity transaction for a company - You can now choose EUR on this transaction - Create another transaction for the same company, the selector is hidden and the currency remains EUR opw-5382255 Forward-Port-Of: odoo/enterprise#108248
This update fixes a bug preventing the proper synchronization of XML documents (like e-invoices) related to accounting moves. Previously, invoices created from various sources didn't always attach the original XML files to the Documents app, leading to data discrepancies. Now, all XML attachments are correctly linked, ensuring accurate document tracking.
Original PR description
[FIX] documents_account: sync all XML documents for account moves Before this commit, the synchronization between accounting attachments and the Documents app was incomplete regarding XML files…
[FIX] documents_account: sync all XML documents for account moves Before this commit, the synchronization between accounting attachments and the Documents app was incomplete regarding XML files (e.g., e-invoices, Peppol). This caused several specific issues: 1. When creating an invoice via the Accounting upload interface, only the generated PDF was synced to the correct Documents folder, leaving the original XML file unsynced. 2. When creating an invoice from an existing file in the Documents app (via server action), the system correctly synced the generated PDF, but failed to move or sync the original XML source file to the target folder. 3. When receiving vendor bills via Peppol or other EDI networks, the proxy attaches the fetched XML to the `account.move` via an `ir.attachment` write. Because this bypassed the existing sync filters, the Peppol XMLs were never pushed to the Documents app. This commit updates the `ir.attachment` logic in both `create` and `write`. It ensures that whenever an XML file (mimetype `application/xml` or `text/xml`) is attached to an `account.move`—regardless of the move type or whether it was uploaded manually or fetched via EDI—the document synchronization logic is triggered, properly linking and filing the XML alongside the PDF. Task-5909245 Task-5917535 Forward-Port-Of: odoo/enterprise#111881 Forward-Port-Of: odoo/enterprise#106574
This update resolves an issue where only administrators could delete work entry types within the payroll module. Now, users with SUPERUSER permissions can delete these types, improving flexibility and reducing reliance on administrator intervention. This change ensures smoother management of payroll configurations.
Original PR description
Forward-Port-Of: odoo/enterprise#111967
Features or functions removed from Odoo
This update removes the automatic assignment of a VoIP provider to new users. Previously, users were linked to the first available provider, which created issues for systems with multiple providers. This change ensures a more appropriate 'no provider' default, simplifying setup for businesses with diverse VoIP options.
Original PR description
Following this Pull Request, users will not be linked to any VoIP provider by default. Prior to this Pull Request, users were linked to the first `voip.provider` record found. The rationale behind this behavior has been forgotten, but it was likely implemented to spare admins with a single provider from having to assign one. However, for databases with more than one provider, "nothing" is usually the relevant default. See also: [task-6023412](https://www.odoo.com/odoo/project.task/6023412) Forward-Port-Of: odoo/enterprise#111758
8 changes
New functionality added to Odoo
This update reintroduces the generation of a proxy token for the l10n_eg_iot module, specifically to support the Egyptian VAT (IoT) functionality. Previously, a modal was used to display the token, which was deemed unnecessary by most users. Now, the token is displayed directly in the database for this module, streamlining the process for Egyptian users.
Original PR description
Proxy token generation was removed to avoid showing a modal with a token nobody cares about except Egypt. We reintroduce token generation, but display it to the database instead of showing a modal. see odoo/odoo#255121 Forward-Port-Of: odoo/enterprise#111496
Resolved issues and error corrections
This update resolves a technical issue that caused warnings during the initial setup of reports for Belgian accounting. The fix ensures that report generation works correctly by providing a backup method for identifying account references, even when standard XMLIDs are missing. This improves the reliability of financial reporting.
Original PR description
Description of the issue this commit addresses: On some migrated BE databases, account template refs a4121/a4521 are missing as XMLIDs. l10n_be_reports then fails to recover partner/reconcile account refs and logs warnings during post-init load. --- Desired behavior after this commit is merged: This commit adds a fallback in BE report chart template data to resolve a4121/a4521 by account code when XMLIDs are missing, preventing recovery warnings while keeping normal XMLID behavior unchanged. --- runbot-[233845](https://runbot.odoo.com/odoo/runbot.build.error/233845) Forward-Port-Of: odoo/enterprise#111325
This update corrects a technical issue where certain invoice PDFs (specifically for FCAM, FCAP, and FESP document types) were missing legally required 'complementos' data. The fix ensures that all invoices generated using the l10n_gt_edi module comply with tax regulations, preventing potential compliance problems. This change improves data accuracy and reduces risk.
Original PR description
**PROBLEM** For some documents types, the "complementos" are not present in the pdf while they are present in the xml. It's legally required that they are added in the pdf. **STEP TO REPRODUCE** 1. Install l10n_gt_edi. 2. Create an customer invoice. 3. Set the document type to FCAM, FCAP, or FESP. 4. Send the invoice using the cfdi. 5. download the xml and the pdf, notice the complementos are in the xml, but not in the pdf. opw-5970285 Forward-Port-Of: odoo/enterprise#109061
This update ensures that changes to a subscription's salesperson are automatically reflected on all associated contacts. Previously, updates only applied to the company partner, leading to inconsistencies. This improvement streamlines workflows and eliminates manual data updates.
Original PR description
Before this commit, changing the salesperson on a subscription only updated the company partner, leaving child contacts with outdated salesperson info. After this commit, updating the subscription's salesperson also updates all child contacts of the company, ensuring consistency across the portal and reducing manual work. An unit test was added to ensure this behavior. task-5917271 Forward-Port-Of: odoo/enterprise#111499 Forward-Port-Of: odoo/enterprise#108339
This update resolves an issue where equity transactions couldn't be created in currencies other than the company's default (USD). Now, users can set the equity currency for the first transaction, ensuring flexibility and accuracy when managing equity values in multiple currencies. Subsequent transactions will automatically use this selected currency.
Original PR description
### Issue: When a company is set in USD, it was not possible to create equity transactions in another currency (e.g., EUR) ### Cause: The equity_currency_id is initialized with the company currency at partner creation (or module installation) However, there was no way to override this value when creating transactions ### Fix: It is now possible to set the equity currency on the first transaction Subsequent transactions reuse this currency and the field becomes read-only ### Steps to reproduce: - Install `equity` with demo data (currency and equity_currency default to USD) - Enable the EUR currency - Create an equity transaction for a company - You can now choose EUR on this transaction - Create another transaction for the same company, the selector is hidden and the currency remains EUR opw-5382255 Forward-Port-Of: odoo/enterprise#108248
This update resolves a bug where removing an EPD line in bank reconciliation incorrectly removed associated tax lines. Now, only the EPD line and its corresponding tax line are properly removed, ensuring accurate reconciliation reporting. This improves the reliability of bank statement processing.
Original PR description
When removing an EPD line in the bank rec widget, if the invoice line added to the statement line contained a tax, the invoice line was removed aswell. Now, only the EPD line and its tax line are removed. no-task Forward-Port-Of: odoo/enterprise#110514
This update resolves a technical issue preventing users from generating VSME and CSRD reports within the ESG app. The fix removes an unnecessary check in the report search process, which was causing an error. This ensures reports can now be successfully printed.
Original PR description
Steps to reproduce:
1. From Accounting, create a Vendor bill with today's date, and containing a line
2. Confirm (post) it
3. Make the Payment ('Pay' stat button)
4. Create a VSME or CSRD report from the ESG App, for the current year
5. Try to print it
=> A traceback occurs (in _get_payment_terms_data()) as we are trying to search on the 'active' field of account.move, which does not exist. => Solution: remove this uneeded check
version-19.0
Forward-Port-Of: odoo/enterprise#111816This update prevents data merge operations from silently failing due to timeouts. Instead, a warning is displayed, suggesting users merge smaller groups of records. Upon successful completion, the model is automatically reloaded, ensuring data integrity and a smoother user experience.
Original PR description
Display a warning notification when the merge operation times out instead of failing silently. Suggest merging fewer records and reload the model on success. task-5912855 Forward-Port-Of: odoo/enterprise#110763
10 changes
Resolved issues and error corrections
A recent update caused Studio Approval Rules to be unexpectedly deleted from the database during updates. This fix prevents the ORM from removing these rules, ensuring they remain active. The issue was triggered during an upgrade from 18.0 to 19.0 and is now resolved.
Original PR description
Server and automated actions created by the ORM for the purpose of revoking approval rights are created without `noupdate=True` which leads to said records being removed by the ORM becuase of not being found in the source. Such records created on the fly should have `noupdate=True` to prevent that from happening. This bug can be reproduced by going to Settings > Technical > User Interface > Studio Approval Rules and creating a new record from there and updating `web_studio`. The update will drop the record from the database. Issue originally detected in the upgrade process from 18.0 to 19.0. This fix will be complemented by an upgrade script that fixes erronous records. Forward-Port-Of: odoo/enterprise#110065
This update fixes an issue where project budget totals were incorrectly summing expense and revenue amounts. The fix ensures that expenses and revenue budgets are calculated and displayed accurately within the project dashboard, providing a more precise view of project financial status. This improves reporting accuracy and helps users manage project budgets effectively.
Original PR description
### Steps to reproduce: - Create a billable project - Create two budgets one expense and the other revenue or both each for 100$ - Create a vendor bill with the analytic account of the created project - Notice in the project dashboard the two budgets are summed up in the total ### Cause: When calculating the total spent and total allocated we add up the amount whether it is an expense or revenue. https://github.com/odoo/enterprise/blob/1dccb87a48ac44735da4c78594e37d4783789cd6/project_account_budget/models/project.py#L120-L121 ### Fix: Set the expense budget to -ve and the revenue/both to +ve amount when calculating the total spent and total allocated opw-5488131 Forward-Port-Of: odoo/enterprise#106504
This update ensures that document creation times are displayed accurately for users, regardless of their location. Previously, times were inconsistent due to a failure to convert dates from UTC to the user's local timezone. Now, all times are correctly formatted for each user, improving the overall user experience.
Original PR description
Step to reproduce: 1. Install `documents` 2. Upload a document and open the tree view 3. Compare the field `Created On` and the time from the `Manage Versions` action Issue: - The displayed time is inconsistent between the tree view and the dialog Cause: - The datetime used in Manage Versions is formatted without converting it from UTC to the user’s timezone Solution: - Use timezone-aware datetime helpers so values are converted from UTC to the user’s timezone. Before: <img width="1328" height="81" alt="image" src="https://github.com/user-attachments/assets/2a02f03c-714d-417d-a805-fd0dd7c52753" /> <img width="636" height="297" alt="image" src="https://github.com/user-attachments/assets/c4514469-2f51-493f-8991-32371fb7f338" /> After: <img width="641" height="312" alt="image" src="https://github.com/user-attachments/assets/3979ece8-635a-4b54-9b53-d8b28b3336ec" /> opw-5467782 Forward-Port-Of: odoo/enterprise#104443
This update corrects a legal issue where certain invoice PDFs generated by the l10n_gt_edi module were missing required tax complements. The fix ensures that all invoices for document types FCAM, FCAP, and FESP now include these complements in the PDF format, complying with legal requirements. This prevents potential compliance problems.
Original PR description
**PROBLEM** For some documents types, the "complementos" are not present in the pdf while they are present in the xml. It's legally required that they are added in the pdf. **STEP TO REPRODUCE** 1. Install l10n_gt_edi. 2. Create an customer invoice. 3. Set the document type to FCAM, FCAP, or FESP. 4. Send the invoice using the cfdi. 5. download the xml and the pdf, notice the complementos are in the xml, but not in the pdf. opw-5970285 Forward-Port-Of: odoo/enterprise#109061
This update prevents data merge operations from silently failing due to timeouts. Instead, a warning notification is displayed, suggesting users reduce the number of records merged and reloading the model upon successful completion. This enhances the reliability and user experience of the data cleaning process.
Original PR description
Display a warning notification when the merge operation times out instead of failing silently. Suggest merging fewer records and reload the model on success. task-5912855 Forward-Port-Of: odoo/enterprise#110763
This update corrects an issue where ISO20022 files generated for Swiss companies were being incorrectly formatted, leading to bank rejections. The fix ensures the correct 'PAIN 09' version is used, resolving compatibility problems and allowing successful file transmission to banks. This upgrade dynamically updates existing databases to maintain compliance.
Original PR description
To reproduce the issue:
- Create a database in 17.0, with a Swiss company, and install account_sepa. Make sure the bank journal uses the Swiss IS020022 PAIN version.
- Migrate this database to 18.0
- Generate an ISO20022 xml file for the Swiss company
==> The file is wrongly formatted, and will be rejected by the bank.
This happens because the sepa_pain_version field of the journal is still set to its old selection value ('pain.001.001.03.ch.02') after migration, which is not supported anymore. The ORM hence returns an empty value when accessing the selection field, and does not enter the proper conditions when generating the file.
An upgrade fix has been made here https://github.com/odoo/upgrade/pull/9771. This commit makes sure already-migrated databases dynamically fix the issue as well.
opw-6060612
Forward-Port-Of: odoo/enterprise#111949This update resolves a recurring issue where the Italian POS printer would generate errors when the system was offline. The fix adds a safety mechanism to gracefully handle offline scenarios, preventing tracebacks and ensuring smoother operation for users with intermittent internet connections. This improves the reliability of the Italian POS system.
Original PR description
When loosing internet connexion a lot of tracebacks appear is the pos if we use the italian fiscal printer. Steps to reproduce: ------------------- * Setup italian fiscal printer for a shop * Open shop * Turn wi-fi off * Add items to cart * Go to payment screen > Traceback * Add a payment and validate > Traceback Why the fix: ------------ Don't try to reach the printer if we're offline regarding the price to pay. We add a try catch block around the call for printing the receipt. If the try block fails when the network is offline we assume it's just because of the offline mode. If it failed while online we raise the error. opw-5432090 Forward-Port-Of: odoo/enterprise#110326 Forward-Port-Of: odoo/enterprise#105515
This update resolves an issue where only administrators could delete work entry types within the payroll module. Now, users with SUPERUSER permissions can delete these types, streamlining payroll configuration and reducing reliance on technical support. This change improves operational efficiency for HR and payroll teams.
Original PR description
Forward-Port-Of: odoo/enterprise#111967
This update resolves a problem where translations were not appearing correctly in the Chilean E-Invoicing module, specifically on Ubuntu Jammy and Debian Bookworm operating systems. The change converts a complex list comprehension to a standard for loop, ensuring accurate translation lookup and functionality.
Original PR description
This commit transforms the list comprehension into a regular for loop to avoid the translation missing context when looking up for lang. Note: the issue appeared more specifically on Ubuntu Jammy and Debian Bookworm. runbot-240951 Forward-Port-Of: odoo/enterprise#111147
This update addresses a potential issue where automated email verification services (Mail Defender) could inadvertently trigger appointment cancellations. The system has been updated to replace direct links with a form, preventing these bots from interacting with the appointment functionality. This ensures appointments are handled correctly and reliably.
Original PR description
…ointments Mail defender services may click URLs in emails to verify their contents. Additionally they may sometimes interact with the page and visit related pages. For this reason URLs sent in emails should not trigger any action directly nor contain any simple link that could trigger an action. The "cancel/reschedule" anchor URL is replaced with a form which bots should not click. We also port the fix done in appointment to the view in appointment as it replaces the original view in this module. task-4555579 Forward-Port-Of: odoo/enterprise#111879 Forward-Port-Of: odoo/enterprise#79831
25 changes
Resolved issues and error corrections
This update fixes an issue where scanning a serial number barcode in work orders incorrectly identified the wrong inventory location. The fix adds a location filter to ensure the system always selects the correct warehouse or stock location for the scanned component, improving accuracy and preventing stock discrepancies.
Original PR description
Steps to reproduce: - Create a database in saas-18.3 or above. - Install mrp_workorder. - Create a storable product tracked by serial number. - Either purchase the product from a vendor (a…
Steps to reproduce: - Create a database in saas-18.3 or above. - Install mrp_workorder. - Create a storable product tracked by serial number. - Either purchase the product from a vendor (a Partners/Vendors quant with negative quantity will be generated) or confirm a Manufacturing Order (a Production quant with negative quantity will be generated). - Create a Manufacturing Order using this product as a component. - In the Shop Floor, scan the serial number barcode to add the component. - Check the location of the scanned component. Issue: - When scanning a barcode in the Shop Floor, searches for a quant matching the serial number with no location filter. Because of this, it returns whichever quant has the lowest database ID — which is the Partners/Vendors quant created during the vendor receipt (quantity = -1), instead of the correct WH/Stock quant (quantity = +1). Solution: - To resolve this issue, a location filter ( source location) and have been added to the quant search. As a result, always returns the correct quant from the move's source location with positive stock. opw-5974474
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 selected quantity of each item, resolving a discrepancy in the Point of Sale system. This improves the accuracy of sales 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
A test failure in the restaurant POS module was caused by a timing issue during order synchronization. The test incorrectly added order lines while a synchronization process was still running, leading to data overwrites. This fix ensures the test runs correctly and highlights a potential data inconsistency.
Original PR description
The tour `test_preset_timing_restaurant` from the test suite was failing because the steps were executed too quickly. When creating a new order, the preset timing popup is opened, which triggers a synchronization of the order. At that moment, the order has no order lines, and the synchronization takes some time to complete. During this delay, the tour adds a new order line while the sync is still in progress. As a result, when the `sync_from_ui` response returns, the frontend data is updated with the synchronized order (which still has no order lines), overriding the order line that was just added. runbot error: 234567 --- Runbot Error: https://runbot.odoo.com/odoo/runbot.build.error/234567
This update corrects errors in the Romanian SAFT (SAF-T) report generation, specifically addressing issues flagged by the Romanian validator. The fix restores a key data element and uses a sanitized bank account number, ensuring compliance with reporting standards and preventing validation failures.
Original PR description
Problem --------- In odoo/odoo#184131 and odoo/enterprise#72206, UOM's categories where removed. Along side the removal, the Description tag in the Romanian SAFT UOM table tag. However, this is the SAFT without this node is flagged as invalid by validator in Romanian. Furthermore, in the RO SAF-T, we use the bank account number and not the sanitized one, which may lead to some spaces in the document. Spaces that are not accepted either. Solution --------- Add back the Description node and use the UOM name instead of category. Use the sanitized account number. opw-5956277 Forward-Port-Of: odoo/enterprise#111664
This update significantly speeds up the process of creating manufacturing orders when a sale order triggers a large BoM. Previously, the system recalculated cost shares repeatedly, causing delays. Now, a caching mechanism avoids this redundant calculation, resulting in much faster order processing times.
Original PR description
Before this commit, confirming a Sale Order that creates a Manufacturing Order for a product with a large BoM could take several minutes when `purchase_mrp` was installed. The slowdown comes from…
Before this commit, confirming a Sale Order that creates a Manufacturing Order for a product with a large BoM could take several minutes when `purchase_mrp` was installed. The slowdown comes from `mrp.bom.line._get_cost_share()`, which is called for every line during a BoM explosion. When no explicit `cost_share` is set, the method recomputes the list of eligible BoM lines and checks whether any of them has a manual cost share. That computation depends only on the BoM and the product variant, but it is recomputed for every exploded line during `mrp.bom.explode()`. This causes a full BoM scan to be repeated for every single line. This commit introduces a contextual cache, initialized in `mrp.bom.explode()`, to store that metadata. We compute it once and reuse it for all lines of the same (BoM, variant) within the same explosion. ### Benchmark: | BoM lines | Before PR | After PR | | --- | ---: | ---: | | 100 | 3.747s | 1.094s | | 300 | 26.554s | 2.826s | | 600 | 85.378s | 5.299s | | 992 | 229.246s | 9.068s | opw-6017626 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254868
This update corrects a potential issue where Italian VAT invoices were incorrectly processing withholding reasons. The change broadens the system's search to allow taxes with the same withholding type to be used during import, even if the specific reason doesn't match. This ensures more accurate VAT withholding calculations for Italian businesses.
Original PR description
Some invoice come in with a wrong ENASARCO withholding reason. We now broaden the search to allow taxes with the same withholding type to be used during import even if the withholding reason doesn't match. In the test, I change the Enasarco tax to reason Q to check that it gets correctly assigned. Ticket [link](https://www.odoo.com/odoo/project.task/5175587), [link](https://www.odoo.com/odoo/project.task/5933699) opw-5175587 opw-5933699 Forward-Port-Of: odoo/odoo#251734 Forward-Port-Of: odoo/odoo#236251
This update fixes a bug that prevented the Google address autocomplete feature from working correctly when certain modules modified address fields. The change adds a new widget to street fields and handles address autocomplete across e-commerce and internal address forms, ensuring accurate address suggestions.
Original PR description
_= base,base_address_extended,google_address_autocomplete,website_sale_autocomplete The Google autocomplete feature was breaking when modules such as base_extended_address modified the address form (e.g., replacing street with street_name, street_number, etc.). In this commit: --- - Add the Google autocomplete widget to street-related fields. - Also same thing handled in frontened (e-commerce address autocomplete). - and update 'city_id' from available cities records if matches with google result. - ```update access_rights for RecCity Model - grant read access to public user``` --- task-5382984 opw-5362597 Forward-Port-Of: odoo/odoo#238672
A recent update to Odoo Enterprise prevented the deletion of newly created approval rules within the Studio module. This issue arose during an upgrade from version 18.0 to 19.0 and was caused by the way the system automatically updated these records. This fix ensures that these records are properly managed, preventing data loss.
Original PR description
Server and automated actions created by the ORM for the purpose of revoking approval rights are created without `noupdate=True` which leads to said records being removed by the ORM becuase of not being found in the source. Such records created on the fly should have `noupdate=True` to prevent that from happening. This bug can be reproduced by going to Settings > Technical > User Interface > Studio Approval Rules and creating a new record from there and updating `web_studio`. The update will drop the record from the database. Issue originally detected in the upgrade process from 18.0 to 19.0. This fix will be complemented by an upgrade script that fixes erronous records. Forward-Port-Of: odoo/enterprise#110065
This update prevents data merge operations from failing silently when they take too long. Instead, a warning is displayed, suggesting users merge smaller groups of records. Upon successful completion, the model is automatically reloaded, ensuring data consistency and a smoother user experience.
Original PR description
Display a warning notification when the merge operation times out instead of failing silently. Suggest merging fewer records and reload the model on success. task-5912855 Forward-Port-Of: odoo/enterprise#110763
This update fixes an issue where kit products were incorrectly reporting the full sales price of each component in delivery DDTs. Previously, the system didn't properly account for kits, leading to inflated values. Now, the delivery DDT accurately reflects the value of each component within the kit.
Original PR description
Steps to reproduce: - Have an IT company setup - Create a product with a Sales Price and define a kit BOM with 2 components - Create SO with product - Confirm, go to delivery, validate - Print Issue: In the delivery DDT, there is a summary of the delivery where each item has its own entry (product, quantity, value). However, in case of kit BOM, each component is reported with the full value of the sale operation. Analysis: This occurs because in the report code we don't consider the possibility of kit products, where multiple components are associated to the same sale line. Ticket [link](https://www.odoo.com/odoo/project.task/5013606) opw-5013606 Forward-Port-Of: odoo/odoo#255435 Forward-Port-Of: odoo/odoo#224103
This update fixes an issue where project budget totals were incorrectly summing expense and revenue budgets. The fix adjusts how the system calculates totals, ensuring that expenses and revenue budgets are treated as separate values when displaying the overall project financial status. This improves the accuracy of project reporting.
Original PR description
### Steps to reproduce: - Create a billable project - Create two budgets one expense and the other revenue or both each for 100$ - Create a vendor bill with the analytic account of the created project - Notice in the project dashboard the two budgets are summed up in the total ### Cause: When calculating the total spent and total allocated we add up the amount whether it is an expense or revenue. https://github.com/odoo/enterprise/blob/1dccb87a48ac44735da4c78594e37d4783789cd6/project_account_budget/models/project.py#L120-L121 ### Fix: Set the expense budget to -ve and the revenue/both to +ve amount when calculating the total spent and total allocated opw-5488131 Forward-Port-Of: odoo/enterprise#106504
This update ensures that document creation times are displayed accurately for users, regardless of their location. Previously, times were inconsistent between the document tree view and version management tools due to a UTC timezone issue. This fix converts all datetime values to the user's local timezone for a more reliable and user-friendly experience.
Original PR description
Step to reproduce: 1. Install `documents` 2. Upload a document and open the tree view 3. Compare the field `Created On` and the time from the `Manage Versions` action Issue: - The displayed time is inconsistent between the tree view and the dialog Cause: - The datetime used in Manage Versions is formatted without converting it from UTC to the user’s timezone Solution: - Use timezone-aware datetime helpers so values are converted from UTC to the user’s timezone. Before: <img width="1328" height="81" alt="image" src="https://github.com/user-attachments/assets/2a02f03c-714d-417d-a805-fd0dd7c52753" /> <img width="636" height="297" alt="image" src="https://github.com/user-attachments/assets/c4514469-2f51-493f-8991-32371fb7f338" /> After: <img width="641" height="312" alt="image" src="https://github.com/user-attachments/assets/3979ece8-635a-4b54-9b53-d8b28b3336ec" /> opw-5467782 Forward-Port-Of: odoo/enterprise#104443
This update corrects a legal requirement for invoices generated using the l10n_gt_edi module. Previously, certain invoice document types (FCAM, FCAP, FESP) lacked essential 'complementos' attachments in the PDF version, while they were present in the XML. This fix ensures compliance with tax regulations.
Original PR description
**PROBLEM** For some documents types, the "complementos" are not present in the pdf while they are present in the xml. It's legally required that they are added in the pdf. **STEP TO REPRODUCE** 1. Install l10n_gt_edi. 2. Create an customer invoice. 3. Set the document type to FCAM, FCAP, or FESP. 4. Send the invoice using the cfdi. 5. download the xml and the pdf, notice the complementos are in the xml, but not in the pdf. opw-5970285 Forward-Port-Of: odoo/enterprise#109061
This update fixes an issue where invoices generated with the l10n_dk_nemhandel module were incorrectly using the VAT number instead of the company partner's EAN/GLN as the EndpointID for Nemhandel transmissions. This ensures accurate data transmission and compliance with Danish regulations. The change ensures invoices are properly formatted for electronic payment processing.
Original PR description
**STEP TO REPRODUCE** 1. install l10n_dk_nemhandel, and activate nemhandel. 2. Create a company partner, with a EAN/GLN as the nemhandel id. 3. Create an individual partner linked to the company partner. 4. Create an invoice with this individual partner. 5. Send the invoice with nemhandel. 6. open the xml file, and notice that the EndpointID doesn't use the EAN/GLN of the company partner. (It falls back to the VAT instead). opw-5945440 Forward-Port-Of: odoo/odoo#251783
This update fixes a problem where the AI chat feature was incorrectly showing the 'OOO' banner and engaging in self-conversations. The change ensures that AI conversations correctly identify a real agent correspondent, preventing these unwanted behaviors and improving the overall user experience.
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
This update fixes an issue where receipts were displaying company information twice. The problem arose after a previous code change. This ensures that receipts consistently show the correct company details for customers.
Original PR description
Before this commit, the receipt was showing the company information twice. It happened after the commit https://github.com/odoo/odoo/commit/dca40d16481ba504d608cc65d82e7821e01c5932. opw-6053013 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes a vulnerability where email bots could automatically cancel meetings by visiting links in invitation emails. We’ve changed how meeting invitations are sent to include buttons instead of direct links, preventing bots from triggering unwanted actions. This improves security and ensures meetings are only cancelled by users.
Original PR description
Mails are sent to users containing an acceptation and cancellation link that accepts GET requests but performs an action on visit Some mail defender software analyzes urls in links by actually visiting the URL. This leads to both actions being triggered without user input. Instead we now send buttons with a neutralizing parameter in the mail. Recipients may then visit the url and click a form button to "accept" or "decline". As these are post requests, the email bots should avoid clicking them. task-4555579 Forward-Port-Of: odoo/odoo#254692 Forward-Port-Of: odoo/odoo#198560
This update addresses a technical issue where Mail Defender services were inadvertently cancelling appointments through automated URL clicks. To resolve this, the system has been updated to use a form instead of a direct link for cancellation/rescheduling, preventing unintended actions by bots. This ensures appointments are handled correctly and reliably.
Original PR description
…ointments Mail defender services may click URLs in emails to verify their contents. Additionally they may sometimes interact with the page and visit related pages. For this reason URLs sent in emails should not trigger any action directly nor contain any simple link that could trigger an action. The "cancel/reschedule" anchor URL is replaced with a form which bots should not click. We also port the fix done in appointment to the view in appointment as it replaces the original view in this module. task-4555579 Forward-Port-Of: odoo/enterprise#111159 Forward-Port-Of: odoo/enterprise#79831
This update resolves a performance issue during testing by proactively generating Odoo's bundled code. Previously, bundles were created on-the-fly during tests, causing delays. Now, the system identifies and pregenerates these bundles, resulting in faster and more reliable test execution.
Original PR description
tl;dr: look for lazy loaded bundles and add them to the bundles' list to pregenerate before running tests to avoid generation on the fly. Forward-Port-Of: odoo/odoo#248256
This update corrects a potential issue where an employee's work email could be unintentionally modified when linked to a user. This change ensures data integrity by preventing unauthorized email updates, particularly for employees connected to a user account. It maintains consistent employee data and avoids potential conflicts.
Original PR description
Due to https://github.com/odoo/enterprise/pull/106974 employee's work_email may be reset to False when creating or updating an offer. This behavior is acceptable if the employee does not have a linked user. However, if the employee is linked to a user, resetting work_email can allow a user to indirectly modify their own work_email through salary confi. To prevent this, we now ensure that work_email never changes if employee has a user linked to it. ### Steps to reproduce: - Hire an applicant from Recruitment (the employee has no work_email). - Set a random work_email and create a user for the employee. - Open the hired applicant and create a new offer to update the contract. - work_email should not be modified, even after new contract. task: 6033382 Forward-Port-Of: odoo/enterprise#111821 Forward-Port-Of: odoo/enterprise#111243
This update corrects a technical issue within the website editor that prevented users from correctly loading custom snippets, specifically related to Google Maps. The fix ensures that custom snippets are not loaded when the base snippet is disabled, improving the user experience and preventing errors.
Original PR description
Steps to reproduce: 1. Go to the website editor (ensure developer mode is off) 2. Drag and drop a Map snippet onto the page 3. Click on the newly placed snippet and save it as a custom snippet 4.…
Steps to reproduce: 1. Go to the website editor (ensure developer mode is off) 2. Drag and drop a Map snippet onto the page 3. Click on the newly placed snippet and save it as a custom snippet 4. Enable developer mode and refresh the website editor 5. Add a new Google Map snippet to the page a. The Google Map snippet is the one where the icon shows a map with a pin on the **left side**. 6. In the wizard, enter your valid API key and click Save a. Alternatively, you can use Odoo inspector to write any string into the `google_maps_api_key` field of the `website` model to simulate the above 7. Disable developer mode and refresh the website editor 8. Click one of the categories in the editor side panel to open the snippets browser 9. Click into the 'Custom' snippets category 10. Observe the error Depending on whether or not you have a Google Maps API key configured on your website, either the `s_map` or `s_google_map` base snippet will be disabled/hidden. When a user has created custom snippets out of the disabled base snippet, you will recieve the error mentioned above when the snippet browser attempts to load in these custom snippets, as it will be unable to load the base snippet. To fix this, we check if an original snippet was found when loading in a custom snippet. If not, we will not load in the custom snippet to avoid confusion. This error does not occur in Developer Mode, as both base snippets are always enabled in this case. Aditionally, we also clarify which snippet is the Google Map snippet to avoid confusion for the user when creating custom snippets. opw-5933787 Forward-Port-Of: odoo/odoo#250236
This update corrects a bug where manual Stripe payments (SEPA Direct Debit) were immediately canceled despite the transaction remaining in 'Pending' status. This prevented subscriptions from correctly reflecting payments and could lead to automatic closures. The fix ensures payments remain in the correct 'Pending' state until Stripe confirms the transaction.
Original PR description
**Problem:** When manually registering a payment using a Stripe SEPA Direct Debit token, the associated `account.payment` is immediately canceled, even though the Stripe transaction is in "Pending"…
**Problem:** When manually registering a payment using a Stripe SEPA Direct Debit token, the associated `account.payment` is immediately canceled, even though the Stripe transaction is in "Pending" status. Later, when Stripe confirms the transaction, the payment remains canceled, leading to subscription closures after 90 days of apparent non-payment. **Steps to reproduce:** 1) Set a customer address to Belgium and add a SEPA Direct Debit payment token via Stripe. 2) Change the company currency to euro. 4) Create a manual invoice for that customer. 5) Pay the invoice using the pre-configured Stripe SEPA token. 6) Observe the `account.payment` is immediately canceled despite the transaction being "Pending". 7) When Stripe confirms the transaction, the payment stays canceled. **Cause:** In `account_payment.action_post()`, after sending the payment request, all payments whose transaction state was not `done` were canceled. For asynchronous payment methods like SEPA Direct Debit, the transaction starts in `pending` (not `done`), so the payment was wrongly canceled. **Solution:** - Only cancel payments whose transaction ended in a failure state (not in `done`, `pending`, or `authorized`), so pending/authorized payments stay in draft/in_process. opw-5934381 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253876
This update corrects an issue where ISO20022 files generated for Swiss companies were being incorrectly formatted, leading to bank rejections. The fix ensures the correct 'PAIN 09' version is used, resolving compatibility problems and preventing failed file submissions. This upgrade dynamically updates existing databases to maintain proper file formatting.
Original PR description
To reproduce the issue:
- Create a database in 17.0, with a Swiss company, and install account_sepa. Make sure the bank journal uses the Swiss IS020022 PAIN version.
- Migrate this database to 18.0
- Generate an ISO20022 xml file for the Swiss company
==> The file is wrongly formatted, and will be rejected by the bank.
This happens because the sepa_pain_version field of the journal is still set to its old selection value ('pain.001.001.03.ch.02') after migration, which is not supported anymore. The ORM hence returns an empty value when accessing the selection field, and does not enter the proper conditions when generating the file.
An upgrade fix has been made here https://github.com/odoo/upgrade/pull/9771. This commit makes sure already-migrated databases dynamically fix the issue as well.
opw-6060612
Forward-Port-Of: odoo/enterprise#111949This update resolves an issue preventing superuser administrators from deleting obsolete work entry types within the Odoo Enterprise payroll module. This change allows for better management of payroll configurations and ensures users have the necessary permissions to maintain accurate payroll settings. It improves operational efficiency and reduces potential data inconsistencies.
Original PR description
Forward-Port-Of: odoo/enterprise#111967
This update corrects a problem with translations in the Chilean VAT reporting module (l10n_cl_edi_factoring). The change improved how translations were handled, specifically on Ubuntu Jammy and Debian Bookworm operating systems. This ensures accurate VAT reporting for our Chilean customers.
Original PR description
This commit transforms the list comprehension into a regular for loop to avoid the translation missing context when looking up for lang. Note: the issue appeared more specifically on Ubuntu Jammy and Debian Bookworm. runbot-240951 Forward-Port-Of: odoo/enterprise#111147
9 changes
Resolved issues and error corrections
This update automatically removes all scheduled future appraisals and associated data when an employee leaves the company. It also removes the employee from appraisal roles and archives their personal goals, ensuring data accuracy and a cleaner system after departures. This improves the HR process and reduces manual effort.
Original PR description
Currently, when an employee leaves the company, their future appraisals remain active and can still be completed. This fix ensures that, upon employee departure: - all future appraisals are removed - the employee is removed from appraisals where they are an appraiser - all their personal goals are archived task: 6036427
This update prevents data merge operations from silently failing due to timeouts. Instead, a warning notification is displayed, guiding users to merge smaller groups of records and reload the model upon successful completion. This enhances the reliability of the data cleaning process.
Original PR description
Display a warning notification when the merge operation times out instead of failing silently. Suggest merging fewer records and reload the model on success. task-5912855 Forward-Port-Of: odoo/enterprise#110763
This update corrects a technical issue where the system was incorrectly limiting VAT numbers submitted to FedEx, causing problems for customers using VAT numbers with longer formats (like in Switzerland). The change ensures that VAT numbers are properly transmitted to FedEx, preventing delivery errors and maintaining accurate data.
Original PR description
Issue ----- Fedex limits VAT numbers to 18 char long strings. This is contradictory with how they are stored in db for some countries (eg Switzerland, where the format is CHE-123.456.788 VAT -> 19 char long). Steps to reproduce ----- - Setup Fedex - Create a customer - Company (for VAT number) - VAT number: CHE-123.456.788 TVA - Create a delivery and confirm it Cause ----- VAT number is retrieved as is in https://github.com/odoo/enterprise/blob/0220d413988708c662ffca3c7fb38641c3d9870a/delivery_fedex_rest/models/fedex_request.py#L332-L343 ----- Ticket: opw-5926452 Forward-Port-Of: odoo/enterprise#109999
A recent bug prevented newly created approval rules in the Studio interface from being properly saved, leading to their automatic deletion. This issue arose during an upgrade from version 18.0 to 19.0 and was triggered by how the system created records for revoking approval rights. The fix ensures these records are created with a flag preventing automatic deletion.
Original PR description
Server and automated actions created by the ORM for the purpose of revoking approval rights are created without `noupdate=True` which leads to said records being removed by the ORM becuase of not being found in the source. Such records created on the fly should have `noupdate=True` to prevent that from happening. This bug can be reproduced by going to Settings > Technical > User Interface > Studio Approval Rules and creating a new record from there and updating `web_studio`. The update will drop the record from the database. Issue originally detected in the upgrade process from 18.0 to 19.0. This fix will be complemented by an upgrade script that fixes erronous records. Forward-Port-Of: odoo/enterprise#110065
This update corrects a bug in the Belgian payroll module that incorrectly calculated canteen costs for employees with no attendance. The fix ensures that canteen costs are only applied when the employee has recorded actual working hours, preventing incorrect charges. This improves payroll accuracy for Belgian companies.
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#110991This update fixes an issue where project budget totals were incorrectly summing expense and revenue amounts. The change adjusts how budgets are calculated, ensuring that expenses and revenue are treated as separate values when determining total spending and allocation. This improves the accuracy of project financial reporting.
Original PR description
### Steps to reproduce: - Create a billable project - Create two budgets one expense and the other revenue or both each for 100$ - Create a vendor bill with the analytic account of the created project - Notice in the project dashboard the two budgets are summed up in the total ### Cause: When calculating the total spent and total allocated we add up the amount whether it is an expense or revenue. https://github.com/odoo/enterprise/blob/1dccb87a48ac44735da4c78594e37d4783789cd6/project_account_budget/models/project.py#L120-L121 ### Fix: Set the expense budget to -ve and the revenue/both to +ve amount when calculating the total spent and total allocated opw-5488131 Forward-Port-Of: odoo/enterprise#106504
This update corrects a legal requirement for invoices generated using the l10n_gt_edi module. Previously, certain document types (FCAM, FCAP, FESP) lacked essential 'complementos' attachments in the PDF invoice, while they were present in the XML. This fix ensures compliance and proper invoice formatting.
Original PR description
**PROBLEM** For some documents types, the "complementos" are not present in the pdf while they are present in the xml. It's legally required that they are added in the pdf. **STEP TO REPRODUCE** 1. Install l10n_gt_edi. 2. Create an customer invoice. 3. Set the document type to FCAM, FCAP, or FESP. 4. Send the invoice using the cfdi. 5. download the xml and the pdf, notice the complementos are in the xml, but not in the pdf. opw-5970285 Forward-Port-Of: odoo/enterprise#109061
This update resolves an issue where ISO20022 XML files generated for Swiss companies were being incorrectly formatted, leading to bank rejections. The fix ensures the correct 'PAIN 09' version is used, aligning with bank requirements after upgrading to version 18.2. This prevents delays in payment processing for our Swiss clients.
Original PR description
To reproduce the issue:
- Create a database in 17.0, with a Swiss company, and install account_sepa. Make sure the bank journal uses the Swiss IS020022 PAIN version.
- Migrate this database to 18.0
- Generate an ISO20022 xml file for the Swiss company
==> The file is wrongly formatted, and will be rejected by the bank.
This happens because the sepa_pain_version field of the journal is still set to its old selection value ('pain.001.001.03.ch.02') after migration, which is not supported anymore. The ORM hence returns an empty value when accessing the selection field, and does not enter the proper conditions when generating the file.
An upgrade fix has been made here https://github.com/odoo/upgrade/pull/9771. This commit makes sure already-migrated databases dynamically fix the issue as well.
opw-6060612
Forward-Port-Of: odoo/enterprise#111949This update fixes an error preventing Point of Sale sessions from closing correctly in version 18.2. The issue stemmed from an incorrect method name in the 'l10n_de_pos_cert' module, which was preventing the correct cash move formatting. Renaming the method ensures proper session closure and accurate cash transaction recording.
Original PR description
**Steps to Reproduce:** 1. Start a new Point of Sale session from the Odoo backend. 2. Create and validate a POS order to ensure the session contains at least one transaction. 3. In the POS…
**Steps to Reproduce:** 1. Start a new Point of Sale session from the Odoo backend. 2. Create and validate a POS order to ensure the session contains at least one transaction. 3. In the POS interface, open the menu (☰ icon) in the top-right corner. 4. Navigate to the Cash In/Out functionality. 5. Perform a cash operation: - Select either Cash In or Cash Out - Choose a Category Reason - Select a Type Reason - Confirm the operation 6. Attempt to close the POS session. **Issue:** In version saas-18.2, an error occurs when closing the POS session because the name of the cash move (in the Cash Register) is incorrect. It should be formatted as: `Hauptmarkt/00006-out-category reason-reason` However, it is currently generated as: `Hauptmarkt/00006-out-reason` This happens because the method `"_prepare_try_cash_in_out_payload"` in "l10n_de_pos_cert" is not called due to an incorrect method name. **Solution:** The issue is resolved by renaming the method to the correct name `"_prepareTryCashInOutPayload"`. This ensures the proper method is invoked, generates the correct cash move name, and allows the POS session to close successfully. opw-6059143
17 changes
Enhancements to existing features
This update automatically updates the DGI (Uruguayan tax authority) state for stock pickings, ensuring compliance with local regulations. When a picking is rejected by the DGI, the system now logs the issue and notifies users for manual review, improving accuracy and reducing manual effort.
Original PR description
This pull request introduces an automated process to periodically update the DGI (Dirección General Impositiva) state for Uruguayan electronic stock pickings, along with improvements to error…
This pull request introduces an automated process to periodically update the DGI (Dirección General Impositiva) state for Uruguayan electronic stock pickings, along with improvements to error handling and logging when a picking is rejected. The main changes are the addition of a scheduled cron job, enhanced logging, and user notifications for rejected pickings. **Automated DGI State Updates:** * Added a new scheduled cron job (`ir_cron_update_dgi_state_pickings`) that runs every 10 minutes to update the DGI state of stock pickings with electronic documents in the "received" state. (`l10n_uy_edi_stock/data/ir_cron.xml`, `l10n_uy_edi_stock/__manifest__.py`) [[1]](diffhunk://#diff-36f19bab7c2edeb0f43a1db1639b72e8508deed19652e0b1142ebfce688b9d3eR1-R11) [[2]](diffhunk://#diff-370a6cfd5890d6504958deb4a225d69ec84e84fa59deeeb52c96a849f3fdfc22R14) * Implemented the `_l10n_uy_edi_stock_cron_update_dgi_state` method in `stock_picking.py` to process batches of pickings and trigger itself again if more records remain. (`l10n_uy_edi_stock/models/stock_picking.py`) **Error Handling and Notifications:** * Enhanced the `l10n_uy_edi_action_update_dgi_state` method to log rejected pickings and post a message in the chatter to notify users when a picking has been rejected by DGI, prompting manual review and correction. (`l10n_uy_edi_stock/models/stock_picking.py`) * Introduced logging setup for the module to support the new logging functionality. (`l10n_uy_edi_stock/models/stock_picking.py`) [[1]](diffhunk://#diff-108d31170c95f307accd45410f9a98bd16ce0413932fab4732eb764d75d3e260R2) [[2]](diffhunk://#diff-108d31170c95f307accd45410f9a98bd16ce0413932fab4732eb764d75d3e260R14)
Resolved issues and error corrections
This update fixes an issue where fields weren't being created correctly when new records were being generated. The change ensures that all fields are properly populated during the creation process, leading to more reliable data and reduced errors. This primarily impacts the creation of new records within various Odoo modules.
Original PR description
See https://github.com/odoo/odoo/pull/199647. Forward-Port-Of: odoo/enterprise#109725
This update fixes a bug that prevented users from successfully updating timesheet entries while a timer was running. The issue stemmed from an error when the system attempted to process updates after a 'My Timesheet' navigation. The fix adds a simple check to ensure the timer state is valid before attempting updates, improving timesheet functionality.
Original PR description
Steps to reproduce: 1. Install `timesheet_grid` 2. Open timesheet and start timer 3. Update any cell by clicking on seach icon. 4. Now after updating go back by clicking "My Timesheet" breadcrumb Issue: - Tracback: `Uncaught Promise > Cannot convert undefined or null to object` Cause: : - The error was occurring because the updateTimerState function in timesheet_timer_service.js was trying to iterate over timerState.data when it was undefined or null. This happens when the list view's urgent save is triggered. Solution: - added a safeguard to updateTimerState so that it simply returns early if timerState.data is empty opw-6018970
This update resolves a technical error that prevented users from printing VSME and CSRD ESG reports. The issue stemmed from an outdated search filter in the report generation process. By removing a redundant check, the report now functions correctly, ensuring accurate data reporting.
Original PR description
Steps to reproduce:
1. From Accounting, create a Vendor bill with today's date, and containing a line
2. Confirm (post) it
3. Make the Payment ('Pay' stat button)
4. Create a VSME or CSRD report from the ESG App, for the current year
5. Try to print it
=> A traceback occurs (in _get_payment_terms_data()) as we are trying to search on the 'active' field of account.move, which does not exist. => Solution: remove this uneeded check
version-19.0This update fixes an issue where expense refusal messages in the Odoo chatter were displayed in the employee's language instead of the user's. It also prevents OCR from overwriting data from Stripe expense payments, ensuring accurate data capture. This improves the user experience and data integrity for expense reporting.
Original PR description
Problem: For expense created from stripe payment, OCR overwrites the data fetched from stripe. Solution: Skip OCR for expense created from stripe payment and put a log note explaining the same. ***…
Problem: For expense created from stripe payment, OCR overwrites the data fetched from stripe. Solution: Skip OCR for expense created from stripe payment and put a log note explaining the same. *** Purpose: One language may have been set on employee, but that employee may be using any other language in his environment, in that case user should see chatter messages in language from his environment. Before this commit: expense refusal message in chatter used employee's language. After this commit: expense refusal message in chatter uses language of user related to employee. *** Problem: Expense Digitalization (OCR) setting is not properly applied. Steps to reproduce:- - Create a new database with demo data and install `hr_expense_extract`. - Switch to `My US Company` and create an employee for that company. - In expense settings set Expense Digitalization (OCR) to Digitize on demand only. - Create an expense for above created employee and attach receipt. - Expense is digitized automatically. Cause: Here https://github.com/odoo/enterprise/blob/d8acbf22fec266ff7d5dcc9499543e6bea3c1325/hr_expense_extract/models/hr_expense.py#L43 `self.env.company` gives that user's default company instead of currently active company in company selector. Solution: Use `company_id` set on expense to determine Expense Digitalization setting. *** task-5712223
This update resolves an issue where equity transactions couldn't be created in currencies other than the company's default (USD). Now, users can set the equity currency for the first transaction, ensuring flexibility in recording equity values. Subsequent transactions automatically use this selected currency.
Original PR description
### Issue: When a company is set in USD, it was not possible to create equity transactions in another currency (e.g., EUR) ### Cause: The equity_currency_id is initialized with the company currency at partner creation (or module installation) However, there was no way to override this value when creating transactions ### Fix: It is now possible to set the equity currency on the first transaction Subsequent transactions reuse this currency and the field becomes read-only ### Steps to reproduce: - Install `equity` with demo data (currency and equity_currency default to USD) - Enable the EUR currency - Create an equity transaction for a company - You can now choose EUR on this transaction - Create another transaction for the same company, the selector is hidden and the currency remains EUR opw-5382255
This update corrects an issue preventing Romanian SAFT reports from passing validation. The team restored a key data element and used the correct, sanitized bank account number, ensuring compliance with Romanian tax regulations. This resolves a technical problem impacting report accuracy and usability.
Original PR description
Problem --------- In odoo/odoo#184131 and odoo/enterprise#72206, UOM's categories where removed. Along side the removal, the Description tag in the Romanian SAFT UOM table tag. However, without this node, the SAFT is flagged as invalid by validator in Romanian. Furthermore, in the RO SAF-T, we use the bank account number and not the sanitized one, which may lead to some spaces in the document. Spaces that are not accepted either. Solution --------- Add back the Description node and use the UOM name instead of category. Use the sanitized account number. opw-5956277 Forward-Port-Of: odoo/enterprise#111664
This update addresses a privacy concern by removing the display of total due amounts for minimal cashiers in the partner list. This change prevents potential leakage of sensitive financial information to cashiers, enhancing security and compliance. The fix was driven by a need to protect cashier data.
Original PR description
Before this commit, the total due amount was visible for minimal cashier in the partner list. This could leak sensitive information to the cashier, which is not desirable. opw-6039529
A recent update to Odoo Enterprise prevented newly created approval rules in the Studio module from being correctly saved to the database. This issue arose during an upgrade from version 18.0 to 19.0 and resulted in these rules being unexpectedly deleted. This fix ensures that updates to Studio approval rules are properly recorded, preventing data loss and maintaining the integrity of user permissions.
Original PR description
Server and automated actions created by the ORM for the purpose of revoking approval rights are created without `noupdate=True` which leads to said records being removed by the ORM becuase of not being found in the source. Such records created on the fly should have `noupdate=True` to prevent that from happening. This bug can be reproduced by going to Settings > Technical > User Interface > Studio Approval Rules and creating a new record from there and updating `web_studio`. The update will drop the record from the database. Issue originally detected in the upgrade process from 18.0 to 19.0. This fix will be complemented by an upgrade script that fixes erronous records. Forward-Port-Of: odoo/enterprise#110065
This update fixes a minor issue within the Web Studio interface where many search dialogs lacked clear titles. Now, most 'selectCreateDialog' instances display meaningful titles, improving usability and clarity for users creating and editing web applications. This ensures a more intuitive experience when working with the design tools.
Original PR description
Before this commit, a lot of search More dialogs did not have a meaningful title because one parameter was usually not set. After this, most or all the selectCreateDialog have a meaningful title task-5932652
This update fixes an issue where project budget totals were incorrectly summing expense and revenue budgets. The fix ensures that expenses are treated as negative values and revenues as positive values during total calculations, accurately reflecting the project's financial status. This improves the reliability of project reporting.
Original PR description
### Steps to reproduce: - Create a billable project - Create two budgets one expense and the other revenue or both each for 100$ - Create a vendor bill with the analytic account of the created project - Notice in the project dashboard the two budgets are summed up in the total ### Cause: When calculating the total spent and total allocated we add up the amount whether it is an expense or revenue. https://github.com/odoo/enterprise/blob/1dccb87a48ac44735da4c78594e37d4783789cd6/project_account_budget/models/project.py#L120-L121 ### Fix: Set the expense budget to -ve and the revenue/both to +ve amount when calculating the total spent and total allocated opw-5488131 Forward-Port-Of: odoo/enterprise#106504
This update ensures that document creation times are displayed accurately for users, regardless of their location. Previously, times were inconsistent due to a failure to convert dates from UTC to the user's local timezone. This fix provides a more reliable and user-friendly experience for managing document versions.
Original PR description
Step to reproduce: 1. Install `documents` 2. Upload a document and open the tree view 3. Compare the field `Created On` and the time from the `Manage Versions` action Issue: - The displayed time is inconsistent between the tree view and the dialog Cause: - The datetime used in Manage Versions is formatted without converting it from UTC to the user’s timezone Solution: - Use timezone-aware datetime helpers so values are converted from UTC to the user’s timezone. Before: <img width="1328" height="81" alt="image" src="https://github.com/user-attachments/assets/2a02f03c-714d-417d-a805-fd0dd7c52753" /> <img width="636" height="297" alt="image" src="https://github.com/user-attachments/assets/c4514469-2f51-493f-8991-32371fb7f338" /> After: <img width="641" height="312" alt="image" src="https://github.com/user-attachments/assets/3979ece8-635a-4b54-9b53-d8b28b3336ec" /> opw-5467782 Forward-Port-Of: odoo/enterprise#104443
This update corrects a legal requirement for GT EDI invoices. Previously, certain document types (FCAM, FCAP, FESP) lacked essential 'complementos' attachments in the PDF invoice, while these attachments were present in the XML. This fix ensures all invoices generated through l10n_gt_edi comply with legal standards.
Original PR description
**PROBLEM** For some documents types, the "complementos" are not present in the pdf while they are present in the xml. It's legally required that they are added in the pdf. **STEP TO REPRODUCE** 1. Install l10n_gt_edi. 2. Create an customer invoice. 3. Set the document type to FCAM, FCAP, or FESP. 4. Send the invoice using the cfdi. 5. download the xml and the pdf, notice the complementos are in the xml, but not in the pdf. opw-5970285 Forward-Port-Of: odoo/enterprise#109061
This update resolves an issue where invoices for foreign customers (e.g., from Colombia) generated by Peruvian companies resulted in errors from SUNAT due to missing identification type information. The change automatically sets a default 'schemeID' of '0' for these invoices, ensuring valid UBL/QR generation and compliance.
Original PR description
In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an…
In multi-country databases, a Peruvian company can invoice a foreign customer (e.g., a Colombian company) whose identification type is defined by another localization. Those records typically have an empty l10n_pe_vat_code, since there are no cross-country dependencies between LATAM identification types. In that case, the generated UBL leaves the receiver identity type empty and SUNAT returns an error like: ``` 2015/2015 - El XML no contiene el tag o no existe informacion del tipo de documento de identidad del receptor... (missing schemeID value). ``` Odoo already defines schemeID = 0 for some foreign identification types in l10n_pe data, but it cannot cover identification types coming from other countries’ localizations (e.g. Colombia): https://github.com/odoo/odoo/blob/18.0/addons/l10n_pe/data/l10n_latam_identification_type_data.xml#L4 This change ensures that, when the partner is not from Peru and the PE VAT code is missing, we fallback the receiver identification type to "0" in: - PartyIdentification/ID/@schemeID - AccountingCustomerParty/AdditionalAccountID - the QR payload identification type field This prevents generating invalid UBL/QR content for foreign customers in multi-country setups. Forward-Port-Of: odoo/enterprise#110324 Forward-Port-Of: odoo/enterprise#105115
This update prevents the entire reports cron job from stopping if an error occurs during report generation. Previously, a single error would halt the entire process. Now, the cron will continue to attempt sending other reports, improving reliability and ensuring all reports are eventually processed.
Original PR description
If an error is raised during the export of reports cron execution, the whole cron stops due to the fact that the error is never catched This commit will ensure that even if there is an error with one of the report export, the cron won't top and will try to send to other documents task-5469038 Forward-Port-Of: odoo/enterprise#111602 Forward-Port-Of: odoo/enterprise#105191
This update resolves a bug preventing users from adding reactions to messages within the Discuss module when those messages are associated with the mail_group model. The fix ensures the 'add reaction' button isn't displayed for message types that don't inherit from the standard mail.thread model, improving stability and usability.
Original PR description
Steps to reproduce: - Install the mail_group module - Open Discuss - Go to the History tab - Add a reaction on a message that has model mail.group - Throws an error The error occurs because the mail.group model does not implement the `_get_allowed_access_params()` method, which is invoked during the process here. Actually, the "add reaction" button should not be shown on messages whose model does not inherit from mail.thread. This commit fixes the issue by hiding the "add reaction" button on messages with models that don’t inherit from mail.thread, such as `mail.group`. community: https://github.com/odoo/odoo/pull/218615 Task-5098050 Forward-Port-Of: odoo/enterprise#111830 Forward-Port-Of: odoo/enterprise#111271
This update corrects an issue where ISO20022 XML files generated for Swiss bank accounts were being rejected due to outdated formatting. The fix ensures the correct 'PAIN 09' version is used, resolving compatibility problems and preventing failed file submissions. This improves the reliability of financial data exchange.
Original PR description
To reproduce the issue:
- Create a database in 17.0, with a Swiss company, and install account_sepa. Make sure the bank journal uses the Swiss IS020022 PAIN version.
- Migrate this database to 18.0
- Generate an ISO20022 xml file for the Swiss company
==> The file is wrongly formatted, and will be rejected by the bank.
This happens because the sepa_pain_version field of the journal is still set to its old selection value ('pain.001.001.03.ch.02') after migration, which is not supported anymore. The ORM hence returns an empty value when accessing the selection field, and does not enter the proper conditions when generating the file.
An upgrade fix has been made here https://github.com/odoo/upgrade/pull/9771. This commit makes sure already-migrated databases dynamically fix the issue as well.
opw-6060612
Forward-Port-Of: odoo/enterprise#1119498 changes
Resolved issues and error corrections
This update fixes an issue where duplicating a product template in Odoo would automatically publish the duplicate, even if the original wasn't. The change ensures that duplicated product templates remain unpublished by default, aligning with expected behavior and preventing unintended product listings. This improves data consistency and reduces potential errors.
Original PR description
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a…
Issue: --- Duplicate product template creates a published product which is not expected. Duplicated products should be unpublished by default. #### Steps to reproduce: 1- Create a product and add a eCommerce category. 2- Without publishing the product duplicate it. Even though the original product is not published, the duplicated one is published. Expected: Regardless of published state of original product, the duplicated product should not be published. Cause: --- This regression is introduced in https://github.com/odoo/enterprise/pull/66218 to create a `is_published` product if `public_categ_ids` is set. However this was only supposed to be when creating a new product using form. It makes the create to ignore `is_published` default value even in copy. Fix: --- We can make sure if `is_published` is in create vals, don't force `is_published` to be set True. However, as `copy=False` in `is_published` field definition, it won't be in vals in copy. By overriding `copy_data`, we can ensure vals is present in copy. #### Note: `product_barcodelookup` doesn't depend on `website_sale`. However, `product_categ_ids` is used in this module. In the test for the same case we only run the test if the module is installed. This would be fine as this is a post-install test. opw-6014789
This update corrects a problem where ISO20022 XML files generated for Swiss bank accounts in version 18.0 were being rejected by banks. The fix ensures the correct 'PAIN 09' format is used, resolving compatibility issues after database migration. This prevents delays in financial transactions.
Original PR description
To reproduce the issue:
- Create a database in 17.0, with a Swiss company, and install account_sepa. Make sure the bank journal uses the Swiss IS020022 PAIN version.
- Migrate this database to 18.0
- Generate an ISO20022 xml file for the Swiss company
==> The file is wrongly formatted, and will be rejected by the bank.
This happens because the sepa_pain_version field of the journal is still set to its old selection value ('pain.001.001.03.ch.02') after migration, which is not supported anymore. The ORM hence returns an empty value when accessing the selection field, and does not enter the proper conditions when generating the file.
An upgrade fix has been made here https://github.com/odoo/upgrade/pull/9771. This commit makes sure already-migrated databases dynamically fix the issue as well.
opw-6060612This update fixes an issue where quality control moves weren't correctly splitting stock when partial failures occurred. Specifically, the demand quantity was calculated incorrectly, leading to an inaccurate split of the affected stock. This ensures accurate stock management and reporting during quality control processes.
Original PR description
**Steps to reproduce:** * Install the `quality_control` module. * Create a storable product. * Configure a Quality Control Point: * Set Control per : Quantity. * Set Operation Type to Receipts. * Set…
**Steps to reproduce:** * Install the `quality_control` module. * Create a storable product. * Configure a Quality Control Point: * Set Control per : Quantity. * Set Operation Type to Receipts. * Set Product to the created product. * Create a Receipt for the product with a demand of 5 units. * Confirm the receipt and mark it as To Do. * Click on the Quality Check button. * Click on Fail and set the failed quantity to 3. * Click on Confirm. **Observed behavior:** * A new stock move is created for the failed quantity. * The original move is split incorrectly: * First move: 2 `product_uom_qty` and 2 `quantity`. * Second move: 2 `product_uom_qty` and 3 `quantity`. * The failed move has a demand of **2** instead of **3**. **Cause:** * Clicking on *Quality Check* triggers `check_quality`, which opens the wizard `action_open_quality_check_wizard`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/stock_picking.py#L79-L82 * Clicking on *Fail* triggers `do_fail`, opening the confirmation wizard: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L85-L88 * Clicking on *Confirm* triggers `confirm_fail`, which calls `_move_line_to_failure_location`: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/wizard/quality_check_wizard.py#L97 * In `_move_line_to_failure_location`, a new stock move is created for the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L480 * The demand quantity is computed using the minimum of the failed quantity and the move line quantity. * This leads to an incorrect demand of *2* instead of *3*. * However, the move line quantity was already reduced by the failed quantity: https://github.com/odoo/enterprise/blob/90567af2703a3928c35814a0c4862b4cd98b8432/quality_control/models/quality.py#L472 **Fix:** * Ensure that partial failures properly split stock moves with correct `product_uom_qty` and `quantity` values. --- opw-5492095
This update fixes an issue where the barcode scanner was incorrectly using the user's company instead of the current business context. This resulted in incorrect barcode recognition, preventing users from scanning products correctly. The fix ensures the scanner utilizes the appropriate company information for accurate barcode processing.
Original PR description
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong…
### Issue: The company used in the main barcode menu is the `company_id` of the user rather than the current contextual company of the session. This is problematic as we might endup using the wrong barcode nomenclature. ### Steps to reproduce: - Have 2 companies: company 1 and company 2 - Set the barcode nomenclature of company 1: default, company 2: GS1 - Incarnate a user allowed in both companies but with default company 1 - With company 2, create a product and set its barcode to 36939282410106 - From the main menu open the barcode app and scan 0136939282410106 #### > No product was found (even thought it is correct in GS1) ### Cause of the issue: Scanning from the main barcode menu will trigger a call of the `main_menu` method relying on the nomenclature of the contextual company of the request: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/static/src/main_menu/main_menu.js#L98-L99 https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/controllers/stock_barcode.py#L15-L21 However, when opening the main barcode menu from the app menu, no contextual warehouse was set to the view: https://github.com/odoo/enterprise/blob/804ea21c225a7a1e0763bac188f027adeb3ab78f/stock_barcode/views/stock_barcode_views.xml#L6-L11 As such, the environment of the request will be set here: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/http.py#L2083 based on the company of the user rather than the one of the context: https://github.com/odoo/odoo/blob/9393b0db6791fe5a7f576cff55705e315fb3dd11/odoo/api.py#L694-L722 ### Fix: Setting the company slices the `current_company` in first position of the `allowed_company_ids`: https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L33-L39 https://github.com/odoo/odoo/blob/260c69ed64f8663b6935b9863c86aac6dbecd961/addons/web/static/src/webclient/switch_company_menu/switch_company_menu.js#L68-L81 which can be recovered from the cookies via the `_get_allowed_company_ids`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L432-L442 precisely used by the `_get_barcode_nomenclature`: https://github.com/odoo/enterprise/blob/43f65ff2f3c6177cc69647bbb85bb40a84409457/stock_barcode/controllers/stock_barcode.py#L485-L491 Note that passing the context in the arguments of the `main_menu` JSON route will not really solve the issue by it self since the context is no longer shared with the request: c8cd1d4a83de7a5798cbb910a788fbb6fe208d2f ### Additional Issue: The type `dest_location` does not exist on barcode types: https://github.com/odoo/odoo/blob/485a64b6a1e91feb4310f282c6dd1cd021f1780b/addons/barcodes_gs1_nomenclature/models/barcode_rule.py#L16-L20 so that the type used by these lines can not work: https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L29-L30 https://github.com/odoo/enterprise/blob/1dedc5bbcee43bfd13e55206e3d7364f715ca9be/stock_barcode/controllers/stock_barcode.py#L52-L56 ### Steps to reproduce: - In the settings enable: Multi-Steps Routes - Set the barcode nomenclature to GS1 - Set your warehouse in receipt in two steps and add a barcode to the WH/Input: 3033710074365 - From the main menu open the barcode app and scan 4133033710074365 #### > No product or picking was found (even thought it is correct in GS1 that should create an internal transfer with WH/INPUT as destination) opw-5847529
This update resolves an issue where the POS scale integration was not accurately displaying product weights due to a change in how the IoT box sends scale data. The fix ensures that the POS correctly reads and displays weight measurements from the physical scale, improving the accuracy of product tracking. This update is critical for accurate inventory management within the POS system.
Original PR description
Steps to reproduce - Use a localisation other than a european one (l10n_eu_iot_scale_cert must not be installed) - Setup the scale for the POS - Open the POS - Add a product to be weighted by scale to the order - Add product to the physical scale - The displayed weight is always 0 Cause: New versions of the IoT box uses the field result to return the scale measure instead of value. Fix for version 18.0 and its intermediary versions. [opw-5990467](https://www.odoo.com/odoo/project/49/tasks/5990467)
This update resolves an issue where discounts weren't correctly processed in the self-order point-of-sale flow. The fix ensures that discount information is properly handled, preventing errors and guaranteeing accurate pricing calculations during self-order transactions. This improves the reliability of the self-order experience.
Original PR description
In the pos self-order flow, `_check_pos_order_lines` does not forward the `discount` field when sanitizing order lines. This caused `_merge_order_lines` to raise a `KeyError` when using `itemgetter('discount')` on lines that lack the key.
opw-6052719This update fixes an issue where global invoices generated from customer invoices weren't correctly using the issued address's zip code in the XML export. The change ensures that the correct postal code is included, improving compliance with Mexican tax regulations. This resolves a reported problem (opw-5956837) related to invoice data accuracy.
Original PR description
**STEP TO REPRODUCE** 1. install l10n_mx_edi_extended. 2. Add an issued address on the customer invoice journal, with a zip code. 3. Create invoices, and create a global invoice with them. 4. download the xml, and notice the field LugarExpedicion is not using the zip from the issued address while it should. opw-5956837
This update fixes an issue where the external value pop-up consistently used a dot as the decimal separator, regardless of the user's language settings. Now, the pop-up will display the decimal separator appropriate for the user's locale, ensuring accurate reporting and a better user experience across different languages.
Original PR description
Description of the issue this commit addresses: The external value pop up doesn't take into account the locale to chose which decimal separator to use. --- Desired behavior after this commit is merged: The decimal separator is the one determined by the language of the user rather than always a dot. --- task-6010533 Forward-Port-Of: odoo/enterprise#109948
4 changes
Resolved issues and error corrections
This update corrects a previous issue where partner totals were incorrectly hidden, regardless of their value. Now, the report accurately displays all partners with totals exceeding €3,005.06, and it properly accounts for sales and purchase journal amounts for insurance operations, ensuring more accurate tax reporting in Spain.
Original PR description
Before this PR: - Partners were only shown if their total was positive and above 3,005.06 €. Negative totals were hidden, even if they were lower than -3,005.06 €. - Insurance operations only took Purchase journal amounts into account. Amounts from Sales journals were ignored, and there was no distinction between the two types of operations. After this PR: - The report now uses the absolute value of the total. Partners with amounts exceeding 3,005.06 €, whether positive or negative, are now shown correctly. - Insurance operations are now divided into two distinct sections: Sales and Purchases. Amounts from both Sales and Purchase journals are now correctly taken into account and reported in their respective sections. task-5214023
This update resolves an issue causing instability in the stable release of Odoo. The change reverts a previous update that was incorrectly using invoice names instead of the correct tax invoice labels in test reports. This ensures accurate reporting and stability for our users.
Original PR description
This reverts commit 8bd288516ce84a2c491dd19bc4527c8ce40a903e as it causes some unexpected behaviour in stable. We'll instead do it in master
This update resolves an issue preventing SBR tax reports from being submitted due to incorrect date formatting and overly long consultant descriptions. The commit restores the original date format and simplifies the consultant name to ensure compliance with validation requirements, allowing reports to pass successfully.
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#111817
This update resolves an issue where only certain users could delete work entry types within the payroll module. The change now allows SUPERUSER administrators to delete these entry types, streamlining payroll management and reducing administrative overhead. This ensures consistent access for critical operational tasks.