Daily updates from Odoo
Thursday, March 26, 2026
62 changes · saas-19.2
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#110860This update fixes a display issue in the SEPA payment file generation process. The system was incorrectly showing an empty field, but it was actually retrieving the correct SEPA PAIN 09 version from the database. This ensures accurate payment file generation and compliance.
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 streamlines the testing process for our VoIP features by pre-generating the necessary demo bundle. Previously, this bundle was rebuilt repeatedly during tests, causing significant delays. This change improves test execution speed and efficiency.
Original PR description
This commit sets the `voip.assets_sip_demo` bundle to be pregenerated while running tests to avoid rebuilding it at runtime (i.e. +800 times with a db "all").
This update ensures that when a subscription's salesperson is changed, all associated contacts are automatically updated as well. This eliminates manual data entry and maintains consistent information across the customer portal, improving efficiency and data accuracy. An automated test has been added to verify this functionality.
Original PR description
Before this commit, changing the salesperson on a subscription only updated the company partner, leaving child contacts with outdated salesperson info. After this commit, updating the subscription's salesperson also updates all child contacts of the company, ensuring consistency across the portal and reducing manual work. An unit test was added to ensure this behavior. task-5917271 Forward-Port-Of: odoo/enterprise#111861 Forward-Port-Of: odoo/enterprise#108339
This update significantly speeds up the bank reconciliation view, particularly when dealing with large volumes of financial data. The previous freezing issue, caused by redundant calculations, has been resolved, resulting in a much faster and more responsive user experience. This improves efficiency for users managing significant financial records.
Original PR description
The bank reconciliation view was freezing on large databases (50k+ invoices, 90k+ journal entries), making it impossible to expand lines, filter, or interact with the view in any way. Attempting to…
The bank reconciliation view was freezing on large databases (50k+ invoices, 90k+ journal entries), making it impossible to expand lines, filter, or interact with the view in any way. Attempting to open a line would sometimes result in a timeout. **Root cause:** The `reconciledLineName` getter was called multiple times per render cycle — once in `t-foreach` and again in the `t-if` condition. Since OWL re-evaluates the template on every reactive state change, this created an O(n×m) computation loop (n renders × m statement lines) that overwhelmed the browser. **Fix:** Cache the result in OWL reactive state via a dedicated `_computeReconciledLineName()` method, called once on setup and reactively via `useEffect` when `line_ids.records` changes. The template is updated to store `Object.entries(reconciledLineName)` in a `t-set` variable to avoid rebuilding the array on every iteration. | Metric | Before | After | |---|---|---| | Longest blocking task | 15 091 ms | 5 118 ms | | Total blocking time | 74 147 ms | 22 481 ms | | Avg. click response | 2 163 ms | 28 ms | | Max click response | 14 305 ms | 222 ms | | Total microtasks executed | 9 917 | 32 484 | opw-5879798 Forward-Port-Of: odoo/enterprise#111059 Forward-Port-Of: odoo/enterprise#107135
This update addresses a privacy concern by preventing minimal cashiers from seeing the total due amount in the partner list. This change protects sensitive financial information and aligns with best practices for cashier security. The fix was implemented to ensure a more secure and appropriate experience for all users.
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 ensures that all attendees of an appointment – including internal users and organizers – receive a booking confirmation notification, regardless of whether the booking syncs with Google or Outlook. Previously, notifications were limited, causing confusion for those not directly involved in the meeting. This change improves communication and ensures everyone is informed.
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 addresses an issue where the tax return check cards had excessive white space and misaligned elements, making them difficult to read. The changes create a cleaner, more professional-looking card design, improving the user experience.
Original PR description
Description of the issue this commit addresses: The UI of the tax return check cards has too many white spaces and misaligned items causing counterintuitive reading. --- Desired behavior after this commit is merged: The cards have a cleaner spacing within them so the UI looks cleaner. --- task-6003121
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#111940 Forward-Port-Of: odoo/enterprise#101333
This update resolves a minor issue where the helpdesk tour occasionally failed due to the tour attempting to click a button before the helpdesk view was fully loaded. By ensuring the helpdesk view is fully rendered before the tour attempts to interact with it, this fix improves the overall stability and reliability of the tour experience.
Original PR description
This PR fixes a flickering failure in the `helpdesk_tour` ### Problem In the kanban view, the tour occasionally tried to click the "New" (quick create) button before the view's internal structure was fully painted. This caused the tour to click a wrong element. ### Solution Updated the step trigger to include a selector for the kanban group (`.o_kanban_group`). By requiring the presence of the group container, we ensure that: 1. The page content has actually loaded. 2. The specific "New" button within the kanban context is visible and ready. **Runbot ID: 223081** Forward-Port-Of: odoo/enterprise#110333
This update corrects a technical issue where the system was incorrectly limiting VAT numbers to 18 characters, causing problems when integrating with FedEx. The change ensures that VAT numbers, including those with longer formats like in Switzerland, are properly transmitted to FedEx, preventing delivery errors. This improves the reliability of shipments using FedEx.
Original PR description
Issue ----- Fedex limits VAT numbers to 18 char long strings. This is contradictory with how they are stored in db for some countries (eg Switzerland, where the format is CHE-123.456.788 VAT -> 19 char long). Steps to reproduce ----- - Setup Fedex - Create a customer - Company (for VAT number) - VAT number: CHE-123.456.788 TVA - Create a delivery and confirm it Cause ----- VAT number is retrieved as is in https://github.com/odoo/enterprise/blob/0220d413988708c662ffca3c7fb38641c3d9870a/delivery_fedex_rest/models/fedex_request.py#L332-L343 ----- Ticket: opw-5926452 Forward-Port-Of: odoo/enterprise#111864 Forward-Port-Of: odoo/enterprise#109999
This update resolves an issue where users couldn't add reactions to messages within the 'mail_group' module in Discuss. The fix ensures that the 'add reaction' button is only displayed for messages that properly inherit from the standard messaging 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#112069 Forward-Port-Of: odoo/enterprise#111271
This update corrects a minor error in the demo data for the l10n_ch_hr_payroll module. Specifically, an incorrect reference to insurance data was removed, ensuring the demo data accurately reflects the module's functionality. This ensures consistent and reliable demo data for testing and training.
Original PR description
This commit removes an unnecessary record and fix wrong reference to the insurance line of the insurance group in the demo data of the l10n_ch_hr_payroll module. task-6070942 Forward-Port-Of: odoo/enterprise#112121
This update resolves an issue where PDF merging errors didn't consistently display user-friendly error messages. The fix ensures that a clear error message is shown when PDF merging fails, regardless of the underlying cause (like a corrupted PDF). This improves the user experience and helps identify problems with report generation.
Original PR description
When merging pdfs, if there is an error when meging those pdfs (due to a malformed PDF for example), the UserError that should be shown to the user is not due to an error in the arguments given to…
When merging pdfs, if there is an error when meging those pdfs (due to a malformed PDF for example), the UserError that should be shown to the user is not due to an error in the arguments given to the handle_error function.
The aim here is to keep the same function signature and edit the signature of the local function used when a custom_handle_error was defined and edit the function itself.
The error message appeared when I was working on a task to change a
test and tested it on master and got the following stacktrace:
```
...
File "/home/odoo/Desktop/src/odoo/odoo/addons/base/models/ir_actions_report.py", line 788, in _merge_pdfs
handle_error(error=e, error_stream=stream)
TypeError: IrActionsReport._handle_merge_pdfs_error() missing 1 required positional argument: 'self'
```
Discovered during : task-3603619
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#255173
Forward-Port-Of: odoo/odoo#211611This update ensures ZATCA invoicing is correctly skipped for new Point of Sale settlement orders (Settle Due) in saas-19.2. Previously, a change in the POS flow required manual invoicing adjustments. This fix prevents incorrect ZATCA reporting and avoids complex mixed order scenarios, ensuring accurate tax compliance.
Original PR description
# Description of the issue/feature this PR addresses In Point of Sale with ZATCA enabled (l10n_sa_edi_pos), invoicing is enforced on all orders. In 18.0, settlement and deposit flows were both…
# Description of the issue/feature this PR addresses In Point of Sale with ZATCA enabled (l10n_sa_edi_pos), invoicing is enforced on all orders. In 18.0, settlement and deposit flows were both correctly excluded from mandatory ZATCA invoicing using the is_settling_account flag. From saas-18.2, the Settle Due flow was refactored to include a dedicated settlement product line. As a result, is_settling_account now only covers account deposit flows, and is no longer sufficient to identify Settle Due orders. # Current behavior before PR With ZATCA enabled on saas-18.2: - Account deposit flows are still correctly excluded from mandatory invoicing using is_settling_account. - Settle Due orders are no longer detected by this flag and are treated as standard sales because they now contain order lines. - This causes ZATCA invoice enforcement to be applied to Settle Due orders, even though the original invoice was already reported. - Additionally, mixed orders combining settlement lines and new sale items would require partial ZATCA reporting, which is not supported. # Desired behavior after PR is merged After this fix: - ZATCA invoice enforcement is skipped for account deposit flows using the existing is_settling_account flag. - Even if invoice is checked, the invoice is not sent to ZATCA - Settle Due orders are correctly identified using the isSettleDueLine() check on order lines and excluded from mandatory ZATCA invoicing. - Mixed settlement and sale orders are explicitly blocked for ZATCA to avoid inconsistent or partial reporting. This restores the intended settlement behavior from 18.0 while adapting it to the refactored Settle Due flow in saas-18.2. task-5144679 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254195 Forward-Port-Of: odoo/odoo#244712
This update fixes a bug where users could confirm popups with empty input fields, such as gift card codes. Now, the confirmation button is disabled if the input is blank or contains only spaces, ensuring data integrity and preventing incorrect transactions. This impacts key features like adding floors and generating gift cards.
Original PR description
*= point_of_sale, pos_loyalty, pos_restaurant Before this commit: =================== - User was able to confirm `TextInputPopup` with an empty input value. Affected functionalities: - Add New Floor - Rename Floor / Table - Enter Code (Gift card or Discount code) - Generate a Gift Card After this commit: ================== - The confirm button will be disabled if the input value is empty or has only spaces so that an empty string will not be accepted. Task-6019160 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255490 Forward-Port-Of: odoo/odoo#253307
This update fixes a bug that prevented the Google address autocomplete feature from working correctly when certain modules modified address fields. The change adds a new widget to street fields and handles address autocomplete in e-commerce, ensuring accurate and reliable address input for users. It also updates access rights for city selection.
Original PR description
_= base,base_address_extended,google_address_autocomplete,website_sale_autocomplete The Google autocomplete feature was breaking when modules such as base_extended_address modified the address form (e.g., replacing street with street_name, street_number, etc.). In this commit: --- - Add the Google autocomplete widget to street-related fields. - Also same thing handled in frontened (e-commerce address autocomplete). - and update 'city_id' from available cities records if matches with google result. - ```update access_rights for RecCity Model - grant read access to public user``` --- task-5382984 opw-5362597 Forward-Port-Of: odoo/odoo#255728 Forward-Port-Of: odoo/odoo#238672
This update resolves an issue where Field Service Reports generated for multiple tasks sometimes produced duplicate PDF files. The fix addresses a flaw in how the system handles report generation, ensuring that reports are created correctly regardless of the number of tasks included. This improves the reliability of report output 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 fixes a problem where users accessing the website without logging in would sometimes receive a '404' error. The fix ensures that website access rules correctly identify public records, allowing users to view blog posts as intended. This improves the overall user experience for website visitors.
Original PR description
\* = test_website_modules ### Issue: When accessing a record from the website without logging in, a `404` error occurs if a public record rule filters records by website related domain, for example…
\* = test_website_modules
### Issue:
When accessing a record from the website without logging in, a `404`
error occurs if a public record rule filters records by website related
domain, for example `[('website_id', '=', website.id)]`.
### Steps to reproduce:
- Install the 'website_blog' module and create at least one website.
- Enable debug mode.
- Go to Settings > Technical > Database Structure > Models.
- Open the `blog.post` model.
- Go to the 'Record Rules' tab.
- For the record 'Blog Post: public: published only', change the domain
from `[('website_published', '=', True)]` to
`[('website_id', '=', website.id)]`.
- Go to Website > Configuration > Blogs.
- Open a blog (e.g., Travel).
- Select 'My Website' in its 'Website' field.
- Open 'My Website' without logging in.
- Click on the 'Blog' menu and the blog listing will appear correctly.
- Try opening a blog post and a `404` error occurs.
### Reason:
<pre>
┌─────────────────────────────────────────────────────────┐
│ Request Lifecycle │
├─────────────────────────────────────────────────────────┤
│ │
│ User Request (not logged in) │
│ ↓ │
│ ┌──────────────────────────────────────┐ │
│ │ 1. _pre_dispatch │ │
│ │ ↓ │ │
│ │ check_access_rule │ │
│ │ ↓ │ │
│ │ _eval_context (compute domain) │ │
│ │ ↓ │ │
│ │ get_request_website() │ │
│ │ ↓ │ │
│ │ request.website = None │ ← Issue │
│ │ ↓ │ │
│ │ Domain evaluation FAILS │ │
│ │ ↓ │ │
│ │ Access DENIED → 404 Error │ │
│ └──────────────────────────────────────┘ │
│ ↓ │
│ ┌──────────────────────────────────────┐ │
│ │ 2. _frontend_pre_dispatch │ │
│ │ (NEVER REACHED) │ │
│ │ ↓ │ │
│ │ request.website initialized ✓ │ ← Too Late │
│ └──────────────────────────────────────┘ │
│ │
└─────────────────────────────────────────────────────────┘
</pre>
Because `request.website` is initialized later in
`_frontend_pre_dispatch`, access rules evaluated earlier in
`_pre_dispatch` cannot rely on website context. As a result, record
rules depending on `website_id` are evaluated before `request.website`
is available, incorrectly denying access to public records.
### Fix:
Avoid totally relying on `get_request_website` during access rule
evaluation. Use the `request.is_frontend` attribute as a fallback, which
is set earlier, to detect frontend requests and ensure correct access
handling.
task-[4758311](https://www.odoo.com/odoo/project/974/tasks/4758311)
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#255708
Forward-Port-Of: odoo/odoo#213143This update corrects a bug where an extra product received during a backorder creation would automatically trigger the creation of an additional return. The fix ensures that only the necessary products are involved in the backorder process, streamlining operations and preventing duplicate return entries. This improves order accuracy and reduces potential errors.
Original PR description
When creating a backorder because of missing product, if there is an extra product received it will create a return also create a return for that product. ### Steps to reproduce: * Create and confirm…
When creating a backorder because of missing product, if there is an extra product received it will create a return also create a return for that product. ### Steps to reproduce: * Create and confirm a purchase ordre for 2 products (A & B) * Add a product C to the picking order and reduce the quantity of product B received * Validate the picking ordre * Create a backorder * Go back on the PO and open the linked pickings -> There is delivery linked for product C ### Observation: When processing the backorder, it will sync the delivery and the PO with _action_synch_order where it will add the new product to the PO: https://github.com/odoo/odoo/blob/1a62c4333de61a4e1358ef8e229b2e0f5a3e9826/addons/purchase_stock/models/stock_move.py#L88-L89 The create that is started by the creation of the new POL will trigger _create_or_update_picking that will create a stock move and a picking: https://github.com/odoo/odoo/blob/2855f0f2b0ffbc340e2af4785dde5bf465579ee8/addons/purchase_stock/models/purchase_order_line.py#L97 https://github.com/odoo/odoo/blob/2855f0f2b0ffbc340e2af4785dde5bf465579ee8/addons/purchase_stock/models/purchase_order_line.py#L197-L198 opw-5868172 Forward-Port-Of: odoo/odoo#255640 Forward-Port-Of: odoo/odoo#248433
This update resolves an issue where the global search modal prevented users from adding snippets to products. The change ensures the modal closes automatically when entering edit mode, allowing seamless snippet functionality. This improves the user experience for adding product information.
Original PR description
Steps to reproduce: - Go to the Shop and enable the floating toolbar. - Click the search icon in the header. - When the search modal opens, click 'Edit' to enable website editing. - Try to add a snippet from the floating toolbar. => The same issue also occurs on individual product pages. Observed behavior: Snippets cannot be added while the global search modal remains open. Expected behavior: Snippets should be draggable and added normally in edit mode. This PR ensures that the global search modal is closed when entering edit mode, preventing it from blocking add snippet. task-5905963 Forward-Port-Of: odoo/odoo#255607 Forward-Port-Of: odoo/odoo#247781
This update resolves an issue where workorders weren't correctly reflecting planned leave time. The team has reverted a previous change that was causing problems with how leave was managed, and now workorders are accurately updated when leave is scheduled or removed. This ensures accurate tracking of workorder availability.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves a technical issue that could cause errors when processing certain order lines in the Point of Sale (POS) system. Specifically, the system was encountering a problem when attempting to add lines with no product information. This change skips these lines, ensuring smoother order processing and preventing potential disruptions to sales.
Original PR description
`line_subsection` lines have no product, so calling `addLineToCurrentOrder` on them raised a TypeError trying to read `taxes_id` of undefined. Skip them early, the same way `line_section` is handled. opw-5949585 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255360
This update fixes a visual issue where floor plans in RTL languages (like Arabic) were incorrectly positioned. The change adjusts how floor plan elements are rendered to account for the different anchor point of `position: absolute` elements, ensuring accurate display in RTL layouts. This improves the user experience for customers using these languages.
Original PR description
In RTL languages (e.g. Arabic), `position: absolute` elements anchor to the top-right corner of their containing block instead of top-left. Since floor plan elements are positioned via `transform: translate(left, top)` using pixel coordinates stored from a top-left origin, all tables and decor elements were rendered at wrong positions when the UI direction was RTL. opw-6040855 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255813
A recent update to Odoo introduced a validation error when resetting the 'Lead Forward' email template. This PR resolves this issue by updating the template to align with newer Odoo versions, addressing a compatibility problem. Users can now reliably reset the template without encountering errors.
Original PR description
Steps to reproduce: - Create a lead > click on gear icon > Forward to partner - Send the forward and ensure there is at least one record of crm.forward.to.partner - Navigate to email templates technical settings menu and search for Lead Forward: Send to partner - Click on Reset Template in the template form Current behavior: - Validation Error thrown Expected behavior: - No validation error thrown and template is reset Note: MailTemplate._check_can_be_rendered was added in version 18.3 which checks for invalid object references when trying to alter + save templates. This template was out of date and fails the check Referenced PR: https://github.com/odoo/odoo/pull/176623 opw-6001560 Forward-Port-Of: odoo/odoo#254819 Forward-Port-Of: odoo/odoo#252599
Previously, a select dialog opened from a record selector or relational field would display an unclear 'Search: undefined' title. This fix ensures the dialog title is set to 'Search' if the expected information isn't available, providing a cleaner and more user-friendly experience. This resolves a minor visual issue.
Original PR description
…e title When opening a selectCreateDialog from a record selector or a relational field, when no (or empty) fieldString was passed to form the dialog's title , an ugly `Search: undefined` was set as the title After this commit, if we don't receive the right props, we simply set the title to `Search` part-of-task-5932652 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#255777
This update fixes an issue where the image quality slider disappeared when using images with shapes in Odoo. The change ensures the slider functions correctly regardless of whether the image format or shape options are modified, improving the user experience for image customization. This resolves a visual glitch impacting image display.
Original PR description
Before this commit, the quality option would not work properly for images with a shape applied by default. After changing an option, the DOM would be updated and the slider disappeared because the…
Before this commit, the quality option would not work properly for images with a shape applied by default. After changing an option, the DOM would be updated and the slider disappeared because the image format would not be considered valid anymore.
Steps to reproduce the issue :
- Drop a snippet with an image with a shape (.s_cta_mockup, ...)
- Do one of the following:
- Move the quality slider
- Change an shape option
=> The Quality slider disappeared.
If the user replaces an image with a png, sets the format to "webp" and adds a shape, the dataset would have the following :
- format-mimetype: the value of the format option ("image/webp")
- mimetype-before-conversion: the original format ("image/png")
- mimetype: the mimetype of an image with shape ("image/svg+xml")
We first evaluate "data-format-mimetype", as it indicates the current format of the image (if it was changed by the user). Otherwise, we check "data-mimetype-before-conversion" since the mimetype for an image with shape is always "image/svg+xml" and doesn't correspond to the real image format. Finally, default to getMimetype to avoid issue for images on which nothing no option was changed.
task-5358952
Forward-Port-Of: odoo/odoo#240360This update fixes a technical issue that prevented users from properly closing the online payment popup in the POS system. The previous system incorrectly relied on an outdated 'currentOrder,' leading to errors. This change ensures the system uses the correct 'order' data, improving the payment process and preventing disruptions for customers.
Original PR description
Before this commit, when the user closed the online payment popup, an error was raised because the currentOrder was not valid and instead order must be used. opw-6034405 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255292
This update resolves an issue preventing the preview of certain reports, specifically the DIN 5008 layout, in Odoo 19.1 and later. The fix addresses a change that removed a key variable used to correctly render these previews, ensuring they function as expected.
Original PR description
Under some conditions, it is currently not possible to render the preview of some layouts To reproduce the issue: (Need `l10n_din5008`) 1. Open Settings more times than the number of companies in the…
Under some conditions, it is currently not possible to render the preview of some layouts To reproduce the issue: (Need `l10n_din5008`) 1. Open Settings more times than the number of companies in the database - (We actually need to increase the psql sequence of its table...) 2. Configure your document layout - Layout: DIN 5008 3. Click "Preview Document" Error: an error is displayed: "Missing record: Record does not exist or has been deleted. (Record: res.company(4,), User: 2)" When clicking on _Preview Document_, we are actually requesting `/report/pdf/web.preview_externalreport/4` Where we have both the report name and the `docids` (equal to `4` in the above example). Since we are calling it from the `res.config.settings`, we provide the doc IDs with the ID of the `res.config.settings`. However, the report is based on the `res.company` model: https://github.com/odoo/odoo/blob/2f64f909d2f20cc8c0a8e95ba7d17348b9b015e6/addons/base_setup/views/res_config_settings_views.xml#L90 https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/web/views/report_templates.xml#L1006-L1010 As a consequence, the mechanism will try to render the report using the company with ID equal to the ID of the config settings, which does not make sense. This is the reason why, at some point, it can lead to a `Missing Record` error. That said, the case is working well on previous versions because we were defining a global `o` variable before rendering the template, cf for instance on Odoo 19, L896: https://github.com/odoo/odoo/blob/1c2e17718e6f2a11d93585f0ea3ba3abee5a4a41/addons/web/views/report_templates.xml#L893-L897 Thanks to that variable, DIN 5008 side, we ignore the `docs`, cf here for instance: https://github.com/odoo/odoo/blob/dae4fd0000080ba6395b370e25d3f13f1becd74e/addons/l10n_din5008/report/din5008_report.xml#L96 On Odoo 19.1+, this global variable has been removed by [1]. This commit is actually the result of a script (cf its description). Since the script hasn't detected the use of `o`, it moved its declaration inside the previous `t-call`, L829: https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/web/views/report_templates.xml#L827-L830 This was a mistake since the global variable is sometimes used. Long story short, the script didn't see the dynamic `t-call` inside the template of `web.external_layout`: https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/web/views/report_templates.xml#L758-L761 We have therefore decided to revert this part of the commit and apply the same logic to its siblings `preview_internalreport` and `preview_layout_report` [1] https://github.com/odoo/odoo/commit/b7ec60d68c6ee23f7684960e33e5bd6290c9d829 OPW-5951003 Forward-Port-Of: odoo/odoo#254198
This update resolves an issue where the expiration date for products wasn't correctly updated when switching between lots. The fix ensures that the expiration date accurately reflects the lot being used, improving inventory management and traceability. This prevents discrepancies in product expiry tracking.
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 corrects a problem where incorrect withholding reasons on Italian invoices were causing issues during import. The change relaxes the rules to allow taxes with the same withholding type to be used, ensuring invoices are processed correctly. This improves the accuracy of VAT calculations for Italian customers.
Original PR description
Some invoice come in with a wrong ENASARCO withholding reason. We now broaden the search to allow taxes with the same withholding type to be used during import even if the withholding reason doesn't match. In the test, I change the Enasarco tax to reason Q to check that it gets correctly assigned. Ticket [link](https://www.odoo.com/odoo/project.task/5175587), [link](https://www.odoo.com/odoo/project.task/5933699) opw-5175587 opw-5933699 Forward-Port-Of: odoo/odoo#255725 Forward-Port-Of: odoo/odoo#236251
This update resolves an issue where a partner's identification type was incorrectly set based on its country. The change ensures that a partner's ID type remains consistent regardless of the selected country, preventing data discrepancies and improving data accuracy for Latin American reporting. This fix was implemented to maintain the integrity of partner records.
Original PR description
**PROBLEM** PR: https://github.com/odoo/odoo/pull/179078 Removed _onchange_country_id() which was used to set the identification type according to the country of the partner. This PR reintroduce it, so id type and country remains consistent. **STEP TO REPRODUCE** 1. install l10n_ar and l10n_co. 2. create a new partner. 3. set its country to Argentina, and select an argentinian id type. 4. set the country to Colombia and save. You end up with a partner from Colombia, with a id type that is used for Argentinian partners which shouldn't be possible. opw-5801824 Forward-Port-Of: odoo/odoo#248585
This update ensures that Point of Sale orders are automatically assigned a default product preset when one isn't explicitly provided. Previously, orders created without a preset ID would not use the configured default. This change aligns with how other key settings like price lists are handled, ensuring consistent and reliable order processing.
Original PR description
When a pos.order was created without a preset_id (e.g. frontend order synced before the async preset dialog resolved, or any other path that omits the field), _complete_values_from_session did not fall back to the config's default_preset_id. Apply it the same way pricelist and fiscal position are defaulted, without overriding an explicitly passed value. opw-5997872 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251934
This update resolves an issue where custom snippets created from dynamic snippets would have a different layout than the original. The fix ensures that attributes from dynamic snippets are preserved when creating custom snippets, maintaining the intended design and functionality. This improves the user experience when customizing website content.
Original PR description
The commit ae4824640665fc639e03a13c341f18e73060349e, added cleaning of some attributes used by filter controller for dynamic snippet. Those attributes are also saved when changed by the user. When the user creates a custom snippet based on a dynamic snippet, the attributes appears legitimately on the root of the view, but the cleaning code removes them. This commit adds a condition to only remove those attributes only if the node is "not static" (and therefore are not causing the issue for which the cleaning code was added). Steps to reproduce: - Open website builder - Drop the snippet `s_blog_posts_horizontal`, and click on it - Save it as a custom snippet - Drop the custom snippet - Bug: The layout is different than the original snippet task-5969305 Forward-Port-Of: odoo/odoo#254613
This update fixes a reporting issue where product inventory tracking changes didn't properly adjust stock valuations. Previously, after setting a product to track inventory, the system incorrectly reported stock values. This change ensures that inventory adjustments are automatically applied when a product's tracking status is updated, providing accurate stock valuation reports.
Original PR description
### Steps to reproduce: - Create a product that is not track inventory (`is_storable = False`) - Set its cost to 50$ and put it in an avco perpetual valuation category - Create and receive a purchase…
### Steps to reproduce: - Create a product that is not track inventory (`is_storable = False`) - Set its cost to 50$ and put it in an avco perpetual valuation category - Create and receive a purchase order for 10 units - Set the product as track inventory (`is_storable = True`) - Inventory > Reporting > Stock - Click on the `unit cost` of your product line #### > This opens the `stock.avco.report` according to which the total value of your stock is 500$ and the total quantity is 10 units even though do not have any unit in stock. ### Expected behavior: The line of the receipt should have been counter balanced by an inventory adjustment line to resets the valuation at the same time as the product has been set to `is_storable` ### Cause of the issue: There is currently no mechanism to counter balance the stock that should have been present in internal locations if the moves done had been processed with a storable product. opw-5472902 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255557 Forward-Port-Of: odoo/odoo#254380
This update resolves a technical issue that caused instability in the HTML editor's automated tests. The fix ensures the editor is fully loaded before tests attempt to interact with it, preventing test failures due to timing differences. This improves the reliability of the HTML editor.
Original PR description
See commit messages. Forward-Port-Of: odoo/odoo#253432 Forward-Port-Of: odoo/odoo#253051
This update fixes a test failure related to email notifications in the Google Calendar and Mail modules. The previous test incorrectly checked for empty timeout emails, leading to false positives. Now, the test focuses on ensuring no emails are sent for any message, regardless of recipient, improving test reliability.
Original PR description
No need to always check the timeout email_to always contains formatted emails. task-5152917 Forward-Port-Of: odoo/odoo#255635 Forward-Port-Of: odoo/odoo#230766
This update ensures that attachment files are always linked to the corresponding financial transaction (move) within the Odoo system. Previously, updates to the transaction and attachments were handled separately, which could lead to inconsistencies. This change guarantees data integrity and avoids potential errors when managing financial records.
Original PR description
Was committing the move fields update, then updating the attachment. This might create an issue were the move update commits successfully, but setting the attachment fails and we end up with an inconsistency. Set attachment in the same transaction as the move update. task-6035727 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255745 Forward-Port-Of: odoo/odoo#255262
This update fixes an issue where invoices with exchange differences and exchange accounts as write-offs were incorrectly fully reconciled after the user chose to keep the invoice open. Now, the system accurately reflects partial payments and maintains the selected exchange account for reconciliation, ensuring correct financial reporting.
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 resolves an issue where the user interface would freeze during reloadable operations. The fix ensures the UI is always released, preventing blocks and improving the overall user experience. This enhancement contributes to a smoother and more reliable application.
Original PR description
Since commit [1], the UI is blocked during a reloadable operation, but an early exit on error prevented unblock() from being called. This commit fixes it by wrapping it in a try/finally to ensure the UI is always unblocked. [1]: https://github.com/odoo/odoo/commit/453b7eb8e038ee8e8a54de16fc1a45fb2fab573a Forward-Port-Of: odoo/odoo#255654 Forward-Port-Of: odoo/odoo#255477
A test within the sale_timesheet module was failing due to a missing dependency on the invoicing module. The fix ensures the invoicing module is automatically installed during test execution, allowing the test to run correctly. This prevents disruptions to the testing process.
Original PR description
__ ## Error description When the test runs following a specific configuration, the field `invoicing_switch_threshold` isn't found. However, we have to keep this field in the test because we can't replicate the issue the test checks without it. ## Origin of the issue This field belongs to the `account_accountant` (Invoicing) module. However, `sale_timesheet` doesn't have a dependency on this module: there's only an auto install for `account_accountant` when installing the module from the front-end. Therefore, if we launch the test without the `account_accountant` auto install, it will fail. __ original commit: https://github.com/odoo/odoo/pull/250946/changes/52a9841c754466c2df65c75d13c9ed2ae86a51ce Forward-Port-Of: odoo/odoo#254506 Forward-Port-Of: odoo/odoo#252772
This update fixes a technical error that prevented users from sharing course content hosted externally via Google Drive. The issue stemmed from a browser security restriction (Same-Origin Policy) when accessing the content's internal structure. This change ensures seamless content sharing functionality for all course types.
Original PR description
Step to reproduce: 1. Install `website_slides` 2. Open any course and add content 3. Select the `Document` type and upload a Google Drive link 4. Save and publish the content 5. Click the "Share" button for this specific content in full screen Issue: - A traceback occurs: `Uncaught Javascript Error > Failed to read a named property 'document' from 'Window': Blocked a frame with origin "http://localhost:3000" from accessing a cross-origin frame.` Cause: - The `_onClickShareSlide` method attempts to calculate the `documentMaxPage` by accessing the internal DOM of the slide's iframe (`iframe.contentWindow.document`). When the content is hosted externally the iframe source is cross-origin. Browsers enforce the Same-Origin Policy. Solution: - Check the origin of the iframe's source URL before attempting to get max page. opw-5422655 Forward-Port-Of: odoo/odoo#251859 Forward-Port-Of: odoo/odoo#241090
This update resolves an issue where users couldn't download attachments linked within the website editor when browsing in incognito mode. The fix ensures the correct access token is included in the download link, allowing attachments to be accessed consistently across different browsing sessions. This improves the user experience and prevents data access limitations.
Original PR description
# How to reproduce
- Go to the website in edit mode
- Select some text
- Upload and link an attachment to that text
- Open a new incognito tab
- Try to download the attachment
# The problem
An error 404 is displayed
# Why
The access token of the attachment is not correctly added in the link URL. This is because link_popover.js does not correctly call the upload function from the uploadLocalFile services.
The signature of that function is :
```py
async function upload(
{ resId, resModel },
{ accept = "*/*", multiple = false, accessToken = false } = {}
) {
```
opw-5500362
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#251427This update fixes a previous restriction that prevented users from editing taxes on reward lines within confirmed sales orders. Previously, changes would trigger a recomputation of taxes, now edits are permitted on confirmed orders as the tax calculation is no longer affected. This improves order management flexibility.
Original PR description
Issue: --- Due to this issue, the tax on reward SOL cannot be edited. Cause: --- This is introduced in #172110 to prevent users from editing taxes on reward lines because confirming the order would recompute the tax. We can make it editable on confirmed SO as the tax wouldn't recomputed on reward lines later. opw-5918435 Forward-Port-Of: odoo/odoo#255644 Forward-Port-Of: odoo/odoo#255102
This update ensures that users are warned before performing a full synchronization of products within the Point of Sale system. Previously, a 'Full' sync could overwhelm the system with a large number of products, leading to performance issues. Now, the system checks against a configured limit to prevent this, ensuring a smoother and more reliable POS experience.
Original PR description
When the user selects "Full" in the SyncPopup, the system now checks the total number of PoS-available products against the configured `point_of_sale.limited_product_count` system parameter before proceeding. opw-5484051 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#243763
This update resolves an issue where users couldn't add reactions to messages using the 'mail.group' model. The fix ensures that the 'add reaction' button is only displayed for message types that properly support reactions, improving stability and preventing errors.
Original PR description
*= im_livechat, portal, test_discuss_full **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` •…
*= im_livechat, portal, test_discuss_full **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. https://github.com/odoo/odoo/blob/d12c1e07727f9b04cd2be2e7dac1ec3af49cb637/addons/mail/models/mail_message.py#L579 Desired behavior after PR is merged: This PR fixes the issue by hiding the "add reaction" button on messages with models that don’t inherit from mail.thread, such as mail.group. enterprise: https://github.com/odoo/enterprise/pull/111271 Task-5098050 [Reference](https://github.com/user-attachments/assets/aa2c4251-fd1f-4734-a62c-9fc80dd5f587) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255950 Forward-Port-Of: odoo/odoo#218615
This update fixes an issue where downpayment accounts weren't correctly linked between POS invoices and sales order invoices. The fix ensures that the correct account ID is used when generating invoices, preventing discrepancies in payment tracking. This improves the accuracy of financial reporting and simplifies reconciliation.
Original PR description
[Issue] 1) When a POS downpayment is created, it doesn't set the account.move.lines.is_downpayment = true. So, no POS invoice line was being marked as a down payment. 2) When preparing to create the…
[Issue] 1) When a POS downpayment is created, it doesn't set the account.move.lines.is_downpayment = true. So, no POS invoice line was being marked as a down payment. 2) When preparing to create the invoice lines for the sales order, it never checks the original POS Invoice lines for down payments. [Fix] 1) When creating the invoice lines for the down payment through the POS, set the 'is_downpayment' based on if the product is the POS's down payment product. 2) Create _prepare_invoice_lin,e then filter through the POS invoice lines for downpayments and then set them accordingly. Steps to Replicate: 1) User creates a Sales Order for a customer, 2) Transfers it to the POS, and the customer makes a down payment. 3) The user creates an invoice on the Sales order to pay the remainder of the bill 4) The account Id on the account.move.line does not match the original account on the POS invoice for the original account.move.line Video Demo of the issue: https://drive.google.com/file/d/1FszCJRUF-cCgg8otxu1jj1kmdKauwTGL/view?usp=drive_link Video Demo of Solution: https://drive.google.com/file/d/1yrYBdQZFw7YeKxsgsQQx5gHkuGER-7BN/view?usp=drive_link Forward-Port-Of: odoo/odoo#249180
This update ensures that the 'mail.catchall.domain.allowed' system parameter is properly sanitized when created manually. Previously, a space character introduced an error, preventing valid domain entries from being used correctly. This fix resolves a potential issue where users couldn't configure catch-all domains as intended, improving mail 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#255969 Forward-Port-Of: odoo/odoo#244279
This update resolves an issue where Odoo could crash if a module didn't include a manifest file. The system now handles this gracefully, ensuring that lazy-loaded bundles are generated as reliably as possible. This improves overall system stability and prevents unexpected errors.
Original PR description
This commit avoids a crash when a module doesn't provide a manifest (cf. Industry). Pregenerating lazy loaded bundles is a "best effort" detection and should be resilient so, not a big deal if some aren't properly found. Forward-Port-Of: odoo/odoo#256056
This update resolves an issue where a key function was incorrectly imported, causing a minor disruption in the IoT drivers module. The fix ensures the function is correctly located within the intended module, improving overall system stability and performance. This change was necessary to maintain the proper functionality of the IoT drivers.
Original PR description
`get_conf` was moved to `system` instead of `helpers`, and a call in `main.py` hasn't been updated in a fw port. This commit fixes it. Forward-Port-Of: odoo/odoo#256049