Tuesday, September 30, 2025
28 changes · master
Enhancements to existing features
The Point of Sale interface has been updated to use the newer way of showing tags on orders and order lines. This helps keep the system compatible with upcoming platform changes while preserving the current user experience.
Original PR description
This commit replaces the use of component TagsList by t-foreach and tag component. TagsList will soon not render tags anymore. This commit is a first pass to reduce the diff and make the transition smoother. task-4660360
Payroll payslip line and worked days reports have been adjusted so users can no longer edit report fields that should only be viewed. The update also improves report navigation and search options, helping payroll teams access the right data more reliably.
Original PR description
-In payslip line report, some fields can be edited, which should not be allowed. -Views have been adjusted to prevent the navigation from pivot to list view. -Search view has been modified for easier data reaching. Forward-Port-Of: odoo/enterprise#95313 Forward-Port-Of: odoo/enterprise#94284
The report editor now uses a newer version of its content-cleaning component, helping keep edited report HTML consistent and reliable. Related automated tests were updated because the underlying tool now produces a more predictable attribute order.
Original PR description
Note: due to the PR [1], the attributes' order is more predicatable, hence the tests adaptations. [1]: https://github.com/cure53/DOMPurify/pull/1085 task-5110128
Resolved issues and error corrections
This fixes visibility issues in dark mode for appointment and point-of-sale screens. Icons and text now use colors that remain readable across light and dark themes, making the interface easier to use.
Original PR description
In this commit: ------------------- - Added a dark mode color for the star icon. - Changed the text color to white in light mode, which is reflected as black in dark mode. This fixes the issue of the text not being properly visible in dark mode. task:4943078 Forward-Port-Of: odoo/enterprise#95673 Forward-Port-Of: odoo/enterprise#93993
Code cleanup and technical improvements
The planning calendar and related portal views were rebuilt using a newer internal interaction approach. This keeps the same business workflows while making the screens easier to maintain and reducing duplicated display logic across planning, forecasting, and sales planning.
Original PR description
continue working on the refactoring introduced by this commit: [1] [1]: https://github.com/odoo/odoo/commit/dd13994674d4ef4683f5a4d46a1f604650cfb92b task-4367641
When the AI feature cannot scrape a webpage, the system now records it as a warning instead of an error. This better reflects that the issue is already shown to the user and does not block the overall process, helping reduce unnecessary error alerts.
Original PR description
Currently, an error can occur on unsuccessful scrapping of URL.
**Error:**
`Error scraping URL https://agenciavirtualpy.com: HTTPError('403 Client Error: Forbidden for url: https://agenciavirtualpy.com/')`
- Instead of logging an error, we log only warning during unsuccessful URL
scraping because it is not a blocking point in the code.
- On unsuccessful scraping, we log warnings [1] and raise a UserError [2] to
inform the user about the failed URL scraping. Therefore, we should log a
warning as the UserError is already present.
[1]: https://github.com/odoo/enterprise/blob/1930d045a5f40f33b0a391b90d5adaed0eb90083/ai/models/ai_agent.py#L258
[2]: https://github.com/odoo/enterprise/blob/1930d045a5f40f33b0a391b90d5adaed0eb90083/ai/models/ai_agent.py#L283-L285
sentry-6634525990
Forward-Port-Of: odoo/enterprise#94960
Forward-Port-Of: odoo/enterprise#94002The Spanish Mod 349 tax report now correctly shows the underlying invoice details when users audit the summary line for intra-community operations. This helps accounting teams verify reported amounts more reliably and reduces manual investigation when reviewing tax filings.
Original PR description
Steps to reproduce: - With an ES company setup - Create 1 invoice to an EU partner - Make sure Mod349 Invoice Type is set - Go to Accounting / Reporting / Statement Reports / Tax Report - Select Tax Report (Mod 349) (ES) - Audit line 'Importe de las operaciones intracomunitarias' Issue: No line will be shown This occurs because the system will allow auditing the line, since the report line is defined as aggregation of sublines, however those sublines are all custom so we should provide a custom domain to retrieve the relevant lines opw-4752813 Forward-Port-Of: odoo/enterprise#84633
The partner ledger now keeps names and expand arrows properly aligned on phones and tablets. This makes the report easier to read and use on smaller devices without changing its underlying data or behavior.
Original PR description
Problem: On smaller screens (phone or tablet) the center alignment between the partner name and the little arrow is broken. Cause: This happened because the little arrow has btn class, which gets larger on smaller screens (to make it easier to click). The larger button causes the center alignment to be lost, as it grows alone inside the table row. Fix: This commit fixes this issue by ensuring that the content of line_name and line_cell are vertically aligned to the middle, and that items in their sub-containers are aligned to the center. task-5106889 Forward-Port-Of: odoo/enterprise#95317
This fixes naming inconsistencies introduced during a previous refactor of Indian GST reporting. The change helps keep India-specific reporting logic isolated so it does not interfere with other localizations, improving reliability for tax reporting workflows.
Original PR description
Following the refactor-https://github.com/odoo/enterprise/commit/3722e9255647254a078166c5ea9696cbf7818147 and removal of `l10n_in.gst.return.period` and adapting the `account.report` since it's no longer an Indian Localisation model the method names not renamed to the localisation specific in this commit we fix that so other localisation are aren't affected Forward-Port-Of: odoo/enterprise#94441
Planning now shows a valid allocated percentage for employees using flexible or fully flexible work schedules when grouped by resource and role. This prevents confusing 'NaN' values from appearing in the schedule view and gives managers clearer staffing information.
Original PR description
Steps to reproduce: ==== - Install the Planning module. - Go to Planning and apply two level group by: Resources ⇒ Role. - Ensure some employees (e.g., AKA Foster) are assigned a 'Flexible Hours'…
Steps to reproduce: ==== - Install the Planning module. - Go to Planning and apply two level group by: Resources ⇒ Role. - Ensure some employees (e.g., AKA Foster) are assigned a 'Flexible Hours' work schedule. Issue: === When grouping by Resource ⇒ Role, employees with flexible hours display 'NaN' instead of a valid allocated percentage. Cause: ==== Flexible and fully flexible resources do not have predefined work intervals in their schedules. The calculation previously relied on work_intervals to compute 'workHours', which is undefined for flexible users, resulting in 'NaN' in the UI. Fix: === The issue is resolved by using avg_hours instead of work_intervals for flexible and fully flexible resources. Additionally, the necessary change has been added to handle fully flexible schedules as well. Since both flexible and fully flexible resources lack scheduled intervals, their avg_hours serve as a reliable value for computing 'workHours', preventing the display of NaN. task-4968436 Forward-Port-Of: odoo/enterprise#91436
When a signer is no longer assigned in a Sign template, the sidebar now removes the old profile picture instead of showing a stale avatar. This keeps the signer information accurate and avoids confusion for users preparing documents for signature.
Original PR description
Issue: - In the template iframe view, when editing a signer’s settings, removing the "Assign To" field did not clear the profile picture. - As a result, the previous avatar remained visible in the sidebar even though no user was assigned. Fix: - Updated `updateRoleNameAndAvatar` to reset the `profilePic` state to an empty string when `assignTo` is removed. Impact: - The profile picture is now correctly hidden when no signer is assigned, ensuring the sidebar always reflects the current state of the signer. Steps to reproduce: 1. Open the signer settings dialog in the template view. 2. Clear the `Assign To` field. 3. Save the dialog. Forward-Port-Of: odoo/enterprise#95743
This fix exposes the company country code in payroll configuration settings. It helps the system access the correct country context from settings, reducing configuration-related errors during setup or processing.
Original PR description
Add a related field in res.config.settings to expose country_code build_error-231405
Payroll settings now include the company country code needed by the configuration view. This prevents upgrade validation errors and access-rights inconsistencies, helping payroll setup remain stable during module updates.
Original PR description
The payroll settings view referenced `country_code` in its invisibility condition, but the field was missing from `res.config.settings`. This caused a validation error and access rights inconsistency during module upgrade. A related field `country_code` has been added, pointing to `company_id.country_id.code`. build_error-231409
This fix prevents errors when upgrading the Lithuanian payroll module by ensuring the payroll settings screen has the country information it expects. It improves reliability for companies using Lithuanian payroll without changing day-to-day payroll features.
Original PR description
The payroll settings view referenced `country_code` in its invisibility condition, but the field was missing from `res.config.settings`. This caused a validation error and access rights inconsistency during module upgrade. A related field `country_code` has been added, pointing to `company_id.country_id.code`. build_erro-231395
Documents can now create server actions that generate journal entries for journals marked as Credit Card. This fixes a gap that prevented users from setting up credit card statement workflows through Documents.
Original PR description
We are unable to create an action to create a credit card statement on a journal with type credit card Allow to create a Server Action to create Journal Entries in journals of type "Credit Card" in Documents. task-5123868
The SEPA payment flow now checks the bank account actually selected by the user, not only the account originally linked to the bill. This prevents unnecessary warning banners when a trusted account is chosen, improving confidence during vendor payment processing.
Original PR description
**Steps to reproduce:** 1. Install the modules: `accounting` and `account_iso20022`. 2. Configure a bank journal with SEPA credit transfer in *Outgoing payment methods*. 3. Create a partner with two bank accounts: one trusted, one untrusted. 4. Create a vendor bill for this partner. 5. Register a payment using the SEPA credit transfer method. 6. Manually select the trusted bank account from the dropdown. **Observed behavior:** * A warning banner is shown when the trusted account is selected. **Root cause:** * `_compute_trust_values` only validated the bank account from the batch (original invoice data) and ignored the `partner_bank_id` if the user changed it manually in the wizard. **Solution:** * Update `_compute_trust_values` to also validate the currently selected `partner_bank_id`, ensuring the trust check reflects the user’s actual selection. opw-5059740 Forward-Port-Of: odoo/enterprise#95124
Helpdesk team tag assignment now only lets internal users be selected as team members. This prevents portal users from being accidentally assigned to handle tickets, keeping automatic ticket dispatch aligned with staff responsibilities.
Original PR description
**Steps to Reproduce:** 1. Go to Helpdesk → Overview. 2. Open a team (e.g., 'Customer Care') and click on 'Settings'. 3. In the team settings, enable 'Automatic Assignment' → 'Dispatch tickets based on tags'. 4. Configure tags handled by team members. 5. In the 'Team Members' field, try to assign users. **Issue:** Portal users are displayed in the 'Team Members' selection list, even though they should not be assignable to helpdesk team tags. **Current behaviour:** - The 'Team Members' field shows all users, including portal users. **Expected behaviour:** - Only internal users should be selectable as 'Team Members'. - Portal users should not appear in the many2many list. **Fix:** Added a domain on the 'user_ids' field to exclude portal users from the 'Team Members' selection. **task-5093188** Forward-Port-Of: odoo/enterprise#95264
This fix ensures the main DATEV account is only assigned for companies based in Germany, preventing incorrect accounting setup for non-German companies. It also improves how debit and credit lines are gathered, making the report logic more efficient for larger records.
Original PR description
The main datev account should only be set for German companies (check for country code) Also fix the complexity of gathering the debit and credit lines: `+=` has a complexity of `O(n²)` whereas `filtered` has a complexity of `O(n)`. Forward-Port-Of: odoo/enterprise#69881
This fixes an issue where General Ledger lines using custom grouping could not be expanded to show details. Businesses using tailored report groupings can now drill into their accounting data as expected.
Original PR description
Before when we added different groupby on the gl line than the default ones, that would not be unfoldable by default. This is due to a default dict that set has_sublines to False by default and it would never be set to true for groupby other than the default ones. Forward-Port-Of: odoo/enterprise#95545
The ESG Database menu no longer offers a direct create option, reducing confusion about unsupported automatic database imports. Users can still create database records from emission factors when they need to manually classify custom emission factors.
Original PR description
Before this commit, when the user goes to Database menu inside ESG app, the user can create a database if he wants. However, when he creates a database, he might think it can add the link of the database to automatically fetch the data, but this system is not implemented because each database has its own formatting. This commit disables the create action inside that menu to avoid confusing the user. However, he can still create a database inside a emission factor if he wants to classify his emission factors manually created. task-5117594 Forward-Port-Of: odoo/enterprise#95613
Customers renting products on the website will now see the correct stock warning when availability is limited. This helps prevent confusion during checkout and reduces the risk of orders being placed without clear availability information.
Original PR description
Introduced by 151349aeaf899a3b70534a0120a5f49882981d53, the `_set_shop_warning_stock` method was modified and is now supposed to return the applied warning. Forward-Port-Of: odoo/enterprise#95731
This fixes a remaining source of inconsistent automated test behavior in Web Studio's rename flow. It helps keep the development and release process stable by reducing false test failures, with no expected change for end users.
Original PR description
Similar to https://github.com/odoo/enterprise/commit/5574c52df8794b3f23d385a670cac8fb5355e229 There was still one indeterminism remaining runbot-232572 Forward-Port-Of: odoo/enterprise#95447
This update corrects an internal mismatch that caused a payroll test to fail for Indian localization fields. It ensures selected employee payroll fields remain consistently editable across employee records and their version history, reducing the risk of configuration issues.
Original PR description
The test `TestHrVersion.test_related_fields_on_version` was failing with:
(Readonly) Inconsistency between some employee fields and version ones.
for the following fields:
- l10n_in_medical_insurance_total
- l10n_in_provident_fund
- l10n_in_pf_employee_percentage
- l10n_in_pf_employer_percentage
- l10n_in_fixed_allowance
Cause:
- On `hr.employee`, these fields were defined as `related='version_id.<field>'` with `readonly=False`. On `hr.version`, the same fields were still implicitly readonly (due to being computed/related), creating a mismatch.
Solution:
- Explicitly set `readonly=False` on these fields on `hr.version` as well.
[RB-232577](https://runbot.odoo.com/odoo/error/232577)
Forward-Port-Of: odoo/enterprise#94914The account reports area now uses the label “Type” instead of “Category” for account return types. This fixes naming so the field better matches its purpose and reduces confusion for users working with returns.
Original PR description
Forward-Port-Of: odoo/enterprise#95183
Mexican payroll employee fields are now only visible to authorized HR payroll users. This prevents non-HR internal users from encountering access errors when viewing employee profile data and keeps payroll-related information appropriately limited.
Original PR description
The test `test_employee_fields_groups` crashed with: `AccessError: The fields "l10n_mx_regime_type,l10n_mx_shift_type, l10n_mx_payment_periodicity", which you are trying to read, are not available for employee public profiles.` These fields exist without HR group restriction as a result, a non-HR internal user calling `.read([])` triggered the `AccessError`. This commit adds `groups="hr_payroll.group_hr_payroll_user"` to these fields so they are only accessible to HR users, resolving the error. [RB-231737](https://runbot.odoo.com/odoo/error/231737)
This update adjusts a payroll-related test so it uses the right user permissions during setup. It helps keep automated checks reliable and prevents false build failures without changing business functionality.
Original PR description
to bypass the access right restriction in test build_error-230682
A naming error prevented a Mexican localization validation from running correctly after a related core function was renamed. This fix aligns the localization with the corrected function name so the intended invoice checks are active again in Odoo 19.
Original PR description
In odoo, The standard function _check_move_constraints had a typo, as it was missing the last t (_check_move_constrains). When it was inherited in this module, the function was left with the typo. In version 19, this typo was fixed in the standard function, but the Mexican localization function was left as it was, so the function was useless as it attempts to inherit a method that does not exist. In this PR, this typo is corrected so that the functionality also exists in 19. Task-id: 5119381 I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#95825
When a user deletes a message linked to an accounting report annotation, the related annotation is now removed as well. This keeps financial report notes accurate and avoids outdated comments remaining visible after the original message is deleted.
Original PR description
And improve a bit the tour to check the result to prevent cases where the tour would pass but something wouldn't be done right. Forward-Port-Of: odoo/enterprise#95750