Daily updates from Odoo
Wednesday, March 18, 2026
67 changes · master
New functionality added to Odoo
This update introduces a new report for French businesses, specifically the '2033-B Simplified P&L' (Compte de résultat simplifié) and Liasse fiscale, aligning with French tax regulations. This addition enhances Odoo Enterprise's reporting capabilities for French users, simplifying their financial reporting obligations.
Original PR description
This commit adds the Liasse fiscale, 2033-B Compte de résultat simplifié, report And fix a typo in the base report Task 5417358
This update introduces a new report for Polish businesses that still need to generate JPK_FA XML reports even when using the KSeF online invoicing system. This report ensures compliance with Polish tax regulations by listing invoices and lines not yet validated by KSeF, aligning with JPK-FA(4) standards.
Original PR description
In Poland, if a business chooses to keep B2C invoicing outside of KSeF (online platform), the JPK_FA obligation remains. It is a XML report that lists all the invoices and the invoice lines that have not been validated by KSeF during a desired period of time. The report follows the JPK-FA(4) norms. task-5166047 Forward-Port-Of: odoo/enterprise#103000
This update enables direct electronic invoicing for POS sales and returns in Colombia, streamlining the process for businesses. It adapts existing DIAN EDI functionality to work with POS data, reducing manual steps and improving efficiency. A key feature is sharing a single DIAN sequence, optimizing costs for businesses.
Original PR description
In Colombia, all POS Sales/Returns must be supported by an Electronic Document. Currently, the only way to connect the DIAN EDI and POS flows is to manage invoices directly in the Accounting App.…
In Colombia, all POS Sales/Returns must be supported by an Electronic Document. Currently, the only way to connect the DIAN EDI and POS flows is to manage invoices directly in the Accounting App. This pr adds the possibility to generate and send the electronic documents directly to DIAN without leaving the POS store. This pr will not create intermediate invoices/credit notes that are supposed to be sent to DIAN, instead we adapted the already existing ubl-generation implementation (in `l10n_co_dian`) to be able to generate the correct files using data from `pos.order` models (implementation can be found in `models/account_edi_xml_ubl_dian.py`). During this process we created some 'common' functions that generate data for the ubl file independent of what model is used (`account.move` or `pos.order`), these common functions are a first step for the future refactoring of the ubl models. An important thing to note here is that the common functions are only used for the pos orders, generating documents for invoices is still done using the original implementation. Another important feature of this implementation is the possibility to share a single sequence, defined on the journal, between pos orders and account moves. This was implemented because in Colombia (and other latam countries) the sequence gets assigned to a company by the government, and can therefore be expensive. Important to note is that sharing a sequence is only possible if the company has never sent documents to DIAN before (~ no existing edi documents). task-4038651 Forward-Port-Of: odoo/enterprise#78742
This update introduces a new wage type option within Odoo's payroll system, allowing businesses to calculate and pay employees based on a daily wage rate. This expands payroll flexibility to accommodate various employment models and ensures accurate compensation calculations for daily workers. The change impacts multiple international payroll modules.
Original PR description
Task: 5852568
Enhancements to existing features
This update introduces a mechanism for generating random serial numbers within Odoo's testing environment. This simplifies test creation and ensures more consistent and reliable test results across various modules. It primarily benefits the development and QA teams by streamlining the testing process.
Original PR description
odoo/odoo#248661
This update brings the Balance Sheet and Profit & Loss reports for Chinese businesses in line with the latest accounting standards (ASBE and ASSBE). The changes improve report consistency and accuracy, ensuring compliance and reliable financial reporting.
Original PR description
### [IMP] l10n_cn_reports: update BS & PnL We update the Balance Sheet and Profit & Loss reports to be consistent with updated ASBE and ASSBE standards odoo-[251681](https://github.com/odoo/odoo/pull/251681) task-[5939988](https://www.odoo.com/odoo/all-tasks/5939988) --- We encountered an issue where setting `groupby = False` still resulted in an error (no groupby and children lines). This was resolved by setting a co-dependent variable `user_groupby = False`. The reports has lines with "Includes:" and sibling lines' name are expected to be aligned with it. Hierarchy lines and using various space characters (CJK space `　`, and "en" space ` `) was a maintenance nightmare. We instead chose to remove `includes:` as it's implied by the natural indentation of grouped lines. Forward-Port-Of: odoo/enterprise#109175
This update enhances the way salary rules are displayed in the Odoo system. By dynamically adjusting the presentation of default values, the list view is now cleaner and easier to read, improving usability for HR staff. This change streamlines the process of configuring and managing salary rules.
Original PR description
This commit refactors the way input default values are shown in the Salary Rule configuration to support dynamic data types and improves the readability of the rule selector list view. Changes: List View Improvements: Added a computed field input_default_display to hr.salary.rule. This field dynamically returns the correct default value string based onnthe input_unit (Text, Selection, or Checkbox), ensuring the List View displays a single, populated column instead of multiple sparse columns. Dynamic Selection Options: task-5357904
This update enhances the rental order empty screen with animated GIFs, mirroring the design of the subscription screen. The GIFs are tailored for both dark and light mode, providing a more visually consistent and engaging experience for users. This improves the overall user interface.
Original PR description
We've added an animated gif to the rental order's empty screen. Loosely based on the pre-existing empty screen image in subscription, dark and light mode each have their own gif to reflect the ui colors. task-5699500
This update allows users to record the reason for a subscription's end date when scheduling it, eliminating the previous requirement to reopen the subscription. Previously, closure reasons were often missed, leading to incomplete records. This change ensures accurate tracking of subscription terminations.
Original PR description
Previously, users had to reopen a subscription to add a close reason after its end date was already scheduled. As a result, many scheduled closures were missing a recorded reason. This improvement allows users to specify a close reason directly when scheduling the subscription’s end date. task-5356573
This update significantly enhances the map view by automating route calculations using the latest technology, providing a more efficient way to plan routes. It also cleans up the pin list UI, isolating unlocated records and improving the overall user experience. This streamlines operations for users relying on map-based data.
Original PR description
*: planning_field_service, project_enterprise, stock_fleet_enterprise, web_studio This commit acts as a follow-up to https://github.com/odoo/enterprise/pull/104618, heavily improving the map view's…
*: planning_field_service, project_enterprise, stock_fleet_enterprise, web_studio This commit acts as a follow-up to https://github.com/odoo/enterprise/pull/104618, heavily improving the map view's routing capabilities and pin list UI: **Routing & Optimization:** * **Automated Routing:** Manual record resequencing has been completely removed. Routing now utilizes the Mapbox Optimization API to automatically calculate the most efficient point-to-point route, including a return to the starting point. * **Dynamic Starting Point:** Added a new input for the starting (and returning) address. It uses the Mapbox or OpenStreetMap API for autocomplete and coordinate fetching. It defaults to the user's location (if available) or falls back to the active company's address. A toggler allows users to quickly reset to their location or clear the input. **Pin List & UI Improvements:** * **Unlocated Records:** Records without coordinates are now isolated in a dedicated group and can be clicked to open their form view directly. * **Empty Groups:** Groups containing only unlocated records are no longer displayed in the pin list to reduce clutter. * **Formatting:** The route duration tooltip now uses the latest duration formatter for a cleaner display. task-5930464
This update enhances the payrun review process by introducing a new warning dialog to highlight unreviewed employee records and pending time-offs. This allows HR staff to proactively address these items, ensuring accurate payroll processing and compliance. The change also includes translations for improved usability.
Original PR description
Task: 5965128
This update enhances the visual clarity of the document search panel by adding more spacing. This improves the user experience and makes it easier to find documents within the system. The change is a visual improvement focused on usability.
Original PR description
Before this PR, the search panel was not optimal visually. It is now given more spacing to optimize visual appearance and clearness. Com PR: https://github.com/odoo/odoo/pull/229305 task-5008305 | | Before | After | |--------|--------|--------| | **Documents** | <img width="235" height="486" alt="Screenshot 2026-01-21 at 12 55 46" src="https://github.com/user-attachments/assets/9d6b8597-7a70-4e42-ae2a-69808cfcd4fa" /> | <img width="235" height="486" alt="Screenshot 2026-01-21 at 12 56 04" src="https://github.com/user-attachments/assets/c8bdfe35-c2d5-4701-9971-806b984e9216" /> |
This update enhances the Ask Feedback form by adding a widget that prompts employees to provide their email address. Previously, a warning message appeared if an employee didn't have an email, creating a friction point in the feedback process. This change ensures all feedback requests include necessary contact information.
Original PR description
-Originally, a warning appears in the ask feedback form when the employee doesn't have an email. -A widget has been added to request an email in the ask feedback form.
This update modernizes the core Odoo ORM, streamlining how data is combined and processed. This change improves the speed and efficiency of various Odoo modules, particularly those related to reporting and data aggregation. The update ensures Odoo continues to perform optimally with evolving data structures.
Original PR description
https://github.com/odoo/odoo/pull/249731
This update automatically populates Partena codes for common work entry types in Odoo, streamlining the payroll setup process for Belgian companies. Previously, users had to manually enter these codes, leading to inefficiencies and potential errors. This change simplifies compliance and reduces administrative burden.
Original PR description
Problem --------- Work entry types for Belgian companies currently lack default Partena codes, forcing users to manually input them, which is inefficient and prone to errors. Objective ---------- Provide pre-configured Partena codes for both common and Belgium-specific work entry types to automate the setup process. Solution ---------- Identified the required records and mapped our internal work entry types to the official Partena documentation, populating the 'Partena code' field with these default values. task-5411465
Resolved issues and error corrections
This update resolves several issues within the timesheet grid component, primarily focusing on the systray interface. Key improvements include fixing display errors, enhancing usability with expanded descriptions and clearer labels, and streamlining the user experience for time entry and record management.
Original PR description
Task-5956044 Forward-Port-Of: odoo/enterprise#109651
This update resolves issues with the formatting and data within Dutch SBR and ICP reports. Specifically, VAT information is now correctly formatted, and the XML output is cleaned for improved readability. This ensures accurate reporting for Dutch tax compliance.
Original PR description
Descriptions of the issues this commit addresses: The xbrli:identifier tags in the exported sbr and sbr icp files are wrong. They should always contain the company's vat without country code . The DateTimeCreation tag currently shows a date in a wrong format. It it YYYYMMDDhhmm but should be YYYY-MM-DDThh:mm:ss. Also the outputted xml is weirdly indented with many whitespaces and it makes it hard to read for no reason. --- Desired behavior after the commit is merged: This commit changes the values in the exported file to address those issues and adds the use of a cleanup helper to make the file human readable. --- task-5998939 Forward-Port-Of: odoo/enterprise#109359
This update resolves an issue where the Point of Sale system in Mexico incorrectly flagged invoices as invalid when the customer was missing a ZIP code or country. The fix ensures the 'Invoice to Public' setting is correctly transmitted to the ORM, preventing the error and allowing users to properly set invoices to public status.
Original PR description
## Issue In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer is missing a recognized ZIP code or country, setting the…
## Issue
In the POS of a Mexican company, when requesting an invoice, the user is asked to set the invoice to public or not. If the customer is missing a recognized ZIP code or country, setting the invoice to public **should not** raise an error, but it does. This is because the `l10n_mx_edi_cfdi_to_public` field is not correctly updated in the ORM, which leads to the UserError below being triggered, as `l10n_mx_edi_cfdi_to_public` is always set to `False` if it's not updated by its `_compute` method.
https://github.com/odoo/enterprise/blob/dd89c2c72039c9910cc0a303bca332f4103c08f6/l10n_mx_edi/models/account_move_send.py#L54-L55
## Cause
The said field is not properly updated because it is a *compute field*. Such fields are not transferred to the ORM because of the two following conditions from the POS:
1. https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L205-L206
2. https://github.com/odoo/odoo/blob/5c2280d089f248dff67df980bee1ce6a4156f2c9/addons/point_of_sale/static/src/app/models/related_models.js#L895-L896
## Solution
To minimize behavioral changes, the required field (`l10n_mx_edi_cfdi_to_public`) is simply added at the end of the
serialization process.
Once this field is correctly shared with the ORM, the UserError is not longer raised when the *Invoice to Public* field is set to "Yes" in the POS.
## Versions >= 19.1
Since https://github.com/odoo/odoo/pull/216523, the error would only be displayed **after** moving onto the FeedbackScreen. Since then, the validation is only computed after moving the POS to the next screen.
**To correctly prevent the user from confirming an order with invalid data, we now check the constraints everytime the customer or the invoicing method is updated:**
- If a customer is selected, trying to set *"Invoice to public"* to *"No"*
will raise an error if the user does not have a ZIP code and a country set.
- If *"Invoice to public"* is set to *"No"*, trying to remove the current
customer or select a customer with a missing ZIP code or country will raise an error.
## Steps to reproduce the initial error:
1. Install the following app and module:
- Point of Sale (`point_of_sale`)
- Mexican Localization for the Point of Sale (`l10n_mx_edi_pos`)
2. Set the company to a Mexican one (e.g., *ESCUELA KEMPER URGATE*)
3. Open the POS app
4. Open a register
5. Select a product and click *Add*
6. Click *Payment*
7. Set the Customer to a new customer with only a name
(no Country/ZIP Code)
- Click "Cash" to set the Remaining to 0
8. Toggle the *Invoice* button, set the *Invoice to Public* to *"Yes"* and click *Ok*
9. Click *Validate*.
10. An error *"Invalid Operation, CFDI not set to Public"* appears.
opw-5171035
Forward-Port-Of: odoo/enterprise#101365
Forward-Port-Of: odoo/enterprise#99871This pull request reverts a recent change that was causing issues with email notifications related to contract salaries within the Enterprise module. The change was rolled back to restore the previous, stable functionality. This ensures that salary-related communications are delivered correctly.
Original PR description
Revert https://github.com/odoo/enterprise/pull/106974 Forward-Port-Of: odoo/enterprise#110767
This update resolves a bug preventing tours from correctly switching shifts within the Odoo Enterprise planning calendar. The issue stemmed from a misunderstanding of how the 'Edit' button was being handled, and the fix removes unnecessary checks. This ensures all tours function as expected.
Original PR description
The tour was working with `planning_field_service_sale_timesheet` but not `planning_field_service` only. The reason is that 'newButtons' did not contains any element, so the 'Edit' button logic was not altered to redirect to the form view on click as wanted. We do not need to do the check on 'newButtons' to allow that. runbot-error: https://runbot.odoo.com/odoo/runbot.build.error/241950 Forward-Port-Of: odoo/enterprise#110937
This update fixes a discrepancy in the Indian salary configurator, ensuring the default basic salary percentage is 50% instead of 60%. Benefit updates now correctly impact gross salary and employer costs without altering employee wages or the payroll structure. This ensures accurate payroll calculations for Indian employees.
Original PR description
- Fix the default Indian basic salary percentage to 50% instead of 60%. - Ensure benefit amounts are treated as additional employer payments and do not rebalance the employee’s wage or basic salary in the salary configurator. After this change, benefit updates only impact gross salary and employer cost, while the wage remain unchanged. task-[5501683](https://www.odoo.com/odoo/project/1251/tasks/5501683) Forward-Port-Of: odoo/enterprise#108055
This update resolves a failing test within the Odoo Enterprise platform, specifically concerning how orders are processed. The system now requires a kitchen printer, but the test environment lacks this setup, causing errors. This fix ensures the test runs correctly and prevents potential issues during order processing.
Original PR description
This commit fixes the failing `test_platform_order_flow` test, specifically within the `test_platform_order_reject_flow` tour at the `.ticket-screen` step. Explanation: The root cause of this issue is that the system is now expecting a kitchen printer to be present to process the order flow. However, the unit test environment does not have a kitchen printer configured, which causes the flow to halt or behave unexpectedly when the system tries to interact with it. Reference: Breaking PR: odoo/odoo#226447 build_error-241246 Forward-Port-Of: odoo/enterprise#110544 Forward-Port-Of: odoo/enterprise#110249
This update restores essential VAT checks within the Belgian tax reporting module, addressing previous issues that caused warnings during XML uploads to Intervat. A new check has been added to ensure returns only pass if all VAT validation warnings are cleared, improving data accuracy and compliance.
Original PR description
Since the implementation of returns, some VAT checks were no longer being executed. This led to warnings when uploading the XML to Intervat. To catch these issues beforehand, this commit: - Restores the warning checks directly on the report. - Adds a new check on the VAT return that passes only if no warnings are raised. task-5883037 Forward-Port-Of: odoo/enterprise#107152
This update corrects an issue where QR codes weren't consistently appearing on PDF invoices sent to customers in Peru. The change resolves a technical problem related to how attachments were linked during the invoice generation process, ensuring correct QR code inclusion. This improves the accuracy of customer invoices.
Original PR description
In [^1] we refactored Peru to use the send and print api instead of account_edi. One issue that was missed is in the case of sending the pdf to the customer in the same call as sending to SUNAT. Since the field that is storing the attachment (`l10n_pe_edi_attachment_id`) is linked to `l10n_pe_edi_attachment_file` via the compute, creating the attachment with a link to the res_field doesn't update within the transaction so `l10n_pe_edi_attachment_id` is still false at the time of PDF generation. There are two fixes, we can either invalidate the recordset at time of computation to make sure that it is truthy in the transaction, or use the `l10n_pe_edi_attachment_file` directly as it means we don't need to access the data field on `ir.attachment`. The use of the `l10n_pe_edi_attachment_file` field seemed cleaner. task-none [^1]: #97593 Forward-Port-Of: odoo/enterprise#110885
This update fixes a technical issue related to how marketing emails are generated. The system now correctly determines if an email body is required based on the email content, ensuring consistent email formatting. This improves the reliability of marketing campaigns.
Original PR description
Prior to this commit, `body_html` was hard-coded as a dependency of the `mass_mailing_html_field`, and that dependency lacked the `required` attribute, which should depend on the value of `body_arch`. The dependency is now added in the related views, and the field is now generic. As HtmlField now mark the record `dirty` `onChange`, some tours should ensure that the form view is properly discarded before finishing. task-5976348 Forward-Port-Of: odoo/enterprise#110643 Forward-Port-Of: odoo/enterprise#109091
This update fixes an issue where reporting queries were using outdated currency rates, leading to inaccurate financial reports. The change ensures that the correct, same-day currency rate is used in all CTA queries, improving the reliability and accuracy of financial data. This impacts the trial balance and other account reports.
Original PR description
We use currency rate at day x - 1 to be applicable at a date x, which shouldn't be applicable in the cta queries. Use same-day rate for the CTA query. task-5969168 Forward-Port-Of: odoo/enterprise#108879
This update fixes a technical issue in the demo certificate used for Peru's electronic invoicing (PE) system. The original certificate's lifespan was shortened, causing testing problems. This change extends the certificate's validity by ten years, ensuring accurate testing and demonstration of the feature.
Original PR description
In runbot's faketime tests, the test 1 year in the future goes past the end date of the demo PE certificate which had a lifetime of 2017-02-25 to 2027-02-25. This commit replaces that with one that lasts another ten years (2026-03-13 to 2036-03-13). runbot-241058 Forward-Port-Of: odoo/enterprise#110719
This update fixes a limitation in the Odoo Enterprise system by enabling users to select 'Other Expenses' as a valid account type when creating loan expense records. Previously, this option was restricted, which created an inconvenience for users tracking certain types of loan-related costs. This change improves flexibility and accuracy in expense reporting.
Original PR description
Allow accounts with the "Other Expenses" type to be selected in the Expense Account field of Loans. task-5946452 Forward-Port-Of: odoo/enterprise#110085
This update ensures shift emails are automatically sent to employees in their preferred language, regardless of the user's settings. Previously, emails defaulted to the current user's language, causing confusion. This change improves communication and user experience for international teams.
Original PR description
Steps to reproduce: ------------------------- 1. Install Planning and Contacts. 2. Install any language other than English (e.g., Arabic). 3. Change an employee's contact language to that language.…
Steps to reproduce: ------------------------- 1. Install Planning and Contacts. 2. Install any language other than English (e.g., Arabic). 3. Change an employee's contact language to that language. 4. Create a shift for that employee and click "Send". 5. Check the message in Settings > Technical > Discuss > Messages. Issue: --------- The email is sent in the language of the current user rather than the language of the employee receiving the shift. Cause: --------- The mail template rendering logic ([_render_lang](https://github.com/odoo/odoo/blob/0dbfa8b99d5c28a7d84e781a7f23b226fd964e95/addons/mail/models/mail_render_mixin.py#L549-L566)) fails to determine a valid language on the planning slot record because it is not directly linked to a `partner_id`. As a result, it falls back to the current user's language. Solution: ------------ Explicitly pass the employee partner's language in the mail context so that the email is sent in the correct language. opw-5928676 Forward-Port-Of: odoo/enterprise#110778 Forward-Port-Of: odoo/enterprise#109619
This update resolves a technical issue that was causing test failures in the Point of Sale preparation display module. The trigger that reacted to spinning icons (fa-spin) has been removed, as the system already handles synchronization delays effectively. This ensures smoother and more reliable operation of the POS preparation process.
Original PR description
In this commit: = - Removed the trigger that checks for `fa-spin` as it was causing test failures when minor delays occurred between steps. - Checks for `fa-spin(Sync)` is alredy handled by the `isSynced` or `waitRequest`. Runbot-error: [198580](https://runbot.odoo.com/odoo/error/198580), [234025](https://runbot.odoo.com/odoo/error/234025) Forward-Port-Of: odoo/enterprise#87281
This update ensures that new files created in the Odoo Enterprise system correctly identify their file type (MIME type). This fix addresses a compatibility issue with older versions of Chrome, aligning with current web standards and improving the system's ability to handle file uploads properly.
Original PR description
The `type` option passed to the `File` constructor should be a string representing the MIME type of the content that will be put into the file. Chrome 146 actually follows the Fetch Standard and preserve the data URL MIME type parameter. This commit fixes the malformed MIME types passed to the `File` constructor to ensure proper compatibility with pre/post Chrome version 146 (and actually follow the spec). References: - https://chromestatus.com/feature/4874471565557760 - https://developer.mozilla.org/en-US/docs/Web/API/File/File#type runbot-241901 Forward-Port-Of: odoo/enterprise#110812 Forward-Port-Of: odoo/enterprise#110496
This update ensures the title of the embedded account report within the annual report correctly reflects the user's selected language. Previously, the report title remained in English regardless of the user interface language setting. This change improves the user experience by providing localized content.
Original PR description
### Issue before this commit: When generating the annual report, the title of the embedded account report displayed in the table of contents remained in English even when the user interface language was changed. ### Steps to reproduce the issue: 1. Install another language than english and switch to that one 2. Install Accounting app and audit modules 3. Go to Accounting > Revision > Annual Report 4. Create an Annual Report and click on it 5. Index is in the correct language but the title inside is not ### Cause of the issue: The issue occurred because the name property passed to the AccountReportComponent was not translated. Reason to introduce the fix: To translate the embedded account report title according to the user’s current language. opw-5958383 Forward-Port-Of: odoo/enterprise#109962
This update fixes a potential issue where new records in several Odoo modules (including account, helpdesk, and project) could inadvertently reuse previously deleted IDs. The change ensures each new record gets a unique ID, improving data integrity and preventing errors. Updated tests confirm this fix.
Original PR description
\* documents_spreadsheet, helpdesk, planning, project_enterprise, sale_planning, spreadsheet_edition, web_cohort, web_gantt, web_grid Previously, new record IDs were generated using the maximum existing ID. If the last record was deleted, newly created records could reuse the same ID. This change stores the last generated ID on the model and uses it to generate new records, ensuring uniqueness. Related tests were updated to match the new behavior. Community: https://github.com/odoo/odoo/pull/250661
This update ensures that quality checks are only performed on tracked products when a lot or serial number is assigned. Previously, users could initiate quality checks without this information, leading to an error message prompting assignment. Additionally, the quality check display now intelligently filters checks based on whether any moves have been picked.
Original PR description
This commit fixes the behavior when the user tries to do quality checks for tracked products without setting their lot/sn on the picking. Before this commit: Nothing happens if the user tries to do quality checks if lots are not set on the tracked products. After this commit: A User Error is raised telling the user to assign lots/sn to the tracked products. Additional improvement: Before this commit, when having quality checks and user click on `Quality Checks` button, all quality checks appear regardless of whether all moves are picked or only some of them are picked. After this commit, clicking on `Quality Checks` button will only show quality checks related to picked move lines if at least one move line is picked, otherwise it will show all quality checks. Task-5730239 Forward-Port-Of: odoo/enterprise#110697 Forward-Port-Of: odoo/enterprise#104945
This update resolves an issue where default values for selection-type salary inputs weren't being correctly applied when first added to a payslip. The fix ensures that these default values are consistently displayed, improving the accuracy of payroll calculations. This change impacts the way salary inputs are configured.
Original PR description
Steps to reproduce: - Create a Salary Input of type 'selection'. - Assign a default value to this input. - Add the input to a payslip. Bug Cause: The form view is not re-comupting the values when it's assigned for the first time since the container is not changed Solution: Forcefully update the payroll_properties when we add new inputs in the payslip form task-5357904 Forward-Port-Of: odoo/enterprise#106469
This update resolves a technical issue causing a warning message related to how boolean fields were displayed. Additionally, outdated tour actions related to work entries have been removed, streamlining the user experience. This ensures correct overtime ruleset presentation.
Original PR description
Remove legacy widget="checkbox" usages that triggered the "Missing widget: checkbox" console warning; boolean fields now use the default boolean widget rendering. Also, removed tour actions related to the "Work Entries" removed in last version. task-5945764 Forward-Port-Of: odoo/enterprise#110777
This update reverses a previous change related to employee benefits, specifically the eco voucher. The change has been reverted to restore the standard payroll calculations. This ensures accurate and consistent payroll processing for employees using the Belgian HR payroll module.
Original PR description
Forward-Port-Of: odoo/enterprise#110515
This update resolves a technical problem with the validation schema used in the account reports and sign modules. The fix ensures that these components function correctly, preventing potential errors and improving data reliability. This change ensures smooth operation of key reporting and signature processes.
Original PR description
This commit corrects wrong props validation schema that could not work.
This update fixes a problem causing incorrect stock synchronization for Amazon listings, leading to phantom orders. The fix allows users to manually specify the fulfillment channel (FBA or FBM) for listings, resolving a known 'ghost listing' issue. This ensures accurate stock management and order fulfillment.
Original PR description
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and…
When configuring a listing on Amazon Seller Central, the user must choose **one** of the available fulfillment channels that Amazon offers. We distinguish two kinds: Fulfillment by Amazon (FBA) and Fulfillment by Merchant (FBM). However, Amazon suffers from a known issue of ghost listings. A ghost listing occurs when an offer is presumably sold via FBA, but in fact stores stock information for both FBM and FBA creating unwanted FBM orders. To avoid ghost listings, the first solution was to disable stock synchronization as soon as an offer contained stock in the Amazon location of Odoo. However, if a merchant decided to change the fulfillment channel, it became impossible to sync the stock anymore. See also e7c01c7097d90e731c5408cee4d3595ed810c8fa. To resolve this issue, we decided to use the Amazon API to fetch information about the fulfillment channel of a listing. However, Amazon doesn't give a clear answer for a given listing. Therefore, after some research, the assumption was that an offer was FBM if the listing contained a `merchant_shipping_group`, as the merchant shipping group is a setting specific to FBM listings. See also e6d620e4b200cadabb00ce37ab03289cfeb4ae58. However, this assumption was flawed because Amazon can keep the shipping group even if the listing switches to FBA. This in turn enabled stock synchronization, leading to ghost listings. To fix this issue we give the possibility to users to manually set the correct fulfillment channel of an offer when it becomes ambiguous. opw-5480254 See also: - https://github.com/odoo/upgrade/pull/9692 Forward-Port-Of: odoo/enterprise#106662
This update fixes an issue where salary-related fields within the HR Contract Salary configuration weren't being updated correctly. The change ensures that all relevant settings are accurately reflected after configuration adjustments, improving data consistency and accuracy for payroll and contract management.
Original PR description
Forward-Port-Of: odoo/enterprise#110950
This update fixes an issue where the auto-focus feature for the country selector in the VoIP keypad stopped working in version 19.2. The fix ensures the selector automatically receives focus when opened, improving user experience. This resolves a minor usability problem.
Original PR description
Commit [1] introduced the country selector on the VoIP keypad, for saas-19.1. However, for saas-19.2, the auto-focus of the country search input once the country selector dropdown is opened was…
Commit [1] introduced the country selector on the VoIP keypad, for saas-19.1. However, for saas-19.2, the auto-focus of the country search input once the country selector dropdown is opened was broken. This is because of [2] which trapped the focus inside the softphone to improve various keyboard behaviors... but the country selector is considered to be outside of the country selector as it is a dropdown, which broke the auto-focus. We now trap the focus inside the country selector once it opens, the same way [2] traps the focus inside the softphone once it opens. Doing that, using `useAutofocus` becomes actually useless as the input is the first focusable element of the dropdown and will thus automatically be focused when the menu becomes the active element. Also, the auto-focus introduced by [1] was not working on mobile. This commit changes that but does not consider that to be a bug so this still target 19.2+. Note: a tour already existed and wanted to check that feature works but it was not properly written. This commit adds a unit test about this only too, and for the mobile usecase. [1]: https://github.com/odoo/enterprise/commit/708aea78760392207f9148c31c67212dacaf3294 [2]: https://github.com/odoo/enterprise/commit/df1772e877a508150fd3f549526dec9d867354be task-5999452 Forward-Port-Of: odoo/enterprise#109871
This update corrects a technical issue preventing the installation of the Planning module when the 'planning_holidays' module was enabled. The fix involves reverting a recent change to the view structure, ensuring compatibility between the module's targeting of a specific HTML element and the underlying database structure. This resolves an installation error and allows the Planning module to function correctly.
Original PR description
**Steps to Reproduce:** - Revert the commit 2ff35d598346798bd00fd40687e0e214c0190c1f. - Install the Planning module. - Restore the original commit - Install 'planning_holidays' module. **Error:** ```…
**Steps to Reproduce:**
- Revert the commit 2ff35d598346798bd00fd40687e0e214c0190c1f.
- Install the Planning module.
- Restore the original commit
- Install 'planning_holidays' module.
**Error:**
```
ParseError: while parsing /home/odoo/src/enterprise/saas-19.2/planning_holidays/views/planning_slot_views.xml:26, somewhere inside <record id="planning_view_kanban_inherit_planning_holidays" model="ir.ui.view">
<field name="name">planning.slot.kanban</field>
<field name="model">planning.slot</field>
<field name="inherit_id" ref="planning.planning_view_kanban_inherit"/>
<field name="arch" type="xml">
<xpath expr="//span[@t-if='record.overlap_slot_count.raw_value']" position="after">
<field name="leave_warning" class="text-danger mb-2"/>
</xpath>
</field>
</record>
```
**Cause:**
The `planning_holidays` module targets a `<span>` element in its XPath, while the `overlap_slot_count` element is located in a `<p>` in the planning module. Since view changes in stable do not update already-installed databases, the old XPath cannot be found, and a ParseError is raised during module installation.
**Fix:**
Revert the changes in stable to restore the original view.
sentry-7338367664
Forward-Port-Of: odoo/enterprise#110826This update corrects a bug in the accounting module that occurred when multiple reconciled lines were present. The fix ensures the system handles reconciliation correctly, preventing errors when users manually reconcile multiple transactions. This improves the stability and reliability of the accounting process.
Original PR description
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with…
**Steps to reproduce:** - Install Accounting - From a Bank journal, create a transaction with an amount of -1000 - Set Account to "Liquidity Transfer" - From a Cash journal, create a transaction with an amount of 999.99 - Set Account to "Liquidity Transfer" - Create a MISC entry: | Account | Debit | Credit | | -------------------- | ----- | ------ | | Liquidity Transfer | 0.00 | 0.01 | | Cash Difference Gain | 0.01 | 0.00 | - Post the entry - From Journal Items list, group by Account, select the 3 lines on "Liquidity Transfer" account and reconcile them - Go back to the Bank journal and try to edit the previous transaction **Issue:** A traceback is raised. **Cause:** In "_compute_full_amount_switch_html" method, the reconciled lines linked the current line are retrieved. A single line is expected and some operations that are only allowed on a singleton are performed. In our case, the reconciliation has been performed manually and there are several reconciled lines ; which violates the singleton condition. **Solution:** The value computed by "_compute_full_amount_switch_html" has no sense if there's more than one reconciled line. Therefore, the computation can be skipped in such a case. opw-6031879 Forward-Port-Of: odoo/enterprise#110857
This update ensures all data files within the Odoo Enterprise system are encoded as UTF-8. Previously, some files used a different encoding, which could lead to display or processing errors. This change improves data integrity and reliability across various Odoo modules.
Original PR description
https://github.com/odoo/odoo/pull/254394
This update fixes a bug that prevented users from removing external members with edit access from spreadsheets after archiving. The fix updates validation logic to correctly handle rule additions and deletions, resolving three related warnings and ensuring proper spreadsheet access. This improves the user experience and data accuracy.
Original PR description
Problem: A bug occurs when an internal user with "Edit" rights to a spreadsheet is archived. Upon archiving, the user transitions to an external user, a state where "Edit" rights are strictly…
Problem: A bug occurs when an internal user with "Edit" rights to a spreadsheet is archived. Upon archiving, the user transitions to an external user, a state where "Edit" rights are strictly prohibited. However, due to a validation error in the access rights wizard, users were unable to fix this. Cause: The validation logic in `documents_sharing.py` performed checks after any action was taken. If an illegal configuration was detected, it set a flag to hide the Save button. Because the check did not distinguish between adding an illegal rule and deleting one, users were blocked from removing the very records causing the validation failure. Solution: The validation checks have been updated to account for the operation- type (addition or deletion). This ensures that while new illegal rules are still blocked, existing illegal rules can be successfully removed to restore the system to a valid state. A test was also added to prevent this problem form happening in the future. This PR applies uses the solution to fix the state of 3 warnings, ensuring they are only displayed when actually relevant. Specifically, it covers: - The warning triggered when removing external users with edit access in `documents_spreadsheets`. - The `has_warning_no_access` warning in documents. - The `has_warning_link_with_more_rights` warning. task-5902391 Forward-Port-Of: odoo/enterprise#110668 Forward-Port-Of: odoo/enterprise#108140
This update fixes an issue where barcode-created manufacturing orders incorrectly used product UoMs instead of the specified BoM UoMs. Now, MOs created through the barcode app accurately reflect the BoM's component quantities, ensuring correct inventory tracking. This resolves a previous traceback and improves order accuracy.
Original PR description
Previous behaviour: * Traceback if MO created with a BoM whose lines have UoMs that don't correspond to those of the products, then UoM setting disabled and MO viewed in the barcode app. * BoM line UoMs ignored in favour of product UoMs when creating MO in the barcode app. New behaviour: * No traceback. * Stock moves in MOs properly created with the corresponding BoM line UoMs. Task ID: [4674196](https://www.odoo.com/odoo/my-tasks/4674196) Forward-Port-Of: odoo/enterprise#110740 Forward-Port-Of: odoo/enterprise#90408
This update corrects a bug in the DIAN invoice processing workflow that was causing original invoices to be accidentally deleted. The previous logic incorrectly protected the oldest document, leading to the deletion of the current invoice. This fix ensures invoices are properly protected during the update process, preventing data loss.
Original PR description
**PROBLEM** In some configurations, `_l10n_co_dian_cron_update_event_status()` would delete the original document of the invoice. **CAUSE** The logic that tried to exclude the original document from the code that unlinks duplicated documents is wrong. It protect the oldest document of `self` instead of `move`. So the document of the move we are currently working on is not protected, and could be deleted. **STEP TO REPRODUCE** 1. Setup DIAN. 2. Create multiples invoices and send them to DIAN. 3. Run _l10n_co_dian_cron_update_event_status() If the original document of the invoice have the same commercial_status as some other document, it could be destroyed. opw-5447147 Forward-Port-Of: odoo/enterprise#110455
This update resolves an issue where users were unable to correctly set start and end dates simultaneously within the Web Studio interface. The fix prevents the system from accepting both date fields being populated at the same time, ensuring data integrity and preventing invalid date range fields. This improves the overall usability of Web Studio for creating and managing date-based records.
Original PR description
Steps to reproduce ================== - Install project,web_studio - Click on the three dots in the top right of a project - Click on settings - Open studio - Add a new date field - Set the start date field to Start date - Set the end date field to Expiration Date - Exit studio => The date range field is marked as invalid (red outline) Cause of the issue ================== https://github.com/odoo/odoo/blob/ee15163fe516817da277760752892ea76a699e22/addons/web/static/src/views/fields/datetime/datetime_field.js#L371-L373 We cannot set both the start and end field at the same time. opw-5403670 Forward-Port-Of: odoo/enterprise#110580 Forward-Port-Of: odoo/enterprise#108562
This update resolves an issue where timesheet descriptions were being duplicated when updating values in the grid view. The fix ensures that new timesheet lines created from updated values retain the original description, maintaining data accuracy and consistency for project tracking. This improves the reliability of timesheet reporting.
Original PR description
To reproduce: ============= - on timesheet group by Project > Task > Description - on a line with a description, update a 0:00 cell to an other value - refresh or change view to list and back to grid - a new line with description '/' is created with the updated value Problem: ======== when creating the new timesheet it's by default given the name '/' which for the grid view is not in same group as the original line with the description. Solution: ========= when creating the new timesheet, we give it the same description as the original line. opw-5909249 Forward-Port-Of: odoo/enterprise#110800 Forward-Port-Of: odoo/enterprise#108894
An error preventing users from downloading audit reports as PDFs has been resolved. This was caused by removing compatibility shims used in the PDF generation process. The update corrects a migration issue, allowing users to successfully export audit reports without encountering errors.
Original PR description
Currently, the user gets an error page when exporting an audit report to PDF. This occurs because the compatibility shims that converted the old PyPDF (1.x) syntax to the new API were recently removed, and one instruction in `accountant_knowledge` was incorrectly migrated.
Steps to reproduce:
1. Create an audit report
2. Open the audit report
3. In the Knowledge editor, click on the "More Actions" button
4. In the dropdown, click on "Download Annual Report"
=> The user gets an error and the following message is printed in the console:
```
File "/home/odoo/src/enterprise/accountant_knowledge/controller/main.py",
line 484, in export_article_to_pdf
page.merge_page(empty_pdf_for_page_numbers[k])
~~~~~~~~~~~~~~~~~~~~~~~~~~^^^
TypeError: 'PdfReader' object is not subscriptable
```
To fix the issue, we update the incorrect call so the user can export an audit report to PDF without errors.
Reference: odoo/enterprise#107138This update corrects a previous issue where overtime records weren't being properly processed when an employee had multiple overtime entries within a single interval. The change ensures accurate tracking of all overtime hours, leading to more reliable employee time reporting. This improves the accuracy of payroll and attendance data.
Original PR description
Overtime intervals can contain multiple overtime records. Iterate over each overtime in the interval instead of unpacking a single record. Task Id : 6014640
This update fixes an issue where orders created through the MPS weren't being grouped correctly into RFQs. The fix ensures that all related orders are combined into a single RFQ, improving order management and reporting. This resolves a discrepancy in RFQ listings.
Original PR description
Issue ----- Orders created through the MPS aren't grouped in a single RFQ. Steps to reproduce ----- - Create a product with a vendor - Add it to the MPS with the buy route - Change the forecast to 2…
Issue ----- Orders created through the MPS aren't grouped in a single RFQ. Steps to reproduce ----- - Create a product with a vendor - Add it to the MPS with the buy route - Change the forecast to 2 - Order - Change the forecast to 5 - Order - Go to RFQs > There are 2 different RFQs Cause ----- When doing `_run_buy`, no existing PO is found https://github.com/odoo/odoo/blob/98e3020bcffaf449291d1e6664ba613761f37331/addons/purchase_stock/models/stock_rule.py#L102 so a new one gets created. The reason why the existing PO is not found is because we add `date_planned_mps` to the search domain https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/stock_rule.py#L10-L15 However, `values['date_planned']` is a datetime.date, whereas `date_planned_mps` is a datetime.datetime in DB. https://github.com/odoo/enterprise/blob/42102423069c2cebbc01eb4d1d8f9b6215358639/mrp_mps/models/purchase_order.py#L10 This poses some problems with timezones, as the client and db dates might differ. We can avoid the problem by converting the date to datetime. ----- Ticket: opw-5171041 Forward-Port-Of: odoo/enterprise#110068 Forward-Port-Of: odoo/enterprise#106968
This update resolves an issue where website content wasn't loading correctly due to a recent framework change. The fix ensures that website content is retrieved accurately, improving the user experience and functionality of the website. This change is a technical update to ensure proper operation.
Original PR description
Since a change in the framework to lazy load attachments content, raw is a LocalBinaryfile object rather than the content of the attachment. Instead we need to do .content to fetch the actual content.
This update fixes a critical issue where AI chat failures resulted in confusing error messages for users. The changes now provide more user-friendly 'oops' messages for initial fetch failures and a clear 'Connection Interrupted' dialog for stream interruptions. It also ensures the AI spinner stops spinning when messages fail to post.
Original PR description
Steps to reproduce: 1. Open the Website Editor 2. Select some text 3. Click the AI tool from the toolbar 4. Send a message in the chat window 5. Observe a non-standard error dialog showing 500 HTTP…
Steps to reproduce:
1. Open the Website Editor
2. Select some text
3. Click the AI tool from the toolbar
4. Send a message in the chat window
5. Observe a non-standard error dialog showing 500 HTTP error
The AI chat was not properly handling server errors and connection
interruptions, causing unhandled exceptions to be thrown to the user.
This commit improves error handling for both public and internal AI chat
by:
- The generator function handles error, such that it still yields data
even in error.
- Simulate RPCError for both the fetch of the streaming endpoint and during
error when streaming (error data is converted to RPCError).
- Properly provide error handler for StreamInterruptedError.
- Use a dedicated cursor for the LLM agent loop, wrapped in try/finally. When
the loop crashes, a new cursor is opened in the finally block to persist the
last text response. This ensures the loop cursor can roll back DB updates from
already-executed tool calls without losing the response message.
The following behavior will now be observed during error in the UI.
- Public AI chat:
- Initial fetch failed: shows "oops" message
- Stream interrupted:
- Server handled: shows "oops" message
- Server stopped: shows "Connection Interrupted" dialog
- Internal AI chat:
- Initial fetch failed: show RPCError dialog
- Stream interrupted:
- Server handled: shows RPCError dialog
- Server stopped: shows "Connection Interrupted" dialog
We also include a fix in the livechat where the ai spinner never goes away
when posting of message failed.
TASK-ID: 5886825
Forward-Port-Of: odoo/enterprise#110478
Forward-Port-Of: odoo/enterprise#105875This update fixes a display issue with XML invoices received through Peppol. Previously, the preview page showed unnecessary raw HTML content. Now, thumbnails are correctly generated for these invoices, providing a cleaner and more user-friendly preview experience. This ensures users can easily access and view their invoices.
Original PR description
Before this commit: - The preview page of XML invoices received via Peppol was split into two parts: one showing the PDF preview, and another showing the plain HTML of the PDF viewer page - Thumbnail were not generated for these XML invoices After the commit: - The second part of the preview (Text part) was removed. As the users won't be interested to see the raw XML content of the invoice, neither the plain HTML of the pdf preview page. - Thumbnails now are correctly generated for the XML invoices. Notes: This fix is part of the bug-fix task to ensure users can correctly open XML invoices received via Peppol. task-5246989 --- I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr) Forward-Port-Of: odoo/enterprise#110481 Forward-Port-Of: odoo/enterprise#100137
This update corrects a reporting issue with NACHA payment files by prioritizing the actual bank account holder's name over the customer's name in Odoo. Using the correct account holder name ensures accurate reporting and compliance with NACHA standards. This change improves the reliability of payment processing.
Original PR description
The NACHA entry detail was using the partner's name (res.partner.name) for the Individual Name field. This should instead prioritize the Account Holder Name (acc_holder_name) from the bank account, as this reflects the actual name on the bank account which may differ from the partner's name in Odoo. The code now uses bank.acc_holder_name if set, and falls back to payment.partner_id.name if not set. Forward-Port-Of: odoo/enterprise#108804 Forward-Port-Of: odoo/enterprise#105582
This update fixes an issue where users were receiving blank PDF reports when attempting to print the planning report. The fix ensures the report data is correctly prepared before printing, guiding users to use the designated Print button for accurate report generation.
Original PR description
**Problem:** When users in debug mode manually add the planning report action through Settings/Technical/Reports and then print from the list or form view, they receive a blank/invalid PDF report.…
**Problem:** When users in debug mode manually add the planning report action through Settings/Technical/Reports and then print from the list or form view, they receive a blank/invalid PDF report. **Steps to reproduce:** 1. Go to Settings app and enable debug mode 2. Navigate to Technical → Reports 3. Search for "slot_report" 4. Click "Add to print menu" button 5. Refresh the browser 6. Go to Planning app and switch to list view 7. Select a few planning.slot records 8. Click Print → Planning **Current behavior:** A blank or invalid PDF is generated. **Expected behavior:** Users should receive a clear error message directing them to use the correct print method from the calendar view. **Cause of the issue:** The planning report requires a pre-processed data structure (weeks, grouped slots per day/week, and group-by mappings) that is only prepared by the action_print_plannings() method called from the custom Print button in the calendar view. The standard print menu invokes _render_qweb_pdf() directly without this data preparation, and there is no mechanism to pass this complex data structure through the standard print workflow. This results in the template receiving empty data contexts, producing blank reports. **Fix:** Block the planning report from being printed through _render_qweb_pdf() when called without the proper data context. This is done by checking if the report name is 'planning.slot_report' and raising a UserError with a clear message directing users to use the Print button in the calendar view instead. This prevents the generation of invalid reports while guiding users to the correct workflow that properly prepares the required data. opw-5477184 Forward-Port-Of: odoo/enterprise#108772 Forward-Port-Of: odoo/enterprise#105168
This update resolves an error that occurred when importing website configurations. The issue stemmed from an attempt to use a field defined in a separate module when that module wasn't installed. The fix ensures the necessary module is only loaded if required, preventing the error and allowing users to successfully import their websites.
Original PR description
This error occurs when attempting to import a website from the Website settings. Steps to reproduce: - Install `website` module - Website > Configurations > Settings > `Import Website` - `Website…
This error occurs when attempting to import a website from the Website settings. Steps to reproduce: - Install `website` module - Website > Configurations > Settings > `Import Website` - `Website URL`(eg: `https://iap-scraper.odoo.com/`) > `Import my website` Traceback: `ValueError: Invalid field 'ecommerce_platform' in 'website_generator.request'` The `ecommerce_platform` field is defined in the `website_generator_sale` module. However, when this module is not installed, we still add this field in vals/[data] from the `website_generator` module. Because of this, when importing a website, the `import_website` method is called and a `website_generator.request` [record] is created. Since the `website_generator_sale` module is not installed, the `ecommerce_platform` field does not exist on the `website_generator.request` model, which results in an error. Solution: We only install the `website_generator_sale` module if the `ecommerce_platform` and `import_products` fields is present in `kwargs`. [data]: https://github.com/odoo/enterprise/blob/288c7d9c1f29746e0abe0338801621c033a2280c/website_generator/static/src/client_actions/import_form/import_form.js#L228 [record]: https://github.com/odoo/enterprise/blob/288c7d9c1f29746e0abe0338801621c033a2280c/website_generator/models/website.py#L33 sentry-7324538798 Forward-Port-Of: odoo/enterprise#110286
This update resolves an issue where the batch view in the Enterprise module incorrectly displayed multiple 'Validate' buttons. The fix ensures that only one 'Validate' button is visible, streamlining the quality check process for users. This improves usability and prevents confusion.
Original PR description
Steps to reproduce: - Create two storable products: “P1” and “P2” - Create two pickings, one with P1 and another with P2 - Create a quality check for P1 - From the picking list view: - Select both pickings and create a batch - Open the batch Problem: Two “Validate” buttons are displayed instead of one. The inherited view was overriding the original `invisible` attributes of the two existing `action_done` buttons and also adding an extra `action_done` button. Because the original visibility logic was replaced (instead of extended), the conditions were no longer mutually exclusive, causing multiple Validate buttons to be visible at the same time. Solution: - Remove the extra `action_done` button added in the inherited view - Extend the existing `invisible` conditions using `separator=" or "` so the original logic is preserved and the buttons remain mutually exclusive opw-5508871 Forward-Port-Of: odoo/enterprise#109911 Forward-Port-Of: odoo/enterprise#107993
This update resolves an issue where default theme colors were unintentionally affecting the Odoo Report Editor's styling. The change restricts the report editor from using these theme colors, ensuring consistent report design. This improves the stability and predictability of report creation within Studio.
Original PR description
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer) Those colors are a bit special (see full…
Before this commit, there was no way to tell the ColorPicker to not use the DEFAULT_THEME_COLOR_VARS (ie classes of the form o-color-[n] with n some integer)
Those colors are a bit special (see full discussion on the opw)
Their existence is described in module web
Their CSS definition is implemented in module html_editor
Reports don't use them at all We probably don't want reports' style to be influenced by the presence or lack thereof of the html_editor module, which was originally made to customize the interface.
Those architecture issues should be solved downstream in master, but they are practically endemic in Odoo.
This commit addresses the fact that Studio's report editor should not allow those colors as possible customization by offering the components and plugins in the chain a props to disable them.
After this commit (and more broadly the PR bundle), the default theme colors are not available in studio's report editor.
see odoo/odoo#251446
opw-5892573
Forward-Port-Of: odoo/enterprise#110594
Forward-Port-Of: odoo/enterprise#109206Previously, email attachments in documents were displayed as raw base64 strings instead of their actual HTML content. This change fixes a technical issue where an update to the Odoo system incorrectly encoded email data. Now, email attachments will be correctly rendered as HTML, improving the user experience when viewing email documents.
Original PR description
When opening an email document from the kanban view or the attachment viewer, the content is currently displayed as a raw base64 string rather than the actual HTML text. This happens because an ORM update standardized the `read` method to always return binary fields (including `raw`) as base64-encoded strings to prevent RPC serialization crashes. Because the frontend was still expecting raw HTML text directly from the RPC response, it failed to render the emails correctly. This change was introduced in odoo/odoo@a6de2a5f This commit updates the kanban record and attachment models to explicitly decode the base64 payload back into a UTF-8 string upon fetching, restoring the correct display of email contents. Task-6012504 Forward-Port-Of: odoo/enterprise#110322
This update corrects a minor issue where the 'Discard' label was automatically added to a button within the document auto-form modal. This change ensures a cleaner and more professional user experience for users working with document management features. The fix prevents a confusing label from appearing.
Original PR description
Purpose ======= The default label "Discard" is now automatically added on button with `special="cancel"`. For the auto-form modal in document we don't want that label, and so we force the string to be empty. Task-6004879 Forward-Port-Of: odoo/enterprise#110624
This update ensures that a critical field within the timesheet timer form is now always required. This change improves data accuracy and prevents errors when recording timesheet hours, leading to more reliable reporting.
Original PR description
`this` is now mandatory Forward-Port-Of: odoo/enterprise#111125
Features or functions removed from Odoo
This update removes outdated and unused code within the l10n_pe_edi_pos module, addressing a dependency issue with an older version of the ‘account_edi’ form. This cleanup improves the stability and maintainability of the Odoo Enterprise system.
Original PR description
In this commit: - error due to dead code : http://pastebin.com/q65h1fME - Form 19.2v 'account_edi' is not in the dependencies, so we have to remove that dead code. - Here is the task which remove that dependencies : https://www.odoo.com/odoo/project/967/tasks/5164609 Forward-Port-Of: odoo/enterprise#109674
This update streamlines the Indian payroll system by removing duplicate salary structures for workers and non-executives. These structures were previously redundant, as their rules are now integrated into the main India: Employee Pay structure. This simplifies payroll management and reduces potential errors.
Original PR description
This PR removes the India: Worker and India: Non-Executives salary structures, as most of the rules defined in these structures are already present in the India: Employee Pay salary structure. These structures are therefore duplicated and redundant. task-5895174
Code cleanup and technical improvements
This update replaces `useEffect` with `useLayoutEffect` in several Odoo modules. This change enhances performance and stability by ensuring UI updates are applied before the browser paints the screen, leading to a smoother user experience. It's part of the ongoing migration to Owl3.
Original PR description
WIP community: https://github.com/odoo/odoo/pull/246838
Miscellaneous changes
This pull request updates the translations for various Odoo modules to align with the saas-19.2 release. These updates ensure that the Odoo Enterprise platform is localized correctly for users around the world, improving the user experience for international customers. The changes cover multiple languages and modules.
Original PR description
Forward-Port-Of: odoo/enterprise#108146