Daily updates from Odoo
Monday, August 18, 2025
86 changes
29 changes
Resolved issues and error corrections
Manufacturing users can now stop work order operations linked to billable projects even when the operation runs longer than expected. The fix prevents an accounting-related access error from interrupting production tracking while preserving the intended analytic cost recording.
Original PR description
To reproduce:
=============
- create a BOM with an operation having an expected duration
- make sure the product of BOM has MTO and Manufacturing routes
- create a Billable project with visibility=portal
- create an SO with the product of BOM and set the project for analytic distribution
- confirm the SO -> a MO is created
- with a user having:
- hr.group_hr_user
- mrp.group_mrp_manager
- project.group_project_user
- hr_timesheet.group_hr_timesheet_approver
- go to the MO and start the first operation and wait to exceed the expected duration
- stop the operation -> access error on the analytic account line
Problem:
========
when the user tries to stop the operation, at first moment AAL will be created, as we exceed the expected duration, we will try to update the AAL which leads to an access error as the user does not have accounting rights.
Solution:
=========
deal with AAL records as sudo
opw-4897142
Forward-Port-Of: odoo/enterprise#92422The Belgian payroll salary configurator now calculates the laptop benefit in kind consistently with other benefits such as internet and mobile phone. This prevents incorrect salary package values when employees or HR teams configure compensation involving a company laptop.
Original PR description
The benefit in kind laptop salary rule was not adapted for the salary configurator. This commit fixes the issue by always returning the correct laptop value if the salary rule is used in a salary configurator, like it is already the case for the internet and mobile benefits. task-4971722 Forward-Port-Of: odoo/enterprise#92216 Forward-Port-Of: odoo/enterprise#91201
Peru PLE reports 5.1 and 6.1 now keep the original account move name exactly as entered instead of removing spaces or slashes. This helps preserve complete audit information and reduces the risk of discrepancies with tax authorities.
Original PR description
Problem: For PLE reports 5.1 and 6.1, the value for `glosa` was being modified (i.e. blank spaces and slashes removed). Although SUNAT accepts the modified value, no information should be removed in the case it might lead to issues with tax authorities during an audit. Solution: The value for `glosa` on the reports should be the exact account move name. opw-4803060 Forward-Port-Of: odoo/enterprise#92271 Forward-Port-Of: odoo/enterprise#91967
A test in the timesheet holiday area was updated so it no longer depends on the current date or Belgian timezone. This prevents false failures in automated checks and helps keep releases moving smoothly.
Original PR description
Before this commit, when the `test_timer_methods_handle_project_access_restrictions` test is executed after 22h in UTC the test failed because the timezone of the current user is the belgian one. This commit makes sure the date and timezone no longer affects this test since it is not the purpose of this test. runbot-error-230490 Forward-Port-Of: odoo/enterprise#92264
Swiss payroll-specific employee fields are now only shown for Swiss companies in multi-company setups. This prevents users in other countries from seeing irrelevant Swiss payroll information, reducing confusion and improving data entry clarity.
Original PR description
When using odoo in multi company with Swiss installed, we can see the fields from any other company. They should be hidden if the country is not Swiss. Task: 4788657
When Excel files shared by portal users are converted into Odoo spreadsheets, portal users are now kept at view-only access. This prevents conversion errors and preserves the rule that external portal users cannot edit spreadsheets.
Original PR description
Let's say a Document Folder is shared with a portal user with 'edit' access. The portal user shares a .xlsx file to the folder, and an internal user later try to convert the file to odoo spreadsheet. During the conversion, the portal user has 'edit' role on the folder, which is copied to the documents.access records of the converted sheet. Since Odoo prevents Spreadsheets from being shared in edit mode to portal users, _check_spreadsheet() raises a Validation Error. <img width="544" height="188" alt="image" src="https://github.com/user-attachments/assets/48426ff8-0cd9-4fb0-8e52-31099e586064" /> To resolve this issue, we force portal users to have `view` role on Spreadsheets during the XLSX to Spreadsheet conversion. opw-4753670 Forward-Port-Of: odoo/enterprise#92427 Forward-Port-Of: odoo/enterprise#92134
Rental invoice lines are now excluded from automatic cost-of-goods-sold entries in Anglo-Saxon accounting. This prevents rental sales from generating inappropriate inventory cost accounting, helping keep financial records accurate.
Original PR description
…entries Modified the COGS generation logic to skip any invoice lines that come from a rental sales order. task-4919306 Forward-Port-Of: odoo/enterprise#91472 Forward-Port-Of: odoo/enterprise#90901
This fix corrects a small typo in the accounting automation that selects the company context for currency rate updates. It helps ensure scheduled accounting processes use the right company information, reducing the risk of incorrect currency rates in multi-company environments.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/5466daa617faef99a2bb5c06beefb3e2d082f459, we fixed a bug where the cron would be trigger with the wrong company which impacted the currency rate. But we did a typo in one of the change of the company. no task id Forward-Port-Of: odoo/enterprise#92475
This fix ensures manually stored external tax amounts also keep the related taxable base amounts. It helps tax calculations and reporting stay accurate when using external tax providers such as AvaTax, including localized integrations.
Original PR description
…unts
This fixes an error that could appear when viewing product variant data with the POS Pricer module installed. The price display field now always receives a safe default value, preventing disruptive tracebacks for users or administrators inspecting product records.
Original PR description
**Step to reproduce:** 1. Install pos_pricer module: 2. Open the Point of Sale app and create a product. 3. Go to the Product Variants menu. 4. Open that product. 5. Activate developer mode. 6. Click…
**Step to reproduce:** 1. Install pos_pricer module: 2. Open the Point of Sale app and create a product. 3. Go to the Product Variants menu. 4. Open that product. 5. Activate developer mode. 6. Click on the Bug icon (top-right corner). 7. Click on Data. **Issue:** A traceback is raised with the error: `Compute method failed to assign product.product(191,).pricer_display_price` The method `_compute_pricer_display_price` was removed in this commit https://github.com/odoo/enterprise/commit/87b1672ac7c1d27cd9eab05138b78f6a9439fea7 , and was reintroduced in a later commit https://github.com/odoo/enterprise/commit/4575d3dfdbd0ccd9bf57bddbd35a89bd47c48798 to avoid the AttributeError. **Cause:** The computed field `pricer_display_price` is a type Char and and is non-stored was not being assigned a value inside the compute method. So ORM requires that records to be assigned a value in a compute method. **Solution:** To fix this, assign a default value to `pricer_display_price` inside the compute method to prevent the error. opw-4887318 Forward-Port-Of: odoo/enterprise#88517
The employee name filter now works correctly when creating a new pay run. This helps payroll users find the right employees faster and avoids confusion during payroll preparation.
Original PR description
Originally, when creating a new payrun, if you filter by employee name, the filter doesn't work. The filter logic has been adjusted to search for the correct field.
Opening a spreadsheet filter editor now replaces the existing side panel instead of stacking another panel on top. This prevents broken Cancel and Remove actions, making filter editing more reliable for users.
Original PR description
Steps to reproduce: - Open the global filter side panel (list of all filters) - Pin the panel - Click on a specific filter to view/edit it Before this commit: - A second side panel was opened instead of replacing the current one - Clicking 'Cancel' on the new panel had no effect - Clicking 'Remove' caused a traceback After this commit: - The new side panel replaces the current one (main or secondary) - The previous panel is restored correctly on 'Cancel' or 'Remove' - If the new panel is already open, we simply close the current one Task: 4911603
A payroll-related test was moved to the correct accounting test area because it relied on accounting features. This prevents Belgian payroll checks from failing when only a single app is being tested, improving reliability without changing user-facing functionality.
Original PR description
Previously a test created on l10n_be_hr_payroll depended on account module, which broke single app tests. This commit moves the test from l10n_be_hr_payroll to test_l10n_be_hr_payroll_account [Old PR](https://github.com/odoo/enterprise/pull/89149) Task: 4942293
This fixes an issue where expanding or collapsing grouped account report lines could leave child lines visible and trigger an error. Users can now fold and unfold nested grouped report lines reliably, improving report usability and avoiding interruptions.
Original PR description
Steps to reproduce: - Create an Account Group - Create a new Account Report as follows: * Name: any * Lines: 1. [test line] * Group By: partner_id,account_id * Expressions: 1. [test expression] *…
Steps to reproduce:
- Create an Account Group
- Create a new Account Report as follows:
* Name: any
* Lines:
1. [test line]
* Group By: partner_id,account_id
* Expressions:
1. [test expression]
* Computation Engine: Odoo Domain
* Formula: [('account_id.account_type', '=', 'asset_receivable')]
* Subformula: sum
- Actions > Create Menu Item
- Open the new report
- Try to unfold/fold a partner line
Issue:
Folding will not fold the first child (representing the created account group). Also, error will raise
```
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~37|~account.report.line~255|{'groupby': 'partner_id'}~res.partner~4226|~account.group~90
Occured on odoo.nas.cpolar.cn on 2025-04-26 04:58:53 GMT
OwlError: Got duplicate key in t-foreach: ~account.report~37|~account.report.line~255|{'groupby': 'partner_id'}~res.partner~4226|~account.group~90
Error: Got duplicate key in t-foreach: ~account.report~37|~account.report.line~255|{'groupby': 'partner_id'}~res.partner~4226|~account.group~90
at AccountReport.template (eval at compile (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:13743:20), <anonymous>:138:49) (/web/static/lib/owl/owl.js:5752)
at App.callTemplate (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:11363:50) (/web/static/lib/owl/owl.js:3372)
at AccountReport.template (eval at compile (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:13743:20), <anonymous>:9:12) (/web/static/lib/owl/owl.js:5752)
at RootFiber._render (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:9774:38) (/web/static/lib/owl/owl.js:1783)
at RootFiber.render (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:9766:18) (/web/static/lib/owl/owl.js:1775)
at ComponentNode.render (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:10493:23) (/web/static/lib/owl/owl.js:2502)
```
Analysis:
Folding issues occurs because of a mismatch in the grouping markup quote escape. If we don't have the very same string the controller cannot properly recognize the parent line and then is unable to fold/unfold properly.
This eventually led to the mentioned error at unfold as the backend will try to generate the apparently missing lines to unfold, only to create duplicate lines
opw-4754241
Forward-Port-Of: odoo/enterprise#89726Opening a Swiss payroll wage type could fail because the activity and message area was no longer available on salary rules. This fix restores that support so payroll configuration forms open normally and users can continue using the existing communication history area.
Original PR description
To reproduce: ============= 1- Install Swiss payroll 2- go to payroll configurations 3- wage types 4- open the form view of one wage type Problem: ======== The hr_salary_rule no longer inherits mail.thread due to this PR : https://github.com/odoo/enterprise/pull/83136 So we cannot load the chatter and a traceback will happen Fix: ===== inherit mail.thread in hr_salary rule so the chatter can work properly There's another solution to do which is removing the chatter from the view But the chatter exists in the previous versions and we try to make it work in 18.4 opw-5015226
The project settings tooltip now accurately explains how document folders work with project tasks. This avoids confusion by no longer suggesting that task-related documents are automatically moved into the selected folder.
Original PR description
Before this commit, the tooltip displayed for `documents_folder_id` defined in `project.project` model, said all documents linked to a task of a project will be automatically added inside that folder but it is no longer the case since the refactoring of Documents to simplify the implementation but also let the documents user sorts his documents as he wants since now the access rights are defined by folder. This commit updates the tooltip accordingly. PR simplifying the bridge between documents and project apps: #75214 opw-5000224 Forward-Port-Of: odoo/enterprise#92189 Forward-Port-Of: odoo/enterprise#92164
Tickets created from Timesheets now default to the Helpdesk Team linked to the selected project. This helps prevent tickets from being assigned to the wrong team and keeps timesheet-related support work routed correctly.
Original PR description
Steps to Reproduce: - 1. Go to Timesheets > My Timesheets, start the timer, and select the project linked to the helpdesk team. 2. In the timer header, quick-create a new ticket via the "Ticket" field dropdown 3. Observe that the default helpdesk team on the new ticket is incorrect. Issue: - - When creating a ticket from the Timesheets module (e.g., via timer header or views), the system selects an incorrect default helpdesk team, leading to misassigned tickets. Cause: - - The core default logic for team_id prioritizes user membership or the first team without considering the selected project's linked helpdesk team. Fix: - - Override `_default_team_id` to set the correct Helpdesk Team based on the selected project. - A domain has been added to the team selection field within the timesheet views to only show teams that have the timesheet feature enabled. task-4885679 Forward-Port-Of: odoo/enterprise#92112 Forward-Port-Of: odoo/enterprise#89503
The employee form now shows the seniority-at-hiring field under Education instead of Citizenship. This makes the Belgian payroll employee record better organized and places the information where users are more likely to expect it.
Original PR description
Move Seniority at hiring from Citizenship to Education group in employee form. In this PR, we moved seniority at hiring from the Citizenship to the Education group in the employee form. Related task: 4936767.
Payroll teams can now correct validated work entries as long as they have not yet been used in a payslip. This helps fix attendance or payroll input mistakes earlier without undoing unrelated payroll work, while preserving protection for entries already tied to payslips.
Original PR description
Originally, the validated work entries cannot be modified, either they have been included in payslips or not. This logic has been adjusted to allow for modifying the work entries marked as "validated" if they are not linked to a payslip. Task #4921300
Fixed an issue where the General Ledger could crash when users enabled the Account Types filter and expanded an account. This ensures accounting users can review payable and receivable activity without interruption.
Original PR description
Steps to reproduce:
- Open general ledger configuration
- Under Options tab, set filter Account Types as "Payable and receivable"
- Open General Ledger report
- Unfold an account
Traceback will raise
```
File "[...]/odoo/tools/query.py", line 101, in add_join
assert self._joins[alias] == (sql_kind, table, condition)
AssertionError
```
Because of the account types filter we already add a "LEFT JOIN" between account_move_line and account_account
Then, trying to add a "JOIN" between the same tables, the system find a different type of JOIN and fails the assert
opw-4742411
Forward-Port-Of: odoo/enterprise#87431Odoo now automatically matches Point of Sale customer account charges with their related settlement payments. This prevents settled POS balances from incorrectly appearing as available credit for other invoices, reducing customer account confusion.
Original PR description
### Problem: When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create…
### Problem:
When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create another account move line crediting Account Receivable (represents the payment). The second move line is considered, by Odoo, as an outstanding amount, and this amount can be used to pay another invoice (sale order invoice). The moves affecting Account Receivable are still correct. However, unreconciling the two lines created from PoS will cause a confusion for clients who may use this amount to pay other invoices.
### How to reproduce:
* Open a PoS session.
* Create an order and pay using customer account.
* Settle this customer's account (inside PoS).
* Create a Sale Order and invoice it (or just an invoice).
* The amount settled can be used as outstanding amount and can be used to pay the created invoice.
commmunity PR: https://github.com/odoo/odoo/pull/210619#pullrequestreview-2853451890
opw-4794793
Forward-Port-Of: odoo/enterprise#92374
Forward-Port-Of: odoo/enterprise#86114DHL rate checks during ecommerce checkout now use a planned date in the future, matching DHL's requirements. This prevents customers from seeing an error when shipping rates are requested with the default current date and time.
Original PR description
Before this commit: During checkout on Ecommerce website the default date of the order is current date and time. There is no option to change the date when getting rate. Which results in an error that the date must be in the future. After this commit: `Planned_date` for getting rate is set in furture to avoid the error. Docs reference: https://developer.dhl.com/api-reference/dhl-express-mydhl-api#reference-docs-section under rating endpoints. opw-4849754 Forward-Port-Of: odoo/enterprise#91705
The restaurant floor plan now only shows appointments scheduled for the current day. Late appointment labels are also highlighted correctly, helping staff focus on relevant reservations and spot delayed customers faster.
Original PR description
Steps to reproduce: =================== 1. Install `pos_restaurant_appointment`. 2. From the Appointments menu, schedule an appointment for tomorrow for a table. 3. Open the restaurant floor plan. Issue 1: ======== - Appointments scheduled for tomorrow are incorrectly shown on the floor plan. Issue 2: ======== - When a customer is late, the appointment label is not displayed in red. Common Cause: ============= - The appointment's `start` field is already a `DateTime` object, but it is being deserialized again, which leads to incorrect time-based comparisons. Fix: ==== - Avoid deserializing the `start` field if it is already a `DateTime` object. Task: 4845006 Forward-Port-Of: odoo/enterprise#86997
This change corrects the provision code used in Swiss payroll salary rules. It helps ensure payroll provisions are calculated and recorded consistently, reducing the risk of incorrect payroll accounting.
Payslips now show the correct weekly hours when an employee uses a flexible working schedule. This prevents payroll documents from displaying outdated schedule hours and improves accuracy for employees and HR teams.
Original PR description
> note: this PR should only be FW'd till `saas~18.4`, after that for `saas~18.5` (i.e., `master`), [this PR](https://github.com/odoo/enterprise/pull/85557) should be merged. ### Steps to reproduce: -…
> note: this PR should only be FW'd till `saas~18.4`, after that for `saas~18.5` (i.e., `master`), [this PR](https://github.com/odoo/enterprise/pull/85557) should be merged. ### Steps to reproduce: - Enable "Flexible Hours" in a working schedule. - Assign the schedule to an employee. - Generate a payslip for the employee. - Observe that the "Working Schedule" section always shows `hours_per_week` from the total hours calculated from the Work Schedule defined before turning on "Flexible Hours" ### Description: - the payslip incorrectly displayed the weekly working hours from the Work Schedule regardless of whether the employee's schedule used flexible hours. ### Cause: - the report template did not check for the `flexible_hours` flag and always rendered the value from `contract_id.hours_per_week`. ### Fix: - added a condition in the payslip template to check if `flexible_hours` is enabled. - if true, it displays `full_time_required_hours` from the working schedule instead of the contract's `hours_per_week`. task: 4719717 Forward-Port-Of: odoo/enterprise#83910
Fixed an issue where exporting the Journal Audit report to PDF could fail when filtering by receivable or payable account types. This ensures users can generate audit PDFs reliably with those common filters applied.
Original PR description
- In the Journal Audit report options, set the Account Type (filter_account_type) to either receivable, payable, or both. - Attempt to export the PDF of the Journal Audit report. A traceback occurs because, in _generate_document_data_for_export, we attempt to add a join using an alias. However, if the filter_account_type option is enabled, there is already a left join in the query with the same alias: account_move_line__account_id. opw-4926547 Forward-Port-Of: odoo/enterprise#91683
Printer tests from the device form now show a clear message if the IoT device does not respond in time. This prevents a confusing error and helps users understand that the communication timed out.
Original PR description
When testing printers from the device form, if no response was received from the IoT after the websocket timeout, we did not provide any message. This resulted in errors when providing `undefined` to the notification service.
The Belgian payroll departure wizards now show only employees from the company the user is currently logged into. This prevents confusion in multi-company environments and helps users select the correct employee when processing departure-related documents.
Original PR description
Added a domain to employees to limit the employee field in the departurre wizard to the logged in company **Steps to reproduce:** - Log into a Blgian Company - Access the Departure wizard through Payroll/Reporting or through the cog actions in an employee. **Issue:** Previously, when using the departure wizard, the employees shown were all the employees across different companies, when in reality it should be employees of the logged in company only **Fix:** Added employee domain so that it allows employees from the current logged in company only Task: 4965719 Forward-Port-Of: odoo/enterprise#92224 Forward-Port-Of: odoo/enterprise#90813
This fix allows Swiss payroll contracts to duplicate monthly wage type entries when needed. It prevents unnecessary blocking during contract setup and helps payroll teams manage valid wage configurations more smoothly.
Original PR description
task-5008742 Forward-Port-Of: odoo/enterprise#92089
21 changes
Resolved issues and error corrections
The Belgian payroll departure wizards now limit employee selection to the company the user is currently logged into. This prevents users from accidentally selecting employees from other companies and helps keep payroll departure processing accurate in multi-company setups.
Original PR description
Added a domain to employees to limit the employee field in the departurre wizard to the logged in company **Steps to reproduce:** - Log into a Blgian Company - Access the Departure wizard through Payroll/Reporting or through the cog actions in an employee. **Issue:** Previously, when using the departure wizard, the employees shown were all the employees across different companies, when in reality it should be employees of the logged in company only **Fix:** Added employee domain so that it allows employees from the current logged in company only Task: 4965719 Forward-Port-Of: odoo/enterprise#92224 Forward-Port-Of: odoo/enterprise#90813
An automated Web Studio test was updated to avoid occasional false failures caused by inconsistent browser event behavior. This helps keep development validation stable without changing the product experience for users.
Original PR description
There was an undeterminism in a test relying on the event beforeunload beign defaultPrevented. For some reason it failed sometimes, probably because of an override somewhere. This commit fixes the problem by asserting other things in the test, arguably even more relevant than before. runbot-error-229754 Forward-Port-Of: odoo/enterprise#92380
The restaurant floor plan now only shows appointments scheduled for the current day, preventing future bookings from appearing too early. Late customer appointments are also highlighted correctly, helping staff identify delayed arrivals at a glance.
Original PR description
Steps to reproduce: =================== 1. Install `pos_restaurant_appointment`. 2. From the Appointments menu, schedule an appointment for tomorrow for a table. 3. Open the restaurant floor plan. Issue 1: ======== - Appointments scheduled for tomorrow are incorrectly shown on the floor plan. Issue 2: ======== - When a customer is late, the appointment label is not displayed in red. Common Cause: ============= - The appointment's `start` field is already a `DateTime` object, but it is being deserialized again, which leads to incorrect time-based comparisons. Fix: ==== - Avoid deserializing the `start` field if it is already a `DateTime` object. Task: 4845006 Forward-Port-Of: odoo/enterprise#86997
Payroll users can now export Belgian Group S work entries for any active company they are allowed to use, instead of being limited to their current company. The export also checks that the selected company has its required Group S code set, helping prevent failed or incomplete payroll submissions.
Original PR description
before this commit only the current company was taken into account when exporting work entries now another company can be selected if multiple companies are active for the current user In addition to that this commit also add a check for the company's group s code to enforce the user to set it before exporting work entries task-4213675 closes old PR: odoo/enterprise/pull/71521 Forward-Port-Of: odoo/enterprise#89438
DHL shipping rate checks during ecommerce checkout now use a planned date in the future, preventing errors caused by same-day timestamps. This helps customers complete checkout more reliably when DHL delivery options are shown.
Original PR description
Before this commit: During checkout on Ecommerce website the default date of the order is current date and time. There is no option to change the date when getting rate. Which results in an error that the date must be in the future. After this commit: `Planned_date` for getting rate is set in furture to avoid the error. Docs reference: https://developer.dhl.com/api-reference/dhl-express-mydhl-api#reference-docs-section under rating endpoints. opw-4849754 Forward-Port-Of: odoo/enterprise#91705
This update adjusts the Planning app's automated split-shift walkthrough so it follows the correct path during testing. This helps ensure the related scheduling workflow remains reliable and reduces the risk of unnoticed issues reaching users.
Original PR description
In this commit, we add steps to ensure the tour take the good way.
Odoo now automatically matches customer account charges and settlements made through Point of Sale. This prevents settled POS amounts from incorrectly appearing as available credit for other invoices, reducing customer account confusion.
Original PR description
### Problem: When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create…
### Problem:
When paying a PoS order using customer account, an account move line debiting Account Receivable will be created. Settling this amount inside the PoS (by depositing money) will create another account move line crediting Account Receivable (represents the payment). The second move line is considered, by Odoo, as an outstanding amount, and this amount can be used to pay another invoice (sale order invoice). The moves affecting Account Receivable are still correct. However, unreconciling the two lines created from PoS will cause a confusion for clients who may use this amount to pay other invoices.
### How to reproduce:
* Open a PoS session.
* Create an order and pay using customer account.
* Settle this customer's account (inside PoS).
* Create a Sale Order and invoice it (or just an invoice).
* The amount settled can be used as outstanding amount and can be used to pay the created invoice.
commmunity PR: https://github.com/odoo/odoo/pull/210619#pullrequestreview-2853451890
opw-4794793
Forward-Port-Of: odoo/enterprise#92374
Forward-Port-Of: odoo/enterprise#86114Fixes an issue where nested grouped lines in accounting reports did not collapse properly and could trigger an error when users folded or unfolded a partner line. This improves report reliability and prevents duplicate lines from appearing during normal report navigation.
Original PR description
Steps to reproduce: - Create an Account Group - Create a new Account Report as follows: * Name: any * Lines: 1. [test line] * Group By: partner_id,account_id * Expressions: 1. [test expression] *…
Steps to reproduce:
- Create an Account Group
- Create a new Account Report as follows:
* Name: any
* Lines:
1. [test line]
* Group By: partner_id,account_id
* Expressions:
1. [test expression]
* Computation Engine: Odoo Domain
* Formula: [('account_id.account_type', '=', 'asset_receivable')]
* Subformula: sum
- Actions > Create Menu Item
- Open the new report
- Try to unfold/fold a partner line
Issue:
Folding will not fold the first child (representing the created account group). Also, error will raise
```
Uncaught Promise > Got duplicate key in t-foreach: ~account.report~37|~account.report.line~255|{'groupby': 'partner_id'}~res.partner~4226|~account.group~90
Occured on odoo.nas.cpolar.cn on 2025-04-26 04:58:53 GMT
OwlError: Got duplicate key in t-foreach: ~account.report~37|~account.report.line~255|{'groupby': 'partner_id'}~res.partner~4226|~account.group~90
Error: Got duplicate key in t-foreach: ~account.report~37|~account.report.line~255|{'groupby': 'partner_id'}~res.partner~4226|~account.group~90
at AccountReport.template (eval at compile (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:13743:20), <anonymous>:138:49) (/web/static/lib/owl/owl.js:5752)
at App.callTemplate (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:11363:50) (/web/static/lib/owl/owl.js:3372)
at AccountReport.template (eval at compile (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:13743:20), <anonymous>:9:12) (/web/static/lib/owl/owl.js:5752)
at RootFiber._render (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:9774:38) (/web/static/lib/owl/owl.js:1783)
at RootFiber.render (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:9766:18) (/web/static/lib/owl/owl.js:1775)
at ComponentNode.render (https://odoo.nas.cpolar.cn/web/assets/debug/web.assets_web.js:10493:23) (/web/static/lib/owl/owl.js:2502)
```
Analysis:
Folding issues occurs because of a mismatch in the grouping markup quote escape. If we don't have the very same string the controller cannot properly recognize the parent line and then is unable to fold/unfold properly.
This eventually led to the mentioned error at unfold as the backend will try to generate the apparently missing lines to unfold, only to create duplicate lines
opw-4754241
Forward-Port-Of: odoo/enterprise#89726A failing automated test in the Saudi payroll module was resolved by assigning the correct HR user access group to an employee field. This helps keep payroll functionality stable and ensures employee information follows the expected access rules.
Original PR description
Issue: - The test case test_employee_fields_groups was failing Reason: - The group on the field was not defined. Fix: - added the group hr.group_hr_user on the field. runbot error: https://runbot.odoo.com/odoo/runbot.build.error/230911
The wording for the project documents folder setting was corrected so it no longer promises that task documents are automatically moved into that folder. This helps users understand the current behavior after document access and organization changes.
Original PR description
Before this commit, the tooltip displayed for `documents_folder_id` defined in `project.project` model, said all documents linked to a task of a project will be automatically added inside that folder but it is no longer the case since the refactoring of Documents to simplify the implementation but also let the documents user sorts his documents as he wants since now the access rights are defined by folder. This commit updates the tooltip accordingly. PR simplifying the bridge between documents and project apps: #75214 opw-5000224 Forward-Port-Of: odoo/enterprise#92189 Forward-Port-Of: odoo/enterprise#92164
Winbooks data imports now continue even when the chart of accounts setup differs from Odoo's default expectations. This prevents import failures and lets users review and adjust the imported draft data inside Odoo afterward.
Original PR description
When importing Winbooks data, if the CoA configuration in Winbooks is different from Odoo's default, users will experience a failure with a message similar to ``` Validation Error Tax Receivable Account (411000 VAT Recoverable) should be an account of type "Receivable" or "Payable" with both options "Allow Reconciliation" and "Non Trade" enabled. ``` This occurs because the account 411000, meant to store the tax provisions, in Winbooks was used as tax receivable. In similar cases we should not raise any error and should let the import go through: the data is imported in draft and the user has the possibility to bring the modifications in Odoo opw-4850314 Forward-Port-Of: odoo/enterprise#91828
Payslips now show the correct weekly hours when an employee has a flexible working schedule. This prevents employees and payroll teams from seeing outdated schedule hours on the payslip.
Original PR description
> note: this PR should only be FW'd till `saas~18.4`, after that for `saas~18.5` (i.e., `master`), [this PR](https://github.com/odoo/enterprise/pull/85557) should be merged. ### Steps to reproduce: -…
> note: this PR should only be FW'd till `saas~18.4`, after that for `saas~18.5` (i.e., `master`), [this PR](https://github.com/odoo/enterprise/pull/85557) should be merged. ### Steps to reproduce: - Enable "Flexible Hours" in a working schedule. - Assign the schedule to an employee. - Generate a payslip for the employee. - Observe that the "Working Schedule" section always shows `hours_per_week` from the total hours calculated from the Work Schedule defined before turning on "Flexible Hours" ### Description: - the payslip incorrectly displayed the weekly working hours from the Work Schedule regardless of whether the employee's schedule used flexible hours. ### Cause: - the report template did not check for the `flexible_hours` flag and always rendered the value from `contract_id.hours_per_week`. ### Fix: - added a condition in the payslip template to check if `flexible_hours` is enabled. - if true, it displays `full_time_required_hours` from the working schedule instead of the contract's `hours_per_week`. task: 4719717 Forward-Port-Of: odoo/enterprise#92441 Forward-Port-Of: odoo/enterprise#83910
XLSX files converted into Odoo spreadsheets now automatically limit portal users to view-only access. This prevents conversion failures when files come from shared folders where portal users previously had edit rights, keeping spreadsheet creation smoother and access rules consistent.
Original PR description
Let's say a Document Folder is shared with a portal user with 'edit' access. The portal user shares a .xlsx file to the folder, and an internal user later try to convert the file to odoo spreadsheet. During the conversion, the portal user has 'edit' role on the folder, which is copied to the documents.access records of the converted sheet. Since Odoo prevents Spreadsheets from being shared in edit mode to portal users, _check_spreadsheet() raises a Validation Error. <img width="544" height="188" alt="image" src="https://github.com/user-attachments/assets/48426ff8-0cd9-4fb0-8e52-31099e586064" /> To resolve this issue, we force portal users to have `view` role on Spreadsheets during the XLSX to Spreadsheet conversion. opw-4753670 Forward-Port-Of: odoo/enterprise#92427 Forward-Port-Of: odoo/enterprise#92134
This update fixes an incorrect provision code in the Swiss payroll configuration. It helps ensure payroll calculations and reporting use the right setup, reducing the risk of payroll processing errors.
Original PR description
Forward-Port-Of: odoo/enterprise#92477
Printer tests from the device form now handle cases where the IoT device does not respond in time. Instead of causing an unclear system error, users receive a proper notification, making troubleshooting smoother.
Original PR description
When testing printers from the device form, if no response was received from the IoT after the websocket timeout, we did not provide any message. This resulted in errors when providing `undefined` to the notification service. Forward-Port-Of: odoo/enterprise#92391
Users can now sign documents directly from the chatter without losing the document reference. This prevents signing actions from failing or opening with missing context, making the workflow more reliable.
Original PR description
Before this fix, when a user signed a document from the chatter, the reference_doc context was not passed correctly. This PR ensures the context is properly set so signing from chatter works as expected.
The accounting automation now runs under the correct company context, preventing exchange rates from being applied for the wrong company. This helps keep bank statement reconciliation and currency-related accounting values accurate in multi-company setups.
Original PR description
In this commit: https://github.com/odoo/enterprise/pull/89244/commits/788d79cea3c2d45582e16b25847c7821a6521da1 we fixed a bug where the cron would be trigger with the wrong company which impacted the currency rate. We decided to put the change in the try_auto_reconcile, but it was a bit of code duplication so this commit will refactor that. Task-4933083 Forward-Port-Of: odoo/enterprise#92016 Forward-Port-Of: odoo/enterprise#90305
A timesheet holidays test was updated so it no longer fails depending on the time of day or user timezone. This improves reliability of automated checks without changing customer-facing behavior.
Original PR description
Before this commit, when the `test_timer_methods_handle_project_access_restrictions` test is executed after 22h in UTC the test failed because the timezone of the current user is the belgian one. This commit makes sure the date and timezone no longer affects this test since it is not the purpose of this test. runbot-error-230490 Forward-Port-Of: odoo/enterprise#92264
The Belgian payroll employee form now places the “Seniority at hiring” field under Education instead of Citizenship. This makes the information easier to find in the section where users are more likely to expect it, with no change to payroll calculations or employee data.
Original PR description
Move Seniority at hiring from Citizenship to Education group in employee form. In this PR, we moved seniority at hiring from the Citizenship to the Education group in the employee form. Related task: 4936767. Forward-Port-Of: odoo/enterprise#90137
Peru PLE reports 5.1 and 6.1 now keep the original account move name in the report description instead of removing spaces or slashes. This helps ensure submitted reports retain the full original information, reducing audit-related risk with tax authorities.
Original PR description
Problem: For PLE reports 5.1 and 6.1, the value for `glosa` was being modified (i.e. blank spaces and slashes removed). Although SUNAT accepts the modified value, no information should be removed in the case it might lead to issues with tax authorities during an audit. Solution: The value for `glosa` on the reports should be the exact account move name. opw-4803060 Forward-Port-Of: odoo/enterprise#92271 Forward-Port-Of: odoo/enterprise#91967
Manufacturing users can now stop work orders that run longer than expected without hitting an access error related to analytic accounting entries. This prevents production workflows linked to billable projects from being blocked for users who do not have accounting permissions.
Original PR description
To reproduce:
=============
- create a BOM with an operation having an expected duration
- make sure the product of BOM has MTO and Manufacturing routes
- create a Billable project with visibility=portal
- create an SO with the product of BOM and set the project for analytic distribution
- confirm the SO -> a MO is created
- with a user having:
- hr.group_hr_user
- mrp.group_mrp_manager
- project.group_project_user
- hr_timesheet.group_hr_timesheet_approver
- go to the MO and start the first operation and wait to exceed the expected duration
- stop the operation -> access error on the analytic account line
Problem:
========
when the user tries to stop the operation, at first moment AAL will be created, as we exceed the expected duration, we will try to update the AAL which leads to an access error as the user does not have accounting rights.
Solution:
=========
deal with AAL records as sudo
opw-4897142
Forward-Port-Of: odoo/enterprise#9242236 changes
Resolved issues and error corrections
Account move imports with analytic allocations now avoid creating duplicate analytic entries. This keeps imported accounting records cleaner by ensuring the analytic entry is only created when the move is posted, while preserving the imported allocation details.
Original PR description
When importing an account move with analytic distribution, two analytic items are created, one at the creation of the move, and another when the move is posted. This happens because, when creating the move from an import, the line values passed include Commands to create analytic_line_ids, and not analytic distributions. Desired behavior: Only one analytic item should be created, and only when the move is posted. When the move is created, its lines' analytic distribution should be correctly filled based on the data imported. Solution: This commit unlinks the Analytic Lines created at move imports (removing the analytic_line_ids from moves at create/write), after the analytic distribution is set on the corresponding move line. task-4987799 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an accounting issue where some batch payments could remain stuck instead of being marked as reconciled. The correction ensures payment matching status is recalculated when related payment information changes, improving reliability in bank reconciliation workflows involving early payment discounts.
Original PR description
In the goal of fixing the batch payments with EPD in the bank rec widget, we discovered another bug that was preventing the batch payments to change their state to "reconciled". This was due to some compute not being triggered again when one of its dependences did change (during another compute). task-4681366
Edited attendance records that were originally created as absences now update their status when check-in or check-out times are corrected. This prevents corrected attendances from continuing to appear as absences, reducing confusion for HR users.
Original PR description
### Steps to reproduce: - Run Absence detection cron - Navigate to the attendances got created in list view - Notice all of them are in red color - Modify the check in and check out dates to correct them as normal attendance - Notice the color didn't change in the view and it is still shows as red ### Cause: This is happening because color of the record is dependant on the check out mode, so if it is technical it means it is absence so we give it red color. https://github.com/odoo/odoo/blob/a7a29ed691db4f1607c0d12929c56845681164fa/addons/hr_attendance/models/hr_attendance.py#L84-L89 Also, the check out mode cannot be changed in any way. ### Fix: When updating the check out and check in time we check if the mode is technical we change it to manual. opw-4865524
The Attendance kiosk no longer incorrectly shows all check-in options for a company website using a public user without a password. This keeps the kiosk experience aligned with the company's configured Barcode/RFID setting and avoids confusing employees during check-in.
Original PR description
### Steps to reproduce: - Install Attendance and Website modules - Have a company 'Company A' - Create a new company 'Company B' - Set the Attendance kiosk mode to 'Barcode / RFID' for both companies…
### Steps to reproduce: - Install Attendance and Website modules - Have a company 'Company A' - Create a new company 'Company B' - Set the Attendance kiosk mode to 'Barcode / RFID' for both companies - Update all websites to be related to Company B - Go to the Kiosk mode for Company B - Notice it makes you choose between the 3 check in types while we only chose 'Barcode / RFID' ### Cause: When openning the kiosk mode it will check if the database is a trial one or if the user doesn't have a password and if so we assume that the database is a trial one. If it is a trial database we set the kiosk mode as 'settings' which shows all check in types when openning the kiosk mode. https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/hr_attendance/controllers/main.py#L101-L102 https://github.com/odoo/odoo/blob/9ec4e0d3c5f1aaff0b36dc5def1e69b8285c3be1/addons/hr_attendance/controllers/main.py#L185-L196 When creating a new company and set website for it we create a public user for this company and normally we don't set password for this user as no one is gonna login using it. ### Fix: We check if the user doesn't have a password and if he is not a public user. As we assume that if he is a public user he won't have a password anyways. opw-4916329
Grouped supplier bill payments now keep a memo made from all individual payment memos. This ensures suppliers receive the expected payment communication details and avoids confusion caused by internal workflow changes.
Original PR description
The payment memo of grouped bills should always consist of the concatenation of individual payments memos. This commit is a partial revert of the changes done in this PR https://github.com/odoo/odoo/pull/162762 The original task was intended to improve internal workflows and should not have impacted payment communications to suppliers. task-4936572 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where deliveries for kit products could fail after the customer invoice was already confirmed. Businesses can now invoice and deliver kits alongside their components without accounting reconciliation errors blocking the delivery process.
Original PR description
#### *mrp_account, purchase_{stock, mrp}, sale_{stock, mrp} ### Steps to reporduced: - In the settings enable: Automatic Accounting - Create 3 storable product: - COMP1, cost 1 $ - COMP2, cost 2 $ -…
#### *mrp_account, purchase_{stock, mrp}, sale_{stock, mrp}
### Steps to reporduced:
- In the settings enable: Automatic Accounting
- Create 3 storable product:
- COMP1, cost 1 $
- COMP2, cost 2 $
- KIT with a kit bom using COMP1 and COMP2, cost 3 $
- Modify the product category of all three products to:
- Costing Method: AVCO
- Inventory Valuation: Automated
- Create and confirm a sale order with 2 lines:
- 1 x KIT
- 1 x COMP2
- Create and confirm the associated invoive
- Try to validate the delivery
#### > UserError: You are trying to reconcile some entries that are already reconciled.
### Cause of the issue:
Validating the delivery will create stock valuation layers related to the associated stock moves — one for COMP1 and two for COMP2 — and then attempt to validate the corresponding accounting entries: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/stock_move.py#L283-L291
However, during this call, the SVLs are grouped by product_id: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/stock_valuation_layer.py#L88-L93
As a result, the first time we enter the loop, the accounting entries related to COMP01 will not be reconciled by the
`_stock_account_anglo_saxon_reconcile_valuation` call. This is because we restrict this call using the product COMP01. Therefore, we will not find the invoice needed to reconcile the outgoing moves here: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/account_move.py#L217-L219 (This happens because the related line of the invoice actually refers to the kit product, as the AMLs were not exploded like the stock moves.)
Now, the issue is that, since the AMLs were not reconciled, they will be added to the pool of lines to be reconciled later: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/stock_account/models/stock_valuation_layer.py#L92-L100
However, the second time we enter the loop — for COMP02 — since COMP02 was sold by itself, there will be an account move line referring to this product on the invoice. The `_stock_account_anglo_saxon_reconcile_valuation` call, now restricted to COMP02, will therefore reconcile the AMLs for both COMP02 and COMP01 related to the kits (as it successfully finds the invoice to reconcile all outgoing moves). This is problematic because the AML related to COMP01 has now been reconciled, despite already having been added to the set of moves to be reconciled. This will raise an error during the second reconciliation attempt: https://github.com/odoo/odoo/blob/596937dfef4d203b0cbf5431e71a97f60154d7cb/addons/account/models/account_move_line.py#L2379-L2380
### Fix:
In the case of kit products, the account move lines of the invoice refer to a different product than the stock valuation layers (because the stock move was exploded but not the AMLs). Therefore, it is important to refer to the kit product during the reconciliation process.
We achieve this by grouping the SVLs using the product of their associated SOL or POL. Unfortunately, we cannot rely on the product from the BoM related to the stock move of the SVL, as kits can be nested within one another. In such cases, the invoice related to the SO or the bill related to the PO would not refer to the intermediate kit we would found that way.
opw-4864925
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#221337This fixes an issue where some badge images could appear much larger after entering edit mode on course pages. Image dimensions are now preserved correctly during content cleanup, helping editors see pages as intended.
Original PR description
Problem: On the Courses page, the user rank badge image becomes much larger when entering edit mode. Cause: During HTML sanitization, `img.width` is removed and its value is moved to `img.style.width`. If `img.width` is a number (e.g., `100`), it is interpreted as `100px`. However, when assigned to `img.style.width` without a unit, the style is considered invalid, and the image defaults to its original size. The same applies to `img.height`. Solution: When transferring width or height to style, ensure a unit is added. If the original attribute is a plain number without a unit, default to `px`. Steps to reproduce: - Open Website > Courses - Observe the user rank badge is appropriately sized - Enter edit mode > The badge image becomes much larger than expected opw-4993038 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Point of Sale now correctly follows the auto-validation setting when a cashier uses Force Done on a terminal payment. This prevents checkout from getting stuck and sends the cashier to the receipt screen as expected.
Original PR description
When doing a force done on a terminal payment, if the auto validation was turned on, it would not be triggered after clicking on the force done button. Steps to reproduce: ------------------- * Turn on the auto validation for terminal payments * Create a new order and add a product * Select a terminal payment method (You can fake the force done state as I did in the tour) * Click on the "Force Done" button > Observation: You are not redirected to the receipt screen. opw-4954406
Odoo now prevents Razorpay payment providers from being enabled and published unless the required account credentials are configured. This reduces setup mistakes that could leave a payment option visible to customers but unable to process payments.
Original PR description
## Version 17.0+ No OAuth in 16.0 ## Issue Razorpay can be enabled and published without being properly configured. ## Steps to reproduce - Go to `Payment Providers` and open `Razorpay`; - Set the state to `Enabled` and publish without providing any credentials. ## Fix Added constraints and revised account linking logic, similar to Stripe. Based on 1b6a7aeb245f0007675943ed7aacf5064e46fe61 suggested by ALSH. opw-4922315 Forward-Port-Of: odoo/odoo#219943
The Time Off dashboard now uses an employee's active running contract when calculating working schedules and holiday days. This prevents incorrect balances when an employee has overlapping contracts, such as one active part-time contract and one future or draft full-time contract.
Original PR description
Steps: -Install the hr_holidays_contract module - Create two contracts for the same employee: - Contract A (Part-time) starting from 01/01/2025 and set to Running - Contract B (Full-time) also starting from 01/01/2025 and set to New - open holiday dashboard for that employee Description of the issue/feature this PR addresses: The Time Off dashboard incorrectly considers the full-time contract instead of the part-time one, even though the part-time contract is in the running state. Cause: The contract selection logic did not correctly prioritize the running contract when multiple contracts existed for the same period. Fix: This PR updates the logic to ensure that: - If a contract is in the running state at a given time, it is used to determine the working schedule and time off calculations. - If no contract is running during that time and multiple contracts exist, the contract with the latest creation_id will be considered. task-4724155
The web interface now prevents record-opening behavior from interrupting selection dialogs. This ensures users choosing a record through “Search more” can select it as intended instead of being taken to an unrelated form view.
Original PR description
Example of steps: - install web, purchase and studio - add a many2one with studio anywhere and choose purchase.order.line - close studio - try to use this new field, select "Search more" - select a random record - It opens the form view record instead of select It This is because purchase order line has an openAction that forces the opening of a form view. However, for a select_create_dialog, we must bypass this action to allow nothing except selection. To do this, a new prop has been added, “allowOpenAction,” in the list_controller, which will be true by default, but will be false for select_create_dialog. opw-4958121
The website settings newsletter option now correctly displays the subscription checkbox for guest shoppers during checkout, even when the checkout page has been customized. This prevents missed newsletter sign-up opportunities and keeps the checkout experience consistent.
Original PR description
Reproduction Steps: --------------------------------------------------- To reproduce the issue first we need to create cowed view, follow the steps below: - Ensure that the website and…
Reproduction Steps: --------------------------------------------------- To reproduce the issue first we need to create cowed view, follow the steps below: - Ensure that the website and website_sale_mass_mailing modules are installed. - Navigate to Website > Shop. - Select any product and add it to the cart. - click on Proceed to checkout then checkout. - On the checkout page, you will see the address form. - Click on "Add a new address". - Now "Edit" the website page (e.g., make the City label bold). This will create a cowed view for the address page. Now, follow the final steps to reproduce the actual issue: - Enable the "Newsletter" option from Website Settings. - Log out of the database. - Go to the website shop, add a product to the cart, and proceed to checkout. - On the address page, the subscription checkbox is not visible for a "Guest" user. Root Cause: -------------------------------------------- The subscription checkbox does not appear because the cowed view of the newsletter is not activated. Solution: --------------------------------------- As of SaaS 17.3, a new module `website_sale_mass_mailing` was introduced, which adds the "Newsletter" option in Website Settings. When this option is enabled, the newsletter view is automatically activated. However, the corresponding cowed views are not automatically activated, causing the subscription checkbox to be missing during guest checkout. To fix this, we ensure that the corresponding cowed view is also activated when the "Newsletter" option is enabled. Related Link: https://github.com/odoo/odoo/pull/154604/files OPW-4860002 UPG-2978748 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an error that occurred when a user removed a product from the parts list on a repair order and then changed the customer. This prevents an unexpected crash during normal repair order editing and makes the workflow more reliable.
Original PR description
When User removes the product from parts in repair order and tries to change the partner, A traceback will appear. Steps to reproduce the error: - Install ``repair`` module - Create new repair order > Add a line > Add a product in parts > Save - Remove product from parts > change customer > Save Traceback: ``` AssertionError: precision_rounding must be positive, got 0.0 ``` https://github.com/odoo/odoo/blob/122dece7eeedbf670254aebd2a2d69642b381547/addons/repair/models/repair.py#L319 When user removes the product from parts, ``precision_rounding`` becomes 0.0 Which results in the above traceback. sentry-6650889934 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where website links meant to be absent could become empty links when a CDN was enabled. It prevents the shop address form submit button from triggering an unintended page refresh, making checkout address submission more reliable.
Original PR description
In QWeb, when using `t-att-href='None'`, the attribute is omitted from the DOM. However, when a CDN is used, `None` is converted to an empty string (`''`) by `get_cdn_url`. This is a follow-up to commit 3e9c953. This fix addresses an issue on the `/shop/address` page where the "Submit" button had `href=''`, causing JavaScript event handling to break due to a race condition triggered by a page refresh during form submission (POST).
This update brings Odoo’s spreadsheet component up to the latest version and fixes issues affecting pivot table measures and OFFSET formula recalculations. Users should see more reliable spreadsheet results, especially in reports and analyses that depend on pivots or dynamic formulas.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ec79db448 [REL] 18.0.40 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/ec79db448 [REL] 18.0.40 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/76b039095 [FIX] Pivot: sanitize measure id [Task: 4876828](https://www.odoo.com/odoo/2328/tasks/4876828) https://github.com/odoo/o-spreadsheet/commit/4e8a7908a [FIX] Functions: OFFSET dependencies are not correctly added [Task: 5001405](https://www.odoo.com/odoo/2328/tasks/5001405) https://github.com/odoo/o-spreadsheet/commit/07aff72b3 [IMP] demo: Add error handler [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/997e25a1a [REL] 18.0.39 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya <rmbh@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
This fix prevents invoices from failing when early payment discount settings are changed after an invoice has already been posted. It adds a safety check so missing discount dates no longer cause an error during payment reconciliation or eligibility checks.
Original PR description
Although unsure how, it seems that we can reach a way where the first payment term's discount date is False. We now add a check of its existence before comparison and a fallback on the latest discount date if it does not yet exist. opw-4982286
This update fixes a failing automated test for the HTML editor toolbar in the community edition. It helps keep quality checks reliable by accounting for differences between community and enterprise versions, with no direct change to user-facing features.
Original PR description
Turns out the test only failed in community and none of my previous fixes could have solved it because the issue is that the sizes are not all the same between community and enterprise. I'm not sure if this is intended but that will be the subject of another task. In this PR I focus in fixing this test that fails deterministically in community. runbot-230955
This change prevents a payment registration test from failing when the demo payment module is not installed. It adds a check before using the demo payment provider, making test results more reliable in leaner installation setups.
Original PR description
Add module installation check before using "demo" as payment provider to generate payment token for payment register test case. Steps to reproduce: 1. Install single module (website_sale). 2. Run test case `TestAccountPaymentRegister.test_register_payment_doesnt_send_email`. You will get ValueError: Invalid field 'demo_simulated_state' on model 'payment.token' build_error-230731
This fixes a display issue where the showcase block in email marketing could appear stacked in received emails on large screens, even though it looked correct in the editor. The change keeps the layout side-by-side as intended, improving consistency between email design and delivery.
Original PR description
Problem: On large screens, the `s_showcase` template shows blocks stacked vertically instead of side-by-side as in the editor. Cause: After commit 10008b32334152ada1a847b091189d1d9d5aa3d3,…
Problem: On large screens, the `s_showcase` template shows blocks stacked vertically instead of side-by-side as in the editor. Cause: After commit 10008b32334152ada1a847b091189d1d9d5aa3d3, `s_showcase` was refactored to fix selection/formatting issues. Mixing relative widths (`col-sm`) with fixed widths (`col-1`) breaks in `convert_inline`, exceeding the 12-column grid. Solution: - Use `Math.floor` when calculating the `colSize` to prevent overflow Before: <img width="1862" height="948" alt="image" src="https://github.com/user-attachments/assets/35d82103-1f84-4754-862d-50ef3481bcb3" /> After: <img width="1847" height="955" alt="image" src="https://github.com/user-attachments/assets/20e1b454-dfc4-4ad0-9e6a-3b38c230d0fd" /> Steps to reproduce: 1. Open a new email marketing. 2. Drop the `s_showcase` snippet. 3. Send a test email. 4. Observe the received template is misaligned compared to the editor. opw-4946126 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Fixes an accounting issue where invoice journal item amounts could be recalculated incorrectly if a user switched from a foreign currency to the company currency and then back before saving. This helps ensure balances and currency amounts remain accurate, reducing the risk of incorrect accounting entries.
Original PR description
Steps to reproduce: - Enable a foreign currency with rate - Create an invoice in foreign currency - Switch to company currency, then back to foreign currency before saving - Check journal items values Issue: Amount currency and balance have been affected by the currency rate even if the original currency was restored before saving opw-4864994 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fixes an issue where website configuration could fail if the website name contained special characters such as a backslash. Businesses can now complete theme and palette setup reliably even with unusual characters in the website name.
Original PR description
Currently, using special characters like backslashes `(\)` in the website name would cause a regex substitution error during website configuration. **Steps to Reproduce:** - Install the `website`…
Currently, using special characters like backslashes `(\)` in the website name would cause a regex substitution error during website configuration. **Steps to Reproduce:** - Install the `website` module. - Go to Settings and change the website name (e.g; "`test\`"). - Navigate to the URL: "http://localhost:8069/website/configurator" - Select a theme and a color palette for the website, then apply the changes. Error: `error - bad escape (end of pattern) at position 19` **Cause:** At [1], a backslash in the `website.name` string leads to a malformed replacement string in `re.sub()`, causing a regex syntax error due to an invalid escape sequence. [1]: https://github.com/odoo/odoo/blob/b8edcd131b3288d037bee9ee03726153932d82f1/addons/website/models/website.py#L678 **Fix:** This PR escapes the `website.name` using `re.escape()` before using it in regex substitution, prevents runtime errors during website configuration. sentry-6651288996,6557563272 Forward-Port-Of: odoo/odoo#213083
Payroll exports now check required work entry codes before generation and show clear user-facing errors instead of failing unexpectedly. This helps Belgian payroll teams identify missing setup for providers such as Group S, Acerta, Partena, Prisma, SD Worx, and UCM before sending exports.
Original PR description
Before this commit no usererror was raised when the work entry type has no group s code defined which caused the export to fail. This commit adds a check at generation time for the work entry type to have a group s code defined task-4241431
Batch payments in bank reconciliation now show the full related invoice or journal entry amount instead of only the paid amount. When an early payment discount applies, the widget also displays the discount line, making reconciliation totals clearer and more accurate for finance users.
Original PR description
In the bank reconciliation widget, it is now possible to have batch payments containing payments linked to only invoice_ids. Such batch payment, once mounted in the widget, should reflect the invoice or move amounts of its payments, and not only the payments amount. In the case of a payment-invoice combo that's elligible for an early payment discount, the early payment discount should also be displayed in the widget. Example: Invoice of 1000$ with possible EPD of 2%. A payment (with no move) is done (paid in the "early" period) for 980$. The payment is then put into a batch payment. Once in the bank rec widget, when mounting the 980$ batch payment to a statement line of 980$, the widget should display it as a batch payment line of 1000$ and add another 20$ Early payment Discount line. task-4681366
Dutch VAT payment wizards now use the Omzetbelastingnummer when it is available, instead of always relying on the company VAT number. This prevents incorrect payment communication references and helps Dutch companies submit tax payments with the right identifier.
Original PR description
**Steps to reproduce:** - Install Accounting, l10n_nl and l10n_nl_reports_sbr_ob_nummer - Switch to a Dutch company (e.g. NL Company) - In company form, set VAT and Omzetbelastingnummer - Create an…
**Steps to reproduce:** - Install Accounting, l10n_nl and l10n_nl_reports_sbr_ob_nummer - Switch to a Dutch company (e.g. NL Company) - In company form, set VAT and Omzetbelastingnummer - Create an invoice with tax for previous month - Confirm the invoice - Go to "Accounting / Reporting / Statement Reports / Tax Return" - Select previous month - Create "Closing Entry" and post it - On "Miscellaneous Operations" journal in Accounting dashboard, click on "Pay tax: [date]" link - A wizard will appear fot the VAT payment **Issue:** The value of the "Communication" field is incorrect. **Cause:** The "Communication" field is always computed from the VAT of the company. However, when the "Omzetbelastingnummer" field is set, it should be used instead of the VAT. **Solution:** Use the "Omzetbelastingnummer" field to compute the "Communication" of the VAT payment when it is set. This is done through an overridden method because "Omzetbelastingnummer" is defined in an independent module. opw-4836615
When an applicant is hired through the salary configurator, their skills are now transferred to the new employee record. This prevents HR teams from losing useful hiring information and avoids manual re-entry after onboarding.
Original PR description
Originally, an applicant, who became an employee through the salary configurator flow, loses his skill info. So, the migration of applicant information, through the salary configurator flow, to employee view has been adjusted.
Fixes an access error that could block manufacturing users from stopping work order operations linked to billable projects. This ensures production time can be recorded reliably even when the user does not have accounting permissions.
Original PR description
To reproduce:
=============
- create a BOM with an operation having an expected duration
- make sure the product of BOM has MTO and Manufacturing routes
- create a Billable project with visibility=portal
- create an SO with the product of BOM and set the project for analytic distribution
- confirm the SO -> a MO is created
- with a user having:
- hr.group_hr_user
- mrp.group_mrp_manager
- project.group_project_user
- hr_timesheet.group_hr_timesheet_approver
- go to the MO and start the first operation and wait to exceed the expected duration
- stop the operation -> access error on the analytic account line
Problem:
========
when the user tries to stop the operation, at first moment AAL will be created, as we exceed the expected duration, we will try to update the AAL which leads to an access error as the user does not have accounting rights.
Solution:
=========
deal with AAL records as sudo
opw-4897142When validating a batch payment, Odoo no longer logs a misleading message saying a payment was removed when it actually remains in the batch. This keeps the activity history accurate for users reviewing payment processing.
Original PR description
When validating a batch that includes payments in process (e.g., without journal entries), Odoo incorrectly logs that the payment was removed from the batch, even though it remains. This commit fixes the chatter message by not possessing the write method of the account_payment if batch_payment_id not in vals. task-5011672
Fixed an issue in Studio's report editor where adding a column to a customized table could introduce unwanted spacing. New table cells now use a simpler layout container, helping reports stay properly aligned.
Original PR description
Before this commit when adding a column into a modified qweb table (q-table node) we inserte a `p` as the cell's first child. This was problematic as a margin was always present, messing with the whole table alignment. After this commit, we put a simple DIV. task-5005441
Egyptian payroll tax calculations now apply the exempt amount before calculating income tax. This helps prevent employees from being overtaxed and improves payroll accuracy.
Original PR description
Issue: - The income tax calculation in Egyptian payroll did not properly account for the exempt amount. - This could result in over-calculating tax for employees by not applying the exemption. Fix: - Updated the 'Taxable Amount' salary rule to correctly apply the exempt amount before tax is calculated. Task-4815156
This fixes a Swiss payroll contract issue where monthly wage type entries could not be duplicated when needed. Businesses can now maintain contract wage details more accurately for Swiss ELM payroll reporting without being blocked by the system.
Original PR description
task-5008742 Forward-Port-Of: odoo/enterprise#92089
Batch payment reconciliation now skips bill or invoice installment lines that have already been reconciled. This prevents errors when paying and reconciling multiple installments from the same bill, allowing accounting teams to complete staged payments normally.
Original PR description
**Steps to reproduce:** - Install accountant - Go to "Accounting / Configuration / Invoicing / Payment Terms" - Create a payment term having at least 2 installments (e.g. 20%-80%) - Create a bill: *…
**Steps to reproduce:** - Install accountant - Go to "Accounting / Configuration / Invoicing / Payment Terms" - Create a payment term having at least 2 installments (e.g. 20%-80%) - Create a bill: * Vendor: [any] * Payment terms: [the created payment term] * Amount: 1000 - Confirm the bill - Pay the first installment from the bill (i.e. 200) - Go to "Accounting / Vendors / Payments" - Select the payment and create a batch - Validate the batch payment - From Accounting dashboard, go to Bank journal - Create a statement: * Partner: [None] * Amount: -200 - Reconcile the statement with the batch payment - From the bill, pay the second installment (i.e. 800) - Go to "Accounting / Vendors / Payments" - Select the payment and create a batch - Validate the batch payment - From Accounting dashboard, go to Bank journal - Create a statement: * Partner: [None] * Amount: -800 - Reconcile the statement with the batch payment **Issue:** The following UserError is raised: "You are trying to reconcile some entries that are already reconciled." **Cause:** When reconciling a batch payment, all the payment term lines from the invoices/bills linked to the payment are used. However, in this case, when the first batch payment has been reconciled, the first payment term line of the bill (linked to the first installment) has been reconciled. It should not be reused when reconciling the second batch payment. **Solution:** Exclude reconciled payment term lines when reconciling a batch payment. opw-4830185
DHL shipping rate requests during ecommerce checkout now use a planned date in the future. This prevents customers from seeing an avoidable DHL error when rates are calculated with the current date and time.
Original PR description
Before this commit: During checkout on Ecommerce website the default date of the order is current date and time. There is no option to change the date when getting rate. Which results in an error that the date must be in the future. After this commit: `Planned_date` for getting rate is set in furture to avoid the error. Docs reference: https://developer.dhl.com/api-reference/dhl-express-mydhl-api#reference-docs-section under rating endpoints. opw-4849754 Forward-Port-Of: odoo/enterprise#91705
Preparation display category settings now also cover products in their subcategories. This ensures kitchen or preparation teams see all relevant orders without needing every subcategory selected manually.
Original PR description
Issue: Before this commit the subcategries of the selected categories in a preparation_display config were not taken into account. Task-4841345
This fix removes an internal step that could release record locks too early when sending Mexican electronic invoices. It lowers the risk of the same invoice being sent twice to SAT, while keeping error handling and logging in place for timeout cases.
Original PR description
Following PR odoo/enterprise#89397 with commit 062f98ea1f2df7cff45fc0a9a88abcd99d0adc1e, we did an intermediary commit to make sure we store the post_time before sending. But the sending itself…
Following PR odoo/enterprise#89397 with commit 062f98ea1f2df7cff45fc0a9a88abcd99d0adc1e, we did an intermediary commit to make sure we store the post_time before sending. But the sending itself catches the exception for timeout, ... so the only case where it would fail is if our own servers crash (through an all destructive fire e.g., which is a very small risk). Otherwise they would save the error without returning it. The bigger danger however is that when you do a commit, you lose the locking on the records that were done, so you effectively risk sending the same record twice at the same time because the locking is not active anymore during the sending. Even if the Odoo invoice name is the same, it is interpreted by the SAT as 2 different invoices. Of course, if we have a timeout and it is sent again, we will have a duplicate, but the user should be alerted about it as exceptions are caught and put in the error message. We added however logging for all those cases to be able to follow it up. opw-4980638, ...
The salary configurator now keeps dependent options unavailable when required related fields are empty or disabled. This helps prevent employees or HR users from selecting incomplete or invalid salary benefit combinations.
Original PR description
When opening the salary configurator, fields that depend on mandatory fields that are disabled/empty should also be disabled/empty. This is fixed by removing unnecessary code and a variable overridden 'mandatoryBenefitSelected'. Task: 4926209 Forward-Port-Of: odoo/enterprise#90539
Fixed an issue where previewing different linked YouTube documents could always show the most recently added video instead of the selected one. Users can now reliably preview the correct linked document, reducing confusion when managing multiple shared links in Documents.
Original PR description
**Steps to reproduce:** 1. Go to Documents > Click ⬇ beside Upload > Add a Link 2. Add two different YouTube video URLs with above steps 3. Preview the first link, then the second **Issue:** Previewing individual YouTube links always displays the preview of the *last* added video, regardless of which one was clicked. **Cause:** When a document has no `attachment_id`, the preview fallback logic defaults incorrectly, causing all documents to share the same preview source. **Solution:** Updated `getRecordAttachment` to prioritize `attachment_id` but gracefully fallback to `rec.resId` and `rec.data.name` when missing. This ensures document preview works even when the record has no linked attachment. opw-4906808 Forward-Port-Of: odoo/enterprise#90388