Tuesday, July 1, 2025
18 changes · saas-18.3
Resolved issues and error corrections
This fix corrects how payroll expense records are referenced so expense sheets are handled as expense sheets rather than payslips. It helps prevent incorrect payroll-expense processing and keeps related employee expense data aligned with the right records.
Original PR description
this commit fixes wrong reference to `hr.payslip`. `payslip_sheets` should be a recordset of `hr.expense.sheet` and not `hr.payslip`. Forward-Port-Of: odoo/enterprise#89068 Forward-Port-Of: odoo/enterprise#88994
The VoIP mobile keypad now keeps the cursor in the right position when entering numbers. This prevents the first digit from jumping to the end, making mobile dialing more reliable and less frustrating for users.
Original PR description
This commit fixes a bug that caused the cursor in the keypad input to be displaced when typing on mobile. So, the first entered number was always to the end. This happens because the `on-touchend` event was calling another event (click) which may involve some changes in the UI that caused this. Steps to produce the bug: 1. Open VoIP wizard from mobile. 2. try to add numbers to the keypad. 3. You will see that the first number is always at the end.
UrbanPiper receipts now print the delivery identifier in a darker, more readable style. This helps staff and customers clearly see delivery references on printed receipts, reducing confusion during order handoff or lookup.
Original PR description
- When printing urban piper receipt the delivery identifier was not correctly rendered in the receipt header. - This is caused by the `text-muted` class on the element, which is causing the text to be too light to be correctly printed. task-id: 4881459 Forward-Port-Of: odoo/enterprise#88763 Forward-Port-Of: odoo/enterprise#88113
A demo payroll setup for Belgium now uses the correct Belgian time off type. This prevents access errors when opening employee records in the demo environment, improving reliability for testing and demonstrations.
Original PR description
This commit fixes an issue in the demo data. A time off allocation was done using a time off type that is not in Belgium. This caused access error when trying to access the employee. This commit fixes the issue by changing the time off type to a belgian one. task-4896664 Forward-Port-Of: odoo/enterprise#88604
The Partner Ledger partner filter now includes all companies, including companies linked to a parent company. This helps users select the correct partner when filtering reports and avoids missing company records in accounting analysis.
Original PR description
Steps to reproduce - create a company - add a contact to this company - go to its contact form and transform this contact from Individual to Company - go to the Partner Ledger - open Partner filtering dropdown list Current behavior - show company and individual with no parent Expected behavior - show individual with no parents and all the companies - Company with parent company seems to be the expected behavior since 2016. If there is one, the Parent company appear in the contact form as defined [there](https://github.com/odoo/odoo/blob/9b03d99fd0174bd67c8ea30e5fd2c26fb2ad2467/odoo/addons/base/views/res_partner_views.xml#L168) opw-4729020 Forward-Port-Of: odoo/enterprise#87017
Belgian payroll termination holiday reports now use the exercise and holiday period from the payslip instead of the employee contract. This helps ensure the reported values match the actual payslip calculation and reduces payroll reporting errors.
Original PR description
The exercise and the holiday period should be based on the payslip instead of the contract. We use the values of the report report_termination_holidays_n and report_termination_holidays_n1 which contains the correct values.
Bank statement reconciliation now avoids matching entries that include cash or credit card account lines when that would conflict with statement rules. This helps prevent validation errors caused by multiple cash or bank accounts on the same statement entry.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/c0f8c5d17b9d78b640d744d8bfb6a2bb4002776a We changed a condition to have the possibility to match move with an account that allows the reconciliation but by doing so, we authorize moves with a cash line to be match. This will trigger a constraint since we cannot have multiple cash or bank accounts on the same statement move. To avoid that we add a condition that the type of the account can be reconcile but is not an asset_cash or liability_credit_card no task id
The Indian payroll demo payslip dates were adjusted so they fit within the employee contract period. This prevents setup errors when installing demo data, making evaluation and testing of the payroll module smoother.
Original PR description
Issue: The demo payslip for employee had dates before the contract start date, leading to errors during demo data installation. Fix: Adjusted the payslip dates to be 3 months before the current date, ensuring they fall within the employee's contract period and allowing successful demo installation. Forward-Port-Of: odoo/enterprise#86794
This fix prevents errors when users add or edit lines in the payslip editing wizard. Payroll teams can complete payslip adjustments without being blocked by a record creation issue.
Original PR description
In this PR we add edit_payslip_lines_wizard_id in the view to prevent a new line record creation error. Forward-Port-Of: odoo/enterprise#88923 Forward-Port-Of: odoo/enterprise#88033
This fixes an access error that could block authorized branch users from opening the Profit and Loss report when journals belonged to a parent company with a different currency. The report can now load correctly without requiring users to have company settings permissions.
Original PR description
This commit is the counterpart of a commit in community to add a test. ### Steps to reproduce: - Create a branch to a company - Create a journal on the parent company with a different currency from the company - Create a user that can access both the parent company and the branch, but can't change the settings of Odoo - Log as this user, select only the branch as current company - Accounting > Reporting > Profit & Loss - Access Error ### Cause: `_compute_display_name` on the journal reads `journal.company_id.currency_id` without sudo. The current user cannot read on `company_id` because of the rule `res_company_rule_employee`. ### Solution: Use `sudo()` to read the currency of the company. opw-4847500 Linked PR: https://github.com/odoo/odoo/pull/215455 Forward-Port-Of: odoo/enterprise#88848 Forward-Port-Of: odoo/enterprise#88339
Installing Sale Planning no longer fails if the standard Hours unit of measure was previously deleted. The system now restores the required unit when needed and prevents it from being removed in contexts where Sale Planning depends on it, reducing setup interruptions.
Original PR description
Steps to reproduce: --- - Install `sale_management` module - Enable `Units of Measure & Packagings` - Delete `Hours` in Units & Packagings - Install `sale_planning` module Traceback: --- ```…
Steps to reproduce:
---
- Install `sale_management` module
- Enable `Units of Measure & Packagings`
- Delete `Hours` in Units & Packagings
- Install `sale_planning` module
Traceback:
---
```
ValueError: External ID not found in the system: uom.product_uom_hour
ParseError: while parsing /home/odoo/src/enterprise/saas-18.2/sale_planning/views/planning_role_views.xml:26, somewhere inside <record id="planning_role_view_tree_inherit_sale_planning" model="ir.ui.view">
<field name="name">planning.role.list.inherit.sale.planning</field>
<field name="model">planning.role</field>
<field name="inherit_id" ref="planning.planning_role_view_tree"/>
<field name="arch" type="xml">
<field name="resource_ids" position="after">
<field name="product_ids" widget="many2many_tags" placeholder="e.g. Cleaning Services" domain="[('planning_role_id', '=', False), ('type', '=', 'service'), ('sale_ok', '=', True)]" context="{ 'default_type': 'service', 'default_planning_enabled': True, 'default_planning_role_id': id, 'default_uom_id': %(uom.product_uom_hour)d, }"/>
</field>
</field>
</record>
```
The error occurred at [1] because the user deleted `Hours` from `Units & Packagings` before attempting to install the other module.
This commit resolves the issue by calling the `ensure_uom_hours` method before updating the `Hours` unit of measure in the data file. This method ensures the UoM is recreated if it no longer exists in the database.
[1]- https://github.com/odoo/enterprise/blob/adfa1ff2ee56b8d43666cd7c2565d6e9430aae48/sale_planning/views/planning_role_views.xml#L38
sentry-6595283261
Forward-Port-Of: odoo/enterprise#85286The Help page now only displays helpdesk teams linked to the website a visitor is currently using. This prevents teams from other company websites from appearing in the wrong place, reducing confusion for customers and staff.
Original PR description
**Steps to Reproduce:** 1. Install the website_helpdesk module. 2. Create a Helpdesk Team A with 'Website Form' enabled, and set the website to 'My website' 3. Create another Helpdesk Team B with 'Website Form' enabled, and Set website to 'My website2' 4. Navigate to Website → Help menu on "My Website". **Observation:** - Both Helpdesk teams appear on "My Website", even though Team B is linked to "My Website 2". **Issue:** - The current domain filter only checks if the Website Form is enabled. - It doesn't restrict teams to the current website, so all teams are visible. https://github.com/odoo/enterprise/blob/b191f16abb5913893a228ccc4eedb8a2242a0298/website_helpdesk/controllers/main.py#L22 **Solution:** - Update the domain to filter on the website ID, to ensure only helpdesk teams related to the current website are shown. OPW-4673939 Forward-Port-Of: odoo/enterprise#88169
The Journal Report now shows the account name in the Account column, making entries easier to identify and review. This fixes a visibility issue that previously left business users with less context when reading journal report lines.
Original PR description
The purpose of this pr is to add account name in the Account column of the Journal Report. Before this code changes:  After this code changes:  OPW : 4702276 Forward-Port-Of: odoo/enterprise#86113
Code cleanup and technical improvements
The VoIP keypad search tests were reorganized into smaller, easier-to-understand checks. The update also makes the tests more reliable, helping reduce false failures during development without changing user-facing behavior.
Original PR description
This commit splits the "search for name" test into smaller tests for clarity and readability. It also removes the use of `edit` in test and uses `insertText` instead in order for the tests to be deterministic. This test was introduced in: https://github.com/odoo/enterprise/pull/87328
Miscellaneous changes
Before this commit this test test_eco_vouchers was only working with all modules installed (classic runbot build) but was failing in singleapp mode (with just test_l10n_be_hr_payroll_account). With this commit this test works as expected in both of them. (and with/) Caused by: ```py reference_year = fields.Selection( selection='_get_years', string='Reference Year', required=True, default=lambda x: str(fields.Date.today().year + 1 if fields.Date.today().month > 5 e
Original PR description
Before this commit this test test_eco_vouchers was only working with all modules installed (classic runbot build) but was failing in singleapp mode (with just test_l10n_be_hr_payroll_account).
With this commit this test works as expected in both of them. (and with/)
Caused by:
```py
reference_year = fields.Selection(
selection='_get_years', string='Reference Year', required=True,
default=lambda x: str(fields.Date.today().year + 1 if fields.Date.today().month > 5 else fields.Date.today().year))
....
def _get_years(self):
today = fields.Date.today()
current_reference_year = today.year + 1 if today.month > 5 else today.year
return [(str(i), i) for i in range(current_reference_year, current_reference_year - 5, -1)]
```
A solution was to use freezetime
runbot error linked: https://runbot.odoo.com/odoo/runbot.build.error/226389
Forward-Port-Of: odoo/enterprise#86887When sharing a knowledge article with an embedded view to an external user. The view was loading indefinitely without saying that the user doesn't have access to that view. Steps to reproduce: ------------------- * Go to the Planning app * Click the 'gear' icon * Click 'Knowledge' * Click 'Inset view in article' * Select an article to add it to * Share the article with portal user > Observation: Embedded planning keeps loading indefinitely. Works with other views that require acce
Original PR description
When sharing a knowledge article with an embedded view to an external user. The view was loading indefinitely without saying that the user doesn't have access to that view. Steps to reproduce: ------------------- * Go to the Planning app * Click the 'gear' icon * Click 'Knowledge' * Click 'Inset view in article' * Select an article to add it to * Share the article with portal user > Observation: Embedded planning keeps loading indefinitely. Works with other views that require access rights. Why the fix: ------------ Embedded view was loading regardless of the error state. opw-4664036 Forward-Port-Of: odoo/enterprise#87589
Currently a traceback is occurring when the user tries to create a Draft Entry, in the batch that contains payslips of multiple companies. **To reproduce this issue:** 1) Install hr_payroll_account and switch to multi-company environment 2) Create two employees with two running contracts respectively 3) Now create a Batch record from payroll/payslips/batches 4) Create two playslips with different companies with the created batch 5) Compute both the payslips and open the batch 6)
Original PR description
Currently a traceback is occurring when the user tries to create a Draft Entry, in the batch that contains payslips of multiple companies. **To reproduce this issue:** 1) Install hr_payroll_account…
Currently a traceback is occurring when the user tries to create a Draft Entry, in the batch that contains payslips of multiple companies. **To reproduce this issue:** 1) Install hr_payroll_account and switch to multi-company environment 2) Create two employees with two running contracts respectively 3) Now create a Batch record from payroll/payslips/batches 4) Create two playslips with different companies with the created batch 5) Compute both the payslips and open the batch 6) Now, try to click on the Create Draft Entry **Error:** A traceback will occur. ``` ValueError: Expected singleton: res.company(1, 2) ``` **Cause:** When the user created multiple payslips with multiple companies containing the same batch and tries to create a Draft Entry, we filtered out the payslips based on the payslip state, and try to change the state to Done using the action_payslip_done method. https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll/models/hr_payslip_run.py#L70 So the self will contain multiple payslip recordsets with different company in each payslip. This leads to the above traceback when accessing company_id from self https://github.com/odoo/enterprise/blob/1e5d7155466f80942f0b8fe2df7fdfb86cae7417/hr_payroll_account/models/hr_payslip.py#L61 **Solution:** In payslips, the company_id field should be in readonly state, since the value of the company_id will computed from the employee_id which is a required field. Also raised a validation Error for the previously created record to handle the traceback. Related Upgrade PR:- https://github.com/odoo/upgrade/pull/7763 opw-4797089 Forward-Port-Of: odoo/enterprise#87984 Forward-Port-Of: odoo/enterprise#86628
The current implementation of the `startTimer` function incorrectly calculates the current time when the timer has been paused. For ex, if the timer started 24 hours ago and was paused 23 hours ago. Calling `startTimer` to resume the timerReactive component, would calculate the offset between the paused time and current time incorrectly. This change ensures that no extra time is added to the timer, when it is in a paused state, maintaining accurate tracking of elapsed time. opw-4658402 op
Original PR description
The current implementation of the `startTimer` function incorrectly calculates the current time when the timer has been paused. For ex, if the timer started 24 hours ago and was paused 23 hours ago. Calling `startTimer` to resume the timerReactive component, would calculate the offset between the paused time and current time incorrectly. This change ensures that no extra time is added to the timer, when it is in a paused state, maintaining accurate tracking of elapsed time. opw-4658402 opw-4824616 opw-4829820 Forward-Port-Of: odoo/enterprise#86831