Daily updates from Odoo
Navigate
Branch
Thursday, March 26, 2026
257 changes
14 changes
Enhancements to existing features
This update allows administrators to efficiently manage database tags by enabling mass editing. Previously, tagging databases required individual updates for each one. This change streamlines the process, saving time and improving database organization.
Original PR description
The aim of this commit is to allow users to mass edit the list of database to add one or several tag on several dbs at once. task-id: 6046088 Forward-Port-Of: odoo/enterprise#112024
Resolved issues and error corrections
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 fields weren't being populated correctly when new fields were created within Odoo. The change ensures that all fields are properly initialized during the creation process, improving data accuracy and reliability. This resolves a technical bug impacting data integrity.
Original PR description
See https://github.com/odoo/odoo/pull/199647. Forward-Port-Of: odoo/enterprise#111898 Forward-Port-Of: odoo/enterprise#109725
This update fixes a misunderstanding regarding the date field used to record when a W4 form is filed with an employer. The change ensures the system accurately reflects the filing date, which is crucial for proper payroll processing and compliance with US tax regulations. This resolves an issue where the date was incorrectly interpreted.
Original PR description
This field is about when the W4 is filed with the employer, not when it's filled in. opw-5096780 Forward-Port-Of: odoo/enterprise#111679 Forward-Port-Of: odoo/enterprise#111213
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, addressing a compatibility problem caused by outdated migration settings. This update guarantees proper file formatting for seamless bank 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-6060612
Forward-Port-Of: odoo/enterprise#111949This update ensures that expense refusal messages displayed in the system's chatter are now shown in the user's preferred language, rather than the employee's. This improves communication clarity and a better user experience. The change addresses an issue where the system incorrectly defaulted to the employee's language.
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 Forward-Port-Of: odoo/enterprise#106261
This update resolves errors preventing users from downloading Annual Statements and exporting audit working files as PDFs. The issue stemmed from changes in how report data is structured, requiring adjustments to the PDF template to correctly access data values.
Original PR description
**Issue-1:** Currently, an error occurs when downloading the Annual Statements report as PDF. **Steps to reproduce:** - Install the `l10n_be` and `accountant` modules. - Navigate to Accounting >…
**Issue-1:** Currently, an error occurs when downloading the Annual Statements report as PDF. **Steps to reproduce:** - Install the `l10n_be` and `accountant` modules. - Navigate to Accounting > Reporting > Annual Statements. - Click the `PDF` button to download the report. **Error:** `AttributeError: 'AccountReportLineData' object has no attribute 'get'` **Root Cause:** After commit [1], all report lines, columns, and annotations were converted from dictionaries to custom objects (e.g., `AccountReportLineData`). However, the PDF template still uses `.get()` to access values, which is only valid for dictionaries. Calling `.get()` on these objects raises an error. **Fix:** This commit ensures that the user can download the report without any errors by updating the PDF template to access attributes directly instead of using `.get()`, similar to [2]. **Issue-2:** Currently, an error occurs when exporting audit working files. **Steps to reproduce:** - Install the `l10n_be` and `accountant` modules. - Navigate to Accounting > Review > Audit > Working Files. - Click `New`, set the date, and click `Generate Return`. - Go back to `Audit`, click the dropdown menu (⋮) and click `Export`. **Error:** `AttributeError: 'AccountReportLineData' object has no attribute 'last_comment'` **Root Cause:** After commit [1], report lines were converted from dictionaries to custom objects. However, `last_comment` was not added to `AccountReportLineData` at [3], while it is still accessed during the export process. This results in an error. **Fix:** This commit ensures that the user can export the audit working files without any errors by adding the missing `last_comment` attribute to `AccountReportLineData` [1]: https://github.com/odoo-dev/enterprise/commit/b92dc397bef029472a40223f51b611cdf5b631dc#diff-e97f74c63a6257470e69eb8122c12d0ce4afa5bc6013176bb69e702849575123 [2]: https://github.com/odoo/enterprise/blob/d0dce18797ddc7fa68a882bce19ff1552ceff5b9/account_reports/data/pdf_export_templates.xml#L279-L288 [3]: https://github.com/odoo/enterprise/blob/72f42a09ccd30ec6200ed8a8155f895febb66501/account_reports/utils/report_data_objects.py#L114-L140 opw-6053889 opw-6063978 opw-6070396
This update resolves a visual issue in the Kanban view for work orders, ensuring consistent color representation based on the associated production. The change utilizes a new color field introduced in the system to accurately reflect work order status and improve usability.
This update fixes a minor issue within the Web Studio module where many search dialogs lacked clear titles. Now, most of these 'More Dialogs' have descriptive titles, improving usability and clarity for users creating and editing web applications. This change ensures a better user experience and simplifies the process of finding specific options.
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 Forward-Port-Of: odoo/enterprise#111948
This update fixes a display issue in the CFDI invoice reports for Mexican companies. Previously, payment method 99 was incorrectly showing as 'False' instead of the correct 'Por definir'. This change ensures accurate reporting of payment methods, improving data clarity for financial processes.
Original PR description
**PROBLEM** PR https://github.com/odoo/enterprise/commit/843d57b25f925a5d4f1848b85717adb4d1a9d388 Archives payment method 99, but because it's archived `_l10n_mx_edi_get_extra_invoice_report_values()` doesn't retrieve it. This leads the pdf report to display '99 - False' instead of '99 - Por definir'. **STEP TO REPRODUCE** 1. Create an invoice with the mx company. 2. Set the due date sometime in the month later. (To have the PPD payment policy on the invoice). 3. Send and generate the invoice using cfdi. opw-5927655 Forward-Port-Of: odoo/enterprise#111362 Forward-Port-Of: odoo/enterprise#107267
This update resolves an issue where users could mistakenly create 'Requested Documents' instead of folders when syncing Peppol documents through the accounting settings. To avoid a confusing location (My Drive), the ability to create or edit documents within the settings has been disabled, ensuring correct document synchronization.
Original PR description
Before this commit a user could create or edit a folder in the accounting settings to sync peppol documents to. The issue was that this created a 'Requested Document' instead of a folder. This commit removes the possibility to create or edit documents through the settings. An alternative would have been to add the contex to create a Folder instead of a Requested Document, however another problem then arises: the folder is created in My Drive, which does not make any functional sense. Therefore we are disabling creation and edit. This is the same logic applied in 8ada2a4f. Task-6063736 Forward-Port-Of: odoo/enterprise#111884 Forward-Port-Of: odoo/enterprise#111761
This update prevents the entire reports cron job from stopping if an individual report export fails. Previously, a single error would halt the entire process. Now, the cron will continue to attempt exporting other reports, improving reliability and ensuring all reports are eventually generated.
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#111732 Forward-Port-Of: odoo/enterprise#105191
This update resolves a technical issue preventing users from printing VSME and CSRD ESG reports. The fix removes an unnecessary check in the report generation process that was causing errors. This ensures reports can be successfully generated and printed, improving the functionality of the ESG reporting module.
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 fixes a technical error that prevented the generation of the 281.10 report for Belgian payroll companies. The issue stemmed from a mismatch in data between the payslip and the report generation process. The fix ensures accurate report creation by adjusting how vehicle information is identified.
Original PR description
[FIX] l10n_be_payroll: fix traceback in 281.10 sheets
Bug reproduction: Go to any version>=17.0 -> select belgium company -> install only belgium payroll (don't install fleet one) -> fill in niss, certification level, address, Time in R&D -> generate payslip and confirm it -> try to generate 281.10 report -> traceback
Bug cause:
1 - In traceback it was saying payslip doesn't have vehicle_id, in 281.10 sheet preparation (in function _get_atn_nature), there is a term like that
2 - Payslip doesn't have it because fleet module is not there.
Bug solution:
1 - Instead of checking the payslip has vehicle like that, we calculated it by using paylsip line_ids
2 - If the code ATN.CAR is there and the total of it is not zero, which means this payslip has a vehicle indeed.
task - 6037206
Forward-Port-Of: odoo/enterprise#111680
Forward-Port-Of: odoo/enterprise#11086015 changes
Enhancements to existing features
This update allows users to efficiently add multiple tags to several databases simultaneously. Previously, users had to tag each database individually. This change streamlines the process, saving time and improving database management efficiency.
Original PR description
The aim of this commit is to allow users to mass edit the list of database to add one or several tag on several dbs at once. task-id: 6046088 Forward-Port-Of: odoo/enterprise#112024
This update allows Peruvian Point of Sale (POS) systems to directly print electronic invoices and receipts on thermal printers, aligning with local regulations and business practices. Previously, customers had to download invoices from a portal. This change improves the customer experience by eliminating the need for a separate download.
Original PR description
Before: - In Peru, Point of Sale (POS) systems are allowed to generate E-invoices and E-receipts that comply with SUNAT’s requirements. - In the POS, Odoo prints a ticket that only includes a QR code linking to the customer portal, where the A4 invoice can be downloaded. - However, according to SUNAT and common practice in Peruvian retail environments, the printed POS ticket itself should serve as the legal representation of the electronic document After: - We allow Peruvian POS users to print electronic invoices and receipts directly on thermal printers (58 mm / 80 mm) using the same electronic document flow and data as the accounting module, ensuring full compliance with SUNAT’s representation requirements. Impact: - Improve customer experience by avoiding portal-only invoice download task-5193544 Forward-Port-Of: odoo/enterprise#101876
Resolved issues and error corrections
This update resolves an issue where a field was incorrectly representing the date the W4 form is filed with the employer, rather than the date it's completed. This correction ensures accurate payroll processing for US businesses using the l10n_us_hr_payroll module, aligning with tax regulations.
Original PR description
This field is about when the W4 is filed with the employer, not when it's filled in. opw-5096780 Forward-Port-Of: odoo/enterprise#111679 Forward-Port-Of: odoo/enterprise#111213
This update fixes an issue where expense refusal messages in the system were displayed in the employee's language instead of the user's. It now correctly uses the user's language for these messages, ensuring a better user experience. Additionally, the system now skips OCR processing for expenses created from Stripe payments, preventing data overwrites.
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 Forward-Port-Of: odoo/enterprise#106261
This update fixes a minor issue where many search dialogs within the Web Studio tool lacked clear titles. Now, most of these dialogs display meaningful titles, improving the user experience and making it easier to navigate and understand the available options. This enhancement ensures a more intuitive workflow for users creating and modifying web applications.
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 Forward-Port-Of: odoo/enterprise#111948
This update fixes a reporting issue where the KMD INF report incorrectly included partners with turnover below 1,000 EUR. Now, the report accurately filters partners based on a combined total of invoices and credit notes, ensuring more precise financial reporting. The changes improve data integrity and reporting reliability.
Original PR description
The KMD INF report should only include partners whose total turnover for the period reaches 1,000 EUR. Before this PR: - The report did not check this threshold, so partners below €1,000 were still shown. After this PR: - The threshold is now calculated correctly based on specific rules: - The threshold is calculated separately for invoices and credit notes per partner. - If invoices total base amount >= €1,000 OR credit notes total base amount >= €1,000, both invoices and credit notes are included in the report - The same logic applies to bills and refunds in Part B. task-5373606 Forward-Port-Of: odoo/enterprise#111737 Forward-Port-Of: odoo/enterprise#101333
This update corrects a problem where ISO20022 files generated for Swiss bank accounts were being incorrectly formatted, leading to rejection by the bank. The fix ensures the correct 'PAIN 09' version is used, resolving compatibility issues after database migrations. This prevents delays in payment processing.
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 corrects a minor issue related to how fields are populated when creating new records in Odoo. Specifically, it ensures that the correct model is used during the filling process. This enhancement improves data accuracy and reliability within the system.
Original PR description
See https://github.com/odoo/odoo/pull/199647. Forward-Port-Of: odoo/enterprise#111898 Forward-Port-Of: odoo/enterprise#109725
This update ensures that all attendees of an appointment, including internal users, receive booking notifications regardless of whether the event syncs with Google or Outlook. Previously, notifications were limited, causing organizers and followers to miss important updates. This change improves communication and ensures everyone is informed about appointment details.
Original PR description
In [1] we prevented cancelation emails from being sent when the booking was synced via google or outlook calendar. However this means even followers who would not be notified by the mail provider (not assisting to the meeting) would not be notified. As well as the organizer who is doing to booking/cancelling from the perspective of the mail provider, as the meeting is created from their account. Instead we should keep sending the "appointment booked" template in all cases as it is only followed by internal users to whom it is always relevant. As for cancelation templates, it should stil be sent to internal users. Partners of the meeting however need not be notified and may be unsubscribed if syncing is enabled, as cancellation typically only happens once. task-5152917 [1]: https://github.com/odoo/enterprise/pull/60913 Forward-Port-Of: odoo/enterprise#111856 Forward-Port-Of: odoo/enterprise#96638
This update prevents the entire reports cron job from stopping if an error occurs during a single report export. Previously, a single failure would halt the entire process. Now, the cron will continue to attempt exporting other reports, improving reliability and ensuring timely report generation.
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#111732 Forward-Port-Of: odoo/enterprise#105191
This update addresses a security concern by hiding the total due amount from minimal cashiers when viewing partner lists. This prevents cashiers from inadvertently accessing sensitive financial information, enhancing data protection and privacy. The change was implemented as a bug fix.
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 Forward-Port-Of: odoo/enterprise#111103
This update resolves an issue where users couldn't add reactions to messages within the ‘mail.group’ model in Discuss. 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#111919 Forward-Port-Of: odoo/enterprise#111271
This update fixes a problem preventing users from successfully connecting to their databases. Previously, connection attempts were blocked due to access rights issues. Now, users are correctly redirected to the database website for login or connection.
Original PR description
The aim of this commit is to allow a db_user to be able to connect to a database in which he should be able to connect. Before this commit: Clicking on connect would stumble upon access rights issues on system.parameter and on `database_api_key_to_use`. After this commit: User are correctly redirected on the db website, either already connected or on the login page. task-id: 6046086 Forward-Port-Of: odoo/enterprise#111965
This update resolves an issue in Odoo's Web Studio where invisible fields would lose their visibility settings when toggling the 'Show Invisible Elements' option. The fix ensures that the intended invisible state is consistently maintained, preventing unexpected field visibility changes. This improves the user experience and accuracy of customizations within Web Studio.
Original PR description
Steps to reproduce ================== - Install contacts,web_studio - Login as admin - Go to contacts - Open any record - Open studio - Click on any field - Add the "Role / Portal" group - Toggle the…
Steps to reproduce ================== - Install contacts,web_studio - Login as admin - Go to contacts - Open any record - Open studio - Click on any field - Add the "Role / Portal" group - Toggle the "Show invisible Elements" checkbox - Click on the same field => The field is marked as invisible - Add an invisible condition => The invisible condition is lost (but still applied on the view) Cause of the issue ================== In studio, when fetching the view, the invisible attribute is set to True when the user does not have access to the field (when he is not part of the groups). The goal is to make the field invisible in studio unless the "Show invisible Elements" is toggled. But this causes the actual value of the invisible attribute to be lost. Note that this also applies to the column_invisible attribute. Solution ======== If an invisible/column_invisible attribute is present on the nodes with missing access, we copy the actual value to the `actual_invisible` attribute. We then use that value in the editor, when present. opw-6026971 Forward-Port-Of: odoo/enterprise#111868 Forward-Port-Of: odoo/enterprise#111299
This update resolves an issue where the HR Work Entry Attendance module could only record a single attendance event. Now, multiple attendance records can be created for a single work entry, providing a more accurate and flexible way to track employee time. This improves the system's ability to capture complete attendance data.
9 changes
Resolved issues and error corrections
This update fixes a reporting issue where the KMD INF report incorrectly included partners with low turnover. Now, the report accurately filters partners based on a €1,000 turnover threshold, considering both invoices and credit notes. This ensures more reliable financial reporting.
Original PR description
The KMD INF report should only include partners whose total turnover for the period reaches 1,000 EUR. Before this PR: - The report did not check this threshold, so partners below €1,000 were still shown. After this PR: - The threshold is now calculated correctly based on specific rules: - The threshold is calculated separately for invoices and credit notes per partner. - If invoices total base amount >= €1,000 OR credit notes total base amount >= €1,000, both invoices and credit notes are included in the report - The same logic applies to bills and refunds in Part B. task-5373606 Forward-Port-Of: odoo/enterprise#111737 Forward-Port-Of: odoo/enterprise#101333
This update fixes a potential issue where a user could indirectly change an employee's work email through salary contract updates. Previously, linking an employee to a user allowed for this unintended modification. Now, the system ensures the work_email remains consistent, regardless of whether the employee is linked to a user, improving data integrity.
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#111955 Forward-Port-Of: odoo/enterprise#111243
This update corrects a technical error preventing Point of Sale sessions from closing properly. The fix involves renaming a method within the 'l10n_de_pos_cert' module to ensure correct cash move formatting, resolving a previously reported issue. This ensures seamless POS operation.
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 Forward-Port-Of: odoo/enterprise#111597
This update resolves an issue where saving a report with an empty XML format in the Web Studio tool would generate an error. The fix prevents the system from attempting to process empty XML data, ensuring a smoother user experience. This change improves stability and usability for report creation.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955 Forward-Port-Of: odoo/enterprise#88613
This update ensures that when an employee leaves, any scheduled future appraisals are automatically cancelled and archived. Additionally, the employee is removed from appraisal roles, and their personal goals are archived, streamlining the process and preventing outdated appraisals from being created.
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 Forward-Port-Of: odoo/enterprise#111589
This update fixes an issue where the canteen cost was incorrectly calculated for Belgian employees, even when they had no attendance recorded. The fix ensures that the canteen cost is only applied if the employee has earned money through attendance or working during the payslip period, preventing incorrect charges.
Original PR description
[FIX] l10n_be_payroll: fix canteen cost computation
Bug reproduction: belgium company -> create a new employee -> new contract (payroll wage > 0) -> canteen_cost = 50 -> create payslip -> allocate time off for full month (such that there will be no attendance) -> recompute payslip -> still canteen cost is calculated
Bug cause:
1 - If l10n_be_canteen_cost is > 0 it was computing the canteen cost line for sure
2 - If result_rules['BASIC']['total'] is > 0 then the canteen cost was 50.
Bug solution:
1 - I add worked_days['WORK100'].amount != 0 to the computation condition.
2 - If there is any earned money from attendance or working in that payslip duration, the canteen cost should be deducted completely
3 - If the employee is absent during the payslip, the employee should not pay the canteen cost.
task - 6045406
Forward-Port-Of: odoo/enterprise#110991This update resolves a technical problem causing AI conversations to incorrectly display an 'OOO' banner and engage in self-chat. The fix ensures AI conversations function correctly with agents, maintaining proper routing and preventing unwanted self-interaction. This improves the overall AI app experience for users.
Original PR description
Override AI thread correspondent computation to keep the base behavior but clear the correspondent when it resolves to the current user in ai_composer/ai_chat. This avoids self-chat fallback side effects (like OOO banner) while preserving agent flows that rely on a real non-self correspondent. source of this crash: https://github.com/odoo/enterprise/pull/108217 Forward-Port-Of: odoo/enterprise#111736
This update fixes an issue where duplicating a product template automatically published it, even if the original wasn't. The change ensures that duplicated products remain unpublished by default, aligning with expected behavior and preventing unintended product listings. This improves data consistency and reduces manual intervention.
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 Forward-Port-Of: odoo/enterprise#111340
This update resolves an issue where the POS scale wasn't 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 readings from the physical scale, improving the accuracy of order processing. This primarily affects users utilizing the POS module.
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) Forward-Port-Of: odoo/enterprise#111963
20 changes
Resolved issues and error corrections
This update resolves an issue where tiny overtime hours (like seconds) were causing incorrect rate calculations on US payslip PDFs. The fix directly calculates the rate from hourly wage and multiplier, mirroring a previous solution for Australia, ensuring accurate overtime pay is displayed. This improves the reliability of payroll reporting.
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 instead, inspired by edc4ed3c21b which did the same for Australia. task-6052711 Forward-Port-Of: odoo/enterprise#111540
This update resolves an issue where Field Service Reports generated for multiple tasks sometimes produced duplicate PDF files. The fix ensures that reports are generated correctly, avoiding the creation of redundant files. This improves the reliability of report generation for users.
Original PR description
### Issue: When we try to print the field service report on multiple tasks, some with worksheets, then everything is duplicated in the PDF. ### Steps to reproduce: - Install `industry_fsm` and `sale`…
### Issue: When we try to print the field service report on multiple tasks, some with worksheets, then everything is duplicated in the PDF. ### Steps to reproduce: - Install `industry_fsm` and `sale` - Create two tasks with the same customer - Add timesheet, products and save a worksheet on one of them (the goal is to have titles on two different pages) - In list view select both tasks and click Report > Field Service Report - The downloaded PDF has the report twice ### Cause: When printing for several records then `_render_qweb_pdf_prepare_streams()` tries to split the document. If the document has more pages than the number of records [we fetch the "Outlines"](https://github.com/odoo/odoo/blob/55a58571fbfa6a6bb0edacd6f9676382cc23630b/odoo/addons/base/models/ir_actions_report.py#L938-L954). These are the biggest sections in the document. In our case these sections are the `<h2>` tags, as there are no `<h1>`: [the main title](https://github.com/odoo/enterprise/blob/6c4b88a1dfe245a63a424e3f51ff803e51ccde61/industry_fsm/report/worksheet_custom_report_templates.xml#L31-L33), [the Timesheet section title](https://github.com/odoo/enterprise/blob/6c4b88a1dfe245a63a424e3f51ff803e51ccde61/industry_fsm/report/worksheet_custom_report_templates.xml#L39), etc. Then we check the pages where these titles are displayed; if we get the same number of pages as the number of records, we use them to split the report. If not, then we [render the report for each record individually](https://github.com/odoo/odoo/blob/55a58571fbfa6a6bb0edacd6f9676382cc23630b/odoo/addons/base/models/ir_actions_report.py#L974-L976), add them to `collected_streams`. Then add the initial report generated on the recordset and return. These streams are later merged into one, which explains the duplication: - Task 1 report individually generated - Task 2 report individually generated - Report of the recordset containing the two first reports ### Solution: The issue was introduced by [this commit](https://github.com/odoo/odoo/commit/7fc1ebd4466a2d9b4a48dfe86332b5844026c4fc) which implements the individual generation without returning. So the individual documents will always be followed by the recordset document. This commit adds the return directly after the individual reports generation. opw-6032935 Forward-Port-Of: odoo/odoo#255581
This update resolves a technical issue impacting the export functionality of Web Studio. Previously, exported properties were incorrectly formatted, now they are correctly converted to XML records, ensuring accurate data exports for reporting and other uses. This improves the reliability of Web Studio's export capabilities.
Original PR description
Since this commit*, properties are exported as an orm field object, while this method is meant to export the fields into xml records. This commit fixes this by converting the value before exporting it (using hidden _values). *https://github.com/odoo/odoo/commit/6f5e7aa783b336941f95c66ae70cb4ee160c00f4
This update corrects a technical error that prevented Point of Sale sessions from closing properly in the German localization (l10n_de_pos_cert). The fix involves renaming a method to ensure correct cash move formatting, resolving a problem that impacted POS functionality. This ensures seamless POS operations for our German-speaking users.
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 Forward-Port-Of: odoo/enterprise#111597
This update ensures that the 'mail.catchall.domain.allowed' system parameter is properly sanitized when created through the Odoo UI. Previously, a formatting issue caused incorrect domain comparisons, potentially preventing email notifications from being delivered. This fix resolves this issue, guaranteeing accurate domain validation and reliable email functionality.
Original PR description
Since its introduction (https://github.com/odoo/odoo/pull/76734), the "mail.catchall.domain.allowed" system parameter is normally sanitized by `_sanitize_allowed_domains` when using `set_param`. But…
Since its introduction (https://github.com/odoo/odoo/pull/76734), the "mail.catchall.domain.allowed" system parameter is normally sanitized by `_sanitize_allowed_domains` when using `set_param`. But the method is not run when the system parameter is created manually, for example through the UI, because the current conditional logic is not triggered for write and create call. This can be an issue if for example the use submits this value: "domain1.com, domain2.com,domain3.com" The comma seperated list will only be split by ',', meaning that the second element is " domain2.com" (space character in front). As such, that domain will not be used as expected, since most flows using that data will end up comparing "domain2.com" vs " domain2.com", and not considering it a match. Before this fix: Create new record in System parameters with key = "mail.catchall.domain.allowed" value = "domain1.com, domain2.com,domain3.com" -> after save, value == "domain1.com, domain2.com,domain3.com" After this fix: -> after save, value == "domain1.com,domain2.com,domain3.com" OPW-5505414 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#244279
This update allows invoicing users to check the Nilvera status of their partners, a key step in the invoicing process. Previously, this check was failing due to access restrictions. Granting access to the `account.group_account_invoice` group now resolves this issue without requiring administrator intervention.
Original PR description
Invoicing users need to verify partner Nilvera status as part of the regular invoicing workflow, but the check was failing due to missing access rights on `l10n_tr.nilvera.alias` (create/unlink operations). Granted access to `account.group_account_invoice` to allow the check without requiring admin intervention. task-6044307 Forward-Port-Of: odoo/odoo#254609
This update ensures Odoo correctly processes invoices following the PEPPOL BIS3 standard (SE-R-005). Previously, this rule was missing, and this fix adds it to the newer helper functions, ensuring compliance with industry standards for electronic invoice processing. This improves the accuracy and reliability of our accounting integrations.
Original PR description
After this commit 9cb237d, the rule was added, but from 18.0 and upper the old helps has been deprecated and removed on saas~18.4. With this commit, we add the rule also to the new helpers. OPW-5881918 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255870
This update fixes an issue where the expiration date on stock moves wasn't correctly updated when switching between lots. Now, the system accurately reflects the expiration date based on the lot being used, ensuring accurate tracking of perishable inventory. This improves inventory management and reduces the risk of expired products.
Original PR description
Steps to reproduce: - Enable "Expiration Dates" in Inventory settings - Create a storable product "P1" - Add 10 units with "Lot 1" - Enable expiration dates on product P1 - Add 10 units with "Lot 2"…
Steps to reproduce: - Enable "Expiration Dates" in Inventory settings - Create a storable product "P1" - Add 10 units with "Lot 1" - Enable expiration dates on product P1 - Add 10 units with "Lot 2" and set an expiration date - Create a delivery for 10 units of P1 - Mark as "To Do" - Open the move line -> "Lot 1" is automatically reserved - Change the lot from "Lot 1" to "Lot 2" -> The expiration date is not updated automatically - Save and reopen the move line -> The expiration date is correctly set - Change again to "Lot 1" - Save and reopen the move line -> The expiration date is not reset and incorrectly keeps the value from "Lot 2" Cause: The expiration date was only computed based on `lot_id`, ignoring the `quant_id` used during reservation. Additionally, the value was not reset when switching to a lot without an expiration date. Solution: - Add `quant_id` to the compute dependencies - Compute the expiration date based on `quant_id.lot_id` - Explicitly set an expiration date to today when the use_expiration_date product is set to True and the lot doesn't have an expiration date. Result: The expiration date is now correctly updated and cleared when changing lots on stock move lines. opw-5999294 Forward-Port-Of: odoo/odoo#254610
This update ensures that when an employee leaves, their outstanding appraisal schedules are automatically cancelled, preventing confusion and outdated data. It also removes the employee from appraisal roles and archives their personal goals, streamlining the system and improving data accuracy. This resolves an issue where departing employees continued to appear on appraisal schedules.
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 Forward-Port-Of: odoo/enterprise#111589
This update fixes an issue where the canteen cost was incorrectly calculated for Belgian employees, even when they had no attendance records. The fix ensures that the canteen cost is only applied if the employee has earned money through attendance or working during the payslip period, preventing incorrect charges.
Original PR description
[FIX] l10n_be_payroll: fix canteen cost computation
Bug reproduction: belgium company -> create a new employee -> new contract (payroll wage > 0) -> canteen_cost = 50 -> create payslip -> allocate time off for full month (such that there will be no attendance) -> recompute payslip -> still canteen cost is calculated
Bug cause:
1 - If l10n_be_canteen_cost is > 0 it was computing the canteen cost line for sure
2 - If result_rules['BASIC']['total'] is > 0 then the canteen cost was 50.
Bug solution:
1 - I add worked_days['WORK100'].amount != 0 to the computation condition.
2 - If there is any earned money from attendance or working in that payslip duration, the canteen cost should be deducted completely
3 - If the employee is absent during the payslip, the employee should not pay the canteen cost.
task - 6045406
Forward-Port-Of: odoo/enterprise#110991This update fixes an issue where duplicating a product template automatically published it, even if the original wasn't. The change ensures that duplicated products remain unpublished by default, aligning with expected behavior and preventing accidental product listings. This improves data consistency and simplifies product management.
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 Forward-Port-Of: odoo/enterprise#111340
This update resolves an issue where users would encounter an error when attempting to save a report with an empty XML format. The fix prevents the system from attempting to process invalid XML data, ensuring reports can be saved correctly. This improves the user experience and prevents data loss.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255316
This update resolves an issue where saving a report with an empty XML format in Web Studio would generate an error. The fix prevents the system from attempting to process empty XML data, ensuring a smoother user experience. This change improves stability and usability for report creation.
Original PR description
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External…
Currently an error is generated when the user tries to save a report with an empty XML format. Steps to reproduce: - Install web_studio and sale_management - Sales > Studio > Reports > New > External > Type Text in report - Save > Edit Sources > Remove full XML > Save Error: `XMLSyntaxError:Document is empty, line 1, column 1 (<string>, line 1)` This error occurs because line [1] in `web_editor` attempts to access nodes by using `etree.fromstring()` with an empty `view.arch`, which is empty, resulting in an error. In earlier versions, this error was already handled by the `_check_xml` constraint, which raised a validation error when an `etree.ParseError` occurred while parsing `etree.fromstring(view.arch)` with an empty `view.arch` (see code reference [2]). However, recent changes introduced in commit [3] allow `view.arch` to be empty. As a result, this error is no longer handled by the constraint. This commit fixes the issue by adding a condition to prevent calling `etree.fromstring()` when `view.arch` is empty, avoiding attempts to access nodes from invalid data. It also updates the logic in the `web_studio` module's `get_xml_editor_resources` method to ensure resources are processed only when a valid view architecture is available. [1]: https://github.com/odoo/odoo/blob/8a88756bed194910bc5a47e93f0e29610dbeee1f/addons/web_editor/models/ir_ui_view.py#L367 [2]: https://github.com/odoo/odoo/blob/75ca0fec9a0d3b1e3a05a8bf3101bbe21846ac7a/odoo/addons/base/models/ir_ui_view.py#L372-L377 [3]: https://github.com/odoo/odoo/commit/8334ea5c777e5a478f12b8bb7a2f54bcae537d0f sentry-6288795955 Forward-Port-Of: odoo/enterprise#88613
This update resolves an issue where the POS scale wasn't 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 the weight from the physical scale, improving the accuracy of order processing. This change impacts the IoT scale integration for POS systems.
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) Forward-Port-Of: odoo/enterprise#111963
This update optimizes how the system loads partner data for self-ordering, addressing performance issues when partners had extensive information. By only loading essential data, the change reduces loading times and improves the overall responsiveness of the self-ordering process.
Original PR description
Partner data loading for self-ordering was not optimized, leading to performance issues when the partner had a lot of data. This commit optimizes the partner data loading by only loading the necessary fields for self-ordering. Forward-Port-Of: odoo/odoo#253563
This update fixes an issue where employee pay calculations were inaccurate when using paid leave. The change ensures that worked days are correctly attributed to a single employee's payslip, preventing incorrect wage calculations for UAE employees with attendance-based work entries. This improves the accuracy of payroll processing.
Original PR description
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry…
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry source to attendance. - Register a paid leave time off entry, for the employee whose work entry source is set to attendance. - Compute a payslip batch using the UAE Monthly pay structure. - Go to the payslip of the employee with the work entry source set to attendance and compute the sheet again. - The 'Paid Leave' salary rule results, will change given that the computation of the field l10n_ae_hourly_wage is different when the computation is done for batches and individually. ### Cause: In 'Paid Leave' rule we use l10n_ae_hourly_wage to compute its result and while computing this field we use self.worked_days_line_ids instead of record inside the loop. This leads to an issue when self has more than one payslip it will take into account all the worked days for each payslip for different employees ### Fix: We use record instead of self to avoid taking other payslips into consideration while computing the hourly wage. opw-5979631 Forward-Port-Of: odoo/enterprise#111280
This update fixes an issue where the SEPA payment file version was incorrectly displayed as empty in the user interface. The fix ensures the correct 'PAIN 09' version is generated, aligning with Odoo's financial reporting standards. This improves the accuracy of payment file generation.
Original PR description
https://github.com/odoo/enterprise/commit/80f9f966d7db793ae82e65c76514323cb10e34ab tried to fix the issue, but assumed the field would be returned empty by the ORM when the value was inconsistent with the db. It's not true: it returns the database value ; only the UI shows the field as empty. Forward-Port-Of: odoo/enterprise#112141
This update resolves an issue where POS orders with both regular sales and settlement lines weren't being properly validated. The change ensures that mixed orders are now correctly blocked during settlement, aligning with the latest 'pos_settle_due' module updates. This improves the accuracy of financial reporting for Saudi businesses using Odoo POS.
Original PR description
# Description of the issue/feature this PR addresses: From saas-18.3 onward, the pos_settle_due module introduced a new method to identify settlement lines. While the old method **isSettleDueLine()**…
# Description of the issue/feature this PR addresses: From saas-18.3 onward, the pos_settle_due module introduced a new method to identify settlement lines. While the old method **isSettleDueLine()** is still there, the new **isAnySettleLine()** covers both order settlement and invoice settlement. This change was not reflected in the Saudi POS EDI integration during forward-porting, which caused incorrect validation when processing POS orders containing both regular sale lines and settlement lines. # Current behavior before PR: - Orders containing a mix of new sale lines and settlement lines could bypass the intended validation. - The validation logic relied on the old isSettleDueLine() method # Desired behavior after PR is merged: - Update the validation flow to use isAnySettleLine() (when available) to correctly detect settlement lines. - Prevent validation of POS orders that contain both settlement lines and new sale lines. - Ensure compatibility with newer versions of the pos_settle_due module and restore the intended settlement validation behavior. - Test case to ensure no regression on this feature I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)
This update fixes an issue where invoices with exchange differences and exchange accounts as write-offs were incorrectly fully reconciled even when the user chose to keep the invoice open for partial payment. The fix ensures that the system accurately handles payment registration and reconciliation when an exchange account is used, preventing incorrect accounting entries.
Original PR description
Currently, if a user selects an exchange difference account as a write-off but then decides to keep the invoice open, the system still fully reconciles the invoice. Steps to reproduce: - Create an…
Currently, if a user selects an exchange difference account as a write-off but then decides to keep the invoice open, the system still fully reconciles the invoice. Steps to reproduce: - Create an invoice in foreign currency - Click 'Register Payment' - Select company currency - Change the amount to a lower one - Select 'Mark as fully paid' - Add the exchange difference loss/gain account as write off account - Select 'Keep open' - Click 'Create payment' Issue: Even though the user selected the option to create a partial payment and keep the invoice open, it is totally reconciled with a difference booked in the selected exchange account. Analysis: This occurs because the use of the exchange account as write off account trigger a specific flow used in localization where a writeoff is not allowed. Once the payment registration process is ongoing, the system does not check that user kept the same choice on how to handle the payment difference. opw-5468052 Forward-Port-Of: odoo/odoo#254479 Forward-Port-Of: odoo/odoo#251965
This update automatically checks out employees from attendance when they are archived. Previously, archived employees remained checked in, which created inconsistencies. This change ensures accurate attendance records and simplifies the process for administrators.
Original PR description
Before: - When an employee was archived, their attendance was not updated. After: - When an employee is archived, if they are currently checked in, they will be automatically checked out at the current timestamp. task-5916700 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255845 Forward-Port-Of: odoo/odoo#255524
4 changes
Resolved issues and error corrections
This update ensures the external value pop-up displays numbers using the correct decimal separator based on the user's language settings. Previously, it always used a dot, which could cause confusion for users in regions that use a comma as a decimal separator. This change improves the user experience and data clarity.
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
This update resolves a problem where translations were failing to load correctly for the Chilean VAT reporting module. The change converts a complex list comprehension to a standard for loop, ensuring accurate translation context is used. This issue was primarily observed on Ubuntu Jammy and Debian Bookworm operating systems.
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 resolves an issue where tiny overtime hours (like seconds) were causing incorrect rate calculations on US payslip PDFs. The fix directly calculates the rate from hourly wage and multiplier, mirroring a previous successful implementation for Australia, ensuring accurate overtime pay is displayed. This improves the reliability of payroll reporting.
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 instead, inspired by edc4ed3c21b which did the same for Australia. task-6052711 Forward-Port-Of: odoo/enterprise#111540
This update fixes an issue where stock moves weren't correctly split when a quality control check resulted in a partial failure. Specifically, the system was incorrectly calculating the demand quantity for the failed stock. This ensures accurate stock accounting and reduces the risk of over- or under-stocking due to quality control processes. The fix ensures the correct quantity is moved to the failure location.
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 Forward-Port-Of: odoo/enterprise#107493
1 change
Miscellaneous changes
Since the function message_post on mail thread has been built to be called on exactly one record and the function write on employee is for multiple records, we need to call it for each employee we are writing on. It has been introduced in: https://github.com/odoo/odoo/pull/143217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196257
Original PR description
Since the function message_post on mail thread has been built to be called on exactly one record and the function write on employee is for multiple records, we need to call it for each employee we are writing on. It has been introduced in: https://github.com/odoo/odoo/pull/143217 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196257
16 changes
New functionality added to Odoo
This pull request adds a mapping between payroll data and accounting records within the Enterprise module. This enhancement ensures that payroll expenses are correctly categorized and tracked for accurate financial reporting. It improves the integration between HR and finance processes.
This update introduces a new report (2069-RCI) for French tax filings, specifically related to the 'liasse fiscal'. The changes include dynamic section additions for accurate reporting and consistency improvements to existing reports, ensuring compliance with French tax regulations.
Original PR description
This commit will add the new report 2069-RCI from the "liasse fiscal". Some sections needed some dynamic section to be added in the report. For each of them, a new line "Add new section" has been added that will create the needed line with the correct figure type in the report. Also did some change on the 2033 F for the naming of lines and sequence to be consistent task-5417364
Enhancements to existing features
This update adjusts the payroll calculations in Belgium to comply with a new law regarding guaranteed salary during a phased return to work following a period of incapacity. The changes ensure accurate accounting for reduced earnings during this transition period, aligning with government policy. New tests have also been added to validate the updated logic.
Original PR description
[IMP] l10n_be_hr_payroll: update neutralisation of guaranteed salary during progressive work resumption Updates the logic to comply the law (Modification de l’article 52, §5, alinéa relatif à la neutralisation du salaire garanti en cas de reprise progressive du travail, Loi du 19 décembre 2025 exécutant une politique renforcée de retour au travail en cas d’incapacité de travail) and add tests. task-5936812
This update adds 'Load More' and 'Search More' buttons to the shift template selection field, allowing users to easily access and select any of the available templates, regardless of the initial 10 displayed. Previously, users were limited to only the first 10 templates, now they can efficiently manage a larger selection of shift templates. This enhances usability and flexibility for shift planning.
Original PR description
_*=project_forecast Before this commit, the shift templates only displayed the first 10 templates. If users wanted to select a template beyond these 10, there was no way to access them. With this commit: A 'Load More' button is added when there are more than 10 templates. Clicking this button loads 10 additional templates at a time.Once 20 templates are loaded, the 'Load More' button is hidden, and a 'Search More' button appears instead. Clicking it opens a dialog box that displays the remaining template, allowing user to select from all available templates easily. This improvement ensures that users can access and select any related template beyond the initial set of 10. Task-3350675
This update standardizes the display of percentage fields within the Swiss payroll module. Previously, percentages were represented as whole numbers, which has now been changed to fractional numbers (ratio of 1.0) and displayed using a dedicated percentage widget. This ensures consistent and accurate reporting for Swiss payroll calculations.
Original PR description
Generalised the definition of fields displayed as percentages in the Swiss payroll ocalization to be fractional numbers (ratio of 1.0) rather than whole numbers (ratio of 100.0), and used the percentage widget to display them all. task-5169522
This update enhances Sendcloud label generation by adding package names (Pack01, Pack02) alongside the sales order number. This clarifies which label corresponds to which package, especially when orders contain multiple shipments, improving accuracy and traceability during shipping.
Original PR description
Currently, labels generated via Sendcloud display only the SO number. When a single sales order contains multiple packages (e.g. , Pack01 and Pack02), all generated labels look identical (e.g., S00001). This makes it difficult for users to quickly identify which label corresponds to which package during packing or shipping operations. Now, the labels generated via Sendcloud now include the package name when a package is specified, or the delivery name when no package is defined, in addition to the SO number. This change ensures that each label clearly reflects the exact parcel it is associated with, even in multi-package delivery flows. After this change, if S00001 has two packages, the label order numbers display: - S00001-Pack01 - S00001-Pack02 This improves parcel identification, reduces the risk of mislabeling, and enhances traceability for multi-package deliveries. task-4509005
Resolved issues and error corrections
This update improves the way attachments are handled within the website helpdesk module. A recent change allows the `insert_attachment` function to return attachment IDs, which are now correctly passed back to the website helpdesk override. This ensures attachments can be used effectively and avoids potential conflicts.
Original PR description
Following the changes in [PR](https://github.com/odoo/odoo/pull/219914), `insert_attachment` now returns `orphan_attachment_ids` so they can be reused outside the method. To avoid return-value conflicts in the website_helpdesk override, we return the result of the super call here. task-[4364668](https://www.odoo.com/odoo/all-tasks/4364668)
This update ensures that waiting payslips are automatically recalculated whenever key information related to payroll is changed. This guarantees that employees receive accurate payment details, resolving potential discrepancies and improving payroll reporting. The change impacts the HR Payroll module.
Original PR description
This commit makes waiting payslips recomputes whenever inputs are changed to make sure the sheet is up to date with inputs Task#5439146
This update restricts the use of the `DotDict` class to testing environments only. Previously, its improper use could lead to unexpected behavior. This change enhances stability and reduces potential issues in production code.
Original PR description
The `DotDict` class can produce unexpected behaviour if used incorrectly. This commit moves this class so that it is only used in tests. task-4822364
This update resolves an issue related to the format of Client IDs used in the payroll module, specifically for the Belgian HR payroll (l10n_be_hr_payroll). The change allows for both the old and new Client ID formats (with and without a hash) to be processed correctly, ensuring seamless integration with external systems.
Original PR description
Forward-Port-Of: odoo/enterprise#111531 Forward-Port-Of: odoo/enterprise#111276
This update resolves an issue where the l10n_ar_edi module fails to function correctly after upgrading. The fix ensures the module has a direct dependency on the currency_rate_live module, which is now correctly installed, preventing an error related to a missing currency provider setting.
Original PR description
The module [adds](https://github.com/odoo/enterprise/blob/master/l10n_ar_edi/models/res_company.py#L64-L67) selection values to field `res_company.currency_provider`, a field [defined](https://github.com/odoo/enterprise/blob/3dc72c9641f62990f5ed3c0ce0cda5ed7b6784a1/currency_rate_live/models/res_config_settings.py#L194-L200) in module `currency_rate_live`, but althouth it is auto-install, it's not a direct dependency, which can trigger errors. To reproduce: - Install `l10n_ar_edi` in 19 - Uninstall `currency_rate_live` - Upgrade to saas~19.2 It will break with ``` AssertionError: Field res.company.currency_provider without selection ```
This update resolves a minor issue within the l10n_ch_hr_payroll module, specifically correcting a file name that caused a potential error. This ensures the payroll calculations function smoothly and reliably, preventing disruptions to payroll processing. The change is a straightforward fix with no impact on core functionality.
Original PR description
related PR : https://github.com/odoo/enterprise/pull/103118
This update fixes a misunderstanding regarding the date a W4 form is filed with an employer. Previously, the system incorrectly tracked when the form was filled in, rather than the actual filing date. This change ensures accurate reporting and compliance related to US payroll.
Original PR description
This field is about when the W4 is filed with the employer, not when it's filled in. opw-5096780 Forward-Port-Of: odoo/enterprise#111679 Forward-Port-Of: odoo/enterprise#111213
This update fixes a previous issue where users couldn't access worksheet properties within the Quality Check process. The changes now display the worksheet tab and add a simplified validation button, streamlining the workflow and enhancing the user experience. This improves efficiency and clarity for users managing quality checks and maintenance requests.
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 Forward-Port-Of: odoo/enterprise#110899
This update fixes an issue where the SEPA payment file version was incorrectly displayed as empty in the Odoo interface. The fix ensures the correct 'PAIN 09' version is generated, aligning with the underlying database data. This improves the accuracy of payment file generation.
Original PR description
https://github.com/odoo/enterprise/commit/80f9f966d7db793ae82e65c76514323cb10e34ab tried to fix the issue, but assumed the field would be returned empty by the ORM when the value was inconsistent with the db. It's not true: it returns the database value ; only the UI shows the field as empty. Forward-Port-Of: odoo/enterprise#112141
This update fixes a crash that occurred when using the command palette to interact with the AI messaging feature. The change simplifies the AI action's return to prevent unexpected errors, ensuring a stable and reliable experience for users. This resolves a previous issue impacting AI functionality.
Original PR description
Prior to this fix, messaging the llm via the command palette would cause a crash because of some undefined value in the return of the action function in the `askAIProvide` method. This commit changes the action to a void returning function, which prevents the call from crashing.
11 changes
Enhancements to existing features
This update enables Peruvian Point of Sale (POS) systems to directly print E-invoices and receipts on thermal printers, aligning with local regulations and common retail practices. Previously, customers had to download invoices from an online portal. This change improves the customer experience by providing immediate, legally-recognized documentation.
Original PR description
Before: - In Peru, Point of Sale (POS) systems are allowed to generate E-invoices and E-receipts that comply with SUNAT’s requirements. - In the POS, Odoo prints a ticket that only includes a QR code linking to the customer portal, where the A4 invoice can be downloaded. - However, according to SUNAT and common practice in Peruvian retail environments, the printed POS ticket itself should serve as the legal representation of the electronic document After: - We allow Peruvian POS users to print electronic invoices and receipts directly on thermal printers (58 mm / 80 mm) using the same electronic document flow and data as the accounting module, ensuring full compliance with SUNAT’s representation requirements. Impact: - Improve customer experience by avoiding portal-only invoice download task-5193544
Resolved issues and error corrections
This update fixes a misinterpretation of the W4 filing date within the US payroll module. Previously, the system incorrectly associated the date of W4 completion with the date it's filed with the employer. This change ensures accurate tracking of the filing date, aligning with US tax regulations. This resolves a potential reporting discrepancy.
Original PR description
This field is about when the W4 is filed with the employer, not when it's filled in. opw-5096780 Forward-Port-Of: odoo/enterprise#111679 Forward-Port-Of: odoo/enterprise#111213
This update fixes an issue where the KMD INF report incorrectly included partners with turnover below 1,000 EUR. Now, the report accurately filters partners based on total invoice and credit note amounts, ensuring more precise financial reporting. The logic considers both standard and Part B transactions.
Original PR description
The KMD INF report should only include partners whose total turnover for the period reaches 1,000 EUR. Before this PR: - The report did not check this threshold, so partners below €1,000 were still shown. After this PR: - The threshold is now calculated correctly based on specific rules: - The threshold is calculated separately for invoices and credit notes per partner. - If invoices total base amount >= €1,000 OR credit notes total base amount >= €1,000, both invoices and credit notes are included in the report - The same logic applies to bills and refunds in Part B. task-5373606 Forward-Port-Of: odoo/enterprise#111737 Forward-Port-Of: odoo/enterprise#101333
This update resolves an issue where deleted serial numbers could not be rescanned using the rfid barcode scanner. The fix removes the serial number from a temporary cache, allowing it to be correctly processed when rescanned. This ensures accurate inventory tracking when using the rfid scanning feature.
Original PR description
**Problem:** When using rfid scan, a deleted line can not be scanned again **Steps to reproduce on localhost:** 1) create a new db with stock_barcode module 2) enable lot and sn setting 3) create a…
**Problem:**
When using rfid scan, a deleted line can
not be scanned again
**Steps to reproduce on localhost:**
1) create a new db with stock_barcode module
2) enable lot and sn setting
3) create a storable serial number product with
barcode 06016478556455
4) open barcode/ Count Inventory
5) to simulate a rfid scan of 3 serial numbers [1,2 and 3]:
- open browser console
- enter the following command :
`odoo.__WOWL_DEBUG__.root.env.services.mobile.bus.trigger("mobile_reader_scanned", { data: [
"urn:epc:id:sgtin:601647.0855645.1urn:epc:id:sgtin:601647.0855645.2urn:epc:id:sgtin:601647.0855645.3"
]});`
6) click the line with serial number "2", click on
the "-1" and then bin red button
7) repeat step 5
**Current behavior:**
the line for sn 2 is not added to the product
**Expected behavior:**
it should be added when rescanned
**Cause of the issue:**
When the uri barcodes are first scanned at step 5,
every uri is added to the uri cache, to be sure that
they are not mistakenly rescanned.
https://github.com/odoo/enterprise/blob/4296be6a81909dcdb094f728f8be45a8617ff54b/stock_barcode/static/src/models/barcode_model.js#L1615
Then when we scan again at step 7, because the uri
is in the cache, it's not added to filteredBarcodes and
it will not be processed.
https://github.com/odoo/enterprise/blob/4296be6a81909dcdb094f728f8be45a8617ff54b/stock_barcode/static/src/models/barcode_model.js#L688-L696
**fix**
we remove the uri from the cache when the line is deleted.
opw-5193250This update resolves an issue where the POS scale integration was not accurately displaying product weights, particularly with newer IoT box versions. The fix adjusts how the scale's measurement data is processed, ensuring correct weight readings are shown in the POS system. This improves the accuracy of product weighing for customers.
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) Forward-Port-Of: odoo/enterprise#111963
This update resolves a slow test within the Documents module by forcing the database to refresh its statistics. This optimization prevents inefficient query plans and significantly reduces test execution time, improving overall development efficiency. The change addresses a performance issue that was impacting test stability.
Original PR description
This commit introduces explicit `ANALYZE` statements on the `documents_document` and `documents_access` for the test `test_documents_embedded_actions_security`. This forces postgres to refresh its statistics for the current transaction, ensuring it uses efficient query plans. The slow test seemed to be cause by unnecessarily triggering jit and optimizing it. Especially the optimisation resulted in the test sometimes taking more than 3 minutes to run instead of taking seconds. Task-6005265 https://runbot224.odoo.com/runbot/static/build/102793860-master/tests/profile/profile_2.html#localProfilePath=1 <img width="1920" height="382" alt="SlowTest" src="https://github.com/user-attachments/assets/dea5a03d-9fc0-4fad-ac96-ef57d9816b46" />
This update resolves an issue where product descriptions in the shopping cart were displayed in reverse order. The root cause was a change introduced to prioritize certain information, but it failed to account for products with multi-line descriptions. The fix ensures product descriptions are correctly rendered in the cart, improving the user experience.
Original PR description
Issue: --- Due to this issue, the description following lines are inversed. Steps to reproduce: --- 1- In product page in backend, add a multiline "Short Description" to a product. 2- Navigate to website and add the product to the cart. 3- Open the cart. Outcome: The description after lines are shown inversed. Cause: --- This is introduced by odoo/odoo#223433. It was done to ensure some information such as rental date and variant description are shown at the beginning. However, it didn't consider that the product description itself might have multilines. Fix: --- There is not a clean way to extract the information from the computed name. To avoid the problem, we can compute the description following lines manually without depending on the line.name. opw-5976614
This update ensures that the currency used for Stripe expense payments is consistently defined within the company settings. Previously, this could lead to payment errors. This fix improves the reliability and accuracy of expense processing, preventing potential disruptions to employee reimbursements.
This update fixes a limitation in the Arabic reporting module, allowing businesses to accurately track and manage VAT across multiple branches. Previously, VAT book functionality was restricted, now it's enabled to support a more complete and compliant accounting process for businesses operating with multiple branches in the Arabic-speaking region.
Original PR description
Task: 62111 Manual FW of https://github.com/odoo/enterprise/pull/101898
This update resolves an issue where searching for delivery locations using only a zip code resulted in inaccurate location suggestions. The system was incorrectly interpreting zip codes as solely postal codes without a city designation, leading to incorrect data being sent to Sendcloud. This fix ensures accurate location retrieval for Sendcloud deliveries.
Original PR description
Issue ----- Searching for locations by only providing a zip code has unexpected results. Steps to reproduce ----- - Set up Sendcloud with Mondial Relay - Create a sale through the website - Get to the delivery part - Select sendcloud delivery - Search for a zip code only (11000) > Points are all in the 12200 area Cause ----- When searching through the wizard, a temporary address is created in https://github.com/odoo/odoo/blob/89e5038c224d58a2f6be8f3001fd0a2932733cbc/addons/delivery/models/sale_order.py#L108-L112 which always has its' city field set to `False`, as all of the wizard's info is interpreted as the zip code. This leads to the address field sent to Sendcloud being '11000 False' instead of the expected '11000', which Sendcloud fails to interpret correctly. ----- Ticket: opw-5999194
This update fixes a recurring issue where the Italian POS printer experienced errors when the system was offline. The fix adds a safety mechanism to gracefully handle network interruptions during receipt printing, preventing errors and improving the overall stability of the POS system for Italian businesses. This ensures smoother transactions even without an internet connection.
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#111487 Forward-Port-Of: odoo/enterprise#105515
8 changes
Enhancements to existing features
This update allows users to manually upload CL EDI invoices through a new system, streamlining invoice processing. The system now also automatically extracts specific fuel taxes from these invoices, improving accuracy and reducing manual data entry. This enhancement supports compliance with Chilean regulations.
Original PR description
- Adding the functionality of manually uploading CL EDI documents through fetchmail_server functions. Unrecognized documents are parsed as vendor bills. - Adjusting fetchmail_server behavior to read specific fuel taxes from vendor bills. Can be extended for other taxes. task-4259393
This update enhances budget reporting by automatically including asset accounts (current, non-current, and fixed) in budget tracking. Previously, budget reports only considered expense accounts. This change provides a more complete view of financial performance and allows for better asset management within the Odoo Enterprise system.
Original PR description
Expand the scope of budget tracking to include asset accounts. Modified the account filtering logic so that when a budget type is set to "Expenses" or "Both", the query includes 'asset_current', 'asset_non_current', and 'asset_fixed' account types. task-5994048
Resolved issues and error corrections
This update corrects a calculation error in payslips for employees using the UAE Monthly pay structure, specifically related to paid leave. The fix ensures accurate hourly wage calculations by preventing data from previous payslips from being incorrectly included in the current calculation. This improves payroll accuracy for UAE-based employees.
Original PR description
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry…
### Steps to reproduce: - Install the l10n_ae_hr_payroll module. - Configure at least two employees, who'll use the UAE Monthly pay structure. - On at least one of the employees, set the work entry source to attendance. - Register a paid leave time off entry, for the employee whose work entry source is set to attendance. - Compute a payslip batch using the UAE Monthly pay structure. - Go to the payslip of the employee with the work entry source set to attendance and compute the sheet again. - The 'Paid Leave' salary rule results, will change given that the computation of the field l10n_ae_hourly_wage is different when the computation is done for batches and individually. ### Cause: In 'Paid Leave' rule we use l10n_ae_hourly_wage to compute its result and while computing this field we use self.worked_days_line_ids instead of record inside the loop. This leads to an issue when self has more than one payslip it will take into account all the worked days for each payslip for different employees ### Fix: We use record instead of self to avoid taking other payslips into consideration while computing the hourly wage. opw-5979631
This update resolves an issue preventing superuser administrators from deleting work entry types within the payroll module. Previously, this action was restricted, leading to potential operational inefficiencies. Now, superusers can safely delete work entry types, streamlining payroll management.
Original PR description
Forward-Port-Of: odoo/enterprise#111967
This update corrects a bug where warranty pricing incorrectly applied to all lines associated with Field Service tasks, including the original service product. The fix ensures warranty pricing is applied only to additional products added to the task, maintaining the correct price for the initial service order. This prevents unexpected cost adjustments.
Original PR description
Steps to reproduce: - Create a Field Service service product configured to create a task. - Create a Sale Order and add the FSM service product. - Confirm the Sale Order to generate the FSM task. - Add an additional product to the newly created task. - Enable Under Warranty on the task. Issue: Enabling warranty sets the unit price of all task-related sale order lines to zero including the original FSM service line. Cause: Warranty logic does not exclude the original service sale order line. Solution Apply warranty pricing only to additional sale order lines linked to the task and keep the original FSM service line price unchanged. task-5403794
This update fixes a bug in Odoo's Web Studio that prevented users from adding chatter functionality to certain form views. Specifically, the system now validates that models support chatter before allowing it to be added, preventing an error and improving the user experience. This ensures smoother operation within Web Studio.
Original PR description
Currently, adding a chatter in a form view using web studio causes an error when the model does not inherit from mail.thread model. **Steps to Reproduce:** 1. Install the `data_cleaning` and…
Currently, adding a chatter in a form view using web studio causes an error when the model does not inherit from mail.thread model. **Steps to Reproduce:** 1. Install the `data_cleaning` and `web_studio` modules. 2. Data Cleaning > Configuration > Field Cleaning (form view). 3. Activate studio and open the XML view from the "View" tab. 4. Add `<chatter/>` tag inside the `<form>` tag and try to save the view. **Error:** `AttributeError - 'data_cleaning.model' object has no attribute '_get_thread_with_access'` **Cause:** The `.../mail/thread/data` controller passes the current model as a `thread_model` but the chatter can only be added module that inherits the 'mail.thread' module. When a chatter is added to a form view of a model that does not inherit mail.thread, resulting in an AttributeError. - [1] **Fix:** This commit prevents adding chatter to form views of models that do not support it. Instead of a traceback, a validation error is shown to the user. [1]: https://github.com/odoo/odoo/blob/71e86f38c7699aaea980c929c67835a3495edf55/addons/mail/controllers/thread.py#L18 sentry-6792833694
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 limits the consultant description to the abbreviation, ensuring compliance with validation requirements and successful report submission.
Original PR description
Description of the issue this commit addresses: During the tax return flow for the SBR development[^1], we discovered that the date format for the "DateTimeCreation" node had been wrongly readjusted and that the "ProfessionalAssociationForTaxServiceProvidersName" content could be too long due to showing the entire description. Those two issue cause the file to be rejected and make submission impossible. [^1]: https://www.odoo.com/odoo/967/tasks/6034675 --- Desired behavior after this commit is merged: This commit reintroduces the old DateTimeCreation format which is the only one that passes the tests done on the xbrl validation service[^2] and replaces the ProfessionalAssociationForTaxServiceProvidersName's value for the abreviation of the order instead of the entire description. [^2]: https://aansluiten.procesinfrastructuur.nl/site/validaties-digipoort/xbrl-validatie --- task-none Forward-Port-Of: odoo/enterprise#111923 Forward-Port-Of: odoo/enterprise#111817
This update corrects a previous issue where negative partner totals were incorrectly hidden and failed to account for sales transactions in Spanish tax reports. Now, all partner totals (positive or negative) are accurately displayed, and insurance operations are correctly categorized and reported from both sales and purchase journals.
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 Forward-Port-Of: odoo/enterprise#100413
2 changes
Resolved issues and error corrections
This change resolves an issue where tests were failing due to reliance on demo data that's no longer available in the testing environment. The fix automatically creates a new partner when needed, ensuring test stability and consistent results. This improves the reliability of our automated testing process.
Original PR description
4d844b7f3b570d7c3d978c6f10c351c48553df0b was a backport that was developed when demo data was installed during CI. However, time has passed, and demo isn't installed anymore causing the following:…
4d844b7f3b570d7c3d978c6f10c351c48553df0b was a backport that was developed when demo data was installed during CI.
However, time has passed, and demo isn't installed anymore causing the following:
```python
Traceback (most recent call last):
File "/data/build/enterprise/sale_amazon/tests/test_amazon.py", line 541, in test_sync_orders_replacement
"partner_id": self.env.ref("base.res_partner_1").id,
File "/data/build/odoo/odoo/api.py", line 596, in ref
res_model, res_id = self['ir.model.data']._xmlid_to_res_model_res_id(
File "/data/build/odoo/odoo/addons/base/models/ir_model.py", line 2215, in _xmlid_to_res_model_res_id
return self._xmlid_lookup(xmlid)
File "<decorator-gen-43>", line 2, in _xmlid_lookup
File "/data/build/odoo/odoo/tools/cache.py", line 104, in lookup
value = d[key] = self.method(*args, **kwargs)
File "/data/build/odoo/odoo/addons/base/models/ir_model.py", line 2208, in _xmlid_lookup
raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: base.res_partner_1
```
This commit creates a new partner on the fly instead.
runbot-241943This update clarifies the error message displayed when an upsell start date is set too close to the next invoice date. The change ensures users receive a more understandable explanation, preventing confusion and streamlining the subscription process. This improves the overall user experience and reduces potential support requests.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032