Daily updates from Odoo
Tuesday, March 24, 2026
16 changes · master
Resolved issues and error corrections
This update disables the automatic refresh of GST tokens for the Russian localization (l10n_in_reports) module. Previously, tokens refreshed every 5 hours, but now they are permanently disabled. Manual triggering of the refresh process is now required, ensuring compliance with current regulations.
Original PR description
With this PR, the GST token refresh cron interval is updated from 5 hours to 9999 months to effectively disable automatic execution. The cron will instead be triggered manually from `validate_otp` and `_cron_refresh_gst_token` based on the token expiration time. Forward-Port-Of: odoo/enterprise#109937
This update resolves an issue where default values weren't consistently applied to VoIP call records. By reverting to a method that triggers Odoo's retry mechanism on unique constraint violations, the system now reliably handles potential errors and ensures data integrity. This improves the overall stability of the VoIP functionality.
Original PR description
Since 2d406b71cf17d91baa30070899515f22f5ec3222, voip.call records are created using a raw SQL query rather than the ORM. This has the side effect of not applying the default values. The main reason it was done with a raw SQL query was to be able to leverage Odoo default retry mechanism on unique constraint violation, since `UniqueViolation` exception doesn't normally trigger a retry. This commit reverts the approach to using the ORM, and raises a `ConcurrencyError` on `UniqueViolation`. The `ConcurrencyError` triggers the retry mechanism, allowing for the same behavior as the raw SQL query, while keeping the ORM features (e.g. default values). [Task-6036473](https://www.odoo.com/odoo/project/5778/tasks/6036473) Forward-Port-Of: odoo/enterprise#111104
This update corrects a visual discrepancy between the AI live chat snippet editor and its actual display on the website. The fix ensures that the AI snippet appears correctly across different devices and configurations, resolving a rendering issue. This improves the user experience and consistency of the AI live chat feature.
Original PR description
Scenario: - add ai livechat snippet block - switch to mobile - enable "Fallback Button" - save Result: the rendering is different between edition and real usage of AI livechat snippet. Cause: structure and classes don't match Fix: make the structure and classes match. opw-5458575 pr note: I copied `ai_website_livechat.AILivechatComponent` in `ai_website_livechat.s_ai_livechat_edit` but it might make more sense to just render the owl widget with a class that neuter the AI (this way we don't need to update both template at each change) Forward-Port-Of: odoo/enterprise#109569
This update fixes an issue where project timesheets didn't accurately reflect changes in employee assignments on manufacturing orders. The fix automatically updates the AAL (analytic accounting line) associated with the work center when an employee is switched, ensuring accurate time tracking and reporting. This improves the reliability of project cost data.
Original PR description
### Steps to reproduce: - Create an MTO product and another Service product that create a project and task - Create a quotation with both products - Create two employees with different hourly cost - Go to Manufacturing order - Configure an employee to manufacture the product at a work station. - Observe the project dashboard - Go back to the MO and change the employee on the work station - Notice the project dashboard Timesheets section doesn't have any change on the amount ### Cause: This is happening because when changing the employee we don't modify anything in the AAL linked to the work station. As we only modify the AAL when the duration change. ### Fix: We call _create_analytic_entry when we change the employee on the work station to change the amount and the employee_id for the AAL. opw-5939321 Forward-Port-Of: odoo/enterprise#111040 Forward-Port-Of: odoo/enterprise#109695
This update resolves an error that prevented users from filtering products by date on the rental shop page. The fix adjusts how the system handles related resources to correctly process date-based searches. This ensures accurate product listings and a smoother user experience for rental bookings.
Original PR description
Currently, an error occurs when searching by date on the shop page. **Steps to Reproduce:** - Install the `website_sale_renting_planning` module. - Go to `Products` and create a product with the…
Currently, an error occurs when searching by date on the shop page. **Steps to Reproduce:** - Install the `website_sale_renting_planning` module. - Go to `Products` and create a product with the following configuration: - `Type`: `Service` - Under the `Sales` tab, set the `Periodicity` value. - Go to `Planning` > `Configuration` > `Roles` and switch to `Kanban` view. - Create a record by adding a `Resource` and the `service` product. - Enable `Sync Shifts and Rental Orders` in this role. - Go to `Website` > `Shop`. - Click `Edit` > `Style` > enable `Rental` by selecting it in the `toolbar`, then `save`. - Set the `start date` and `end date` and `apply` the filter. **Error1:** `ValueError: Invalid field 'resource_id' on model 'planning.slot' for 'resource_id:recordset'.` **Error2:** ` File "/home/odoo/odoo18/community/addons/resource/models/resource_calendar.py", line 455, in _leave_intervals_batch for _, resources in resources_per_tz.items():` `AttributeError: 'resource.resource' object has no attribute 'items'` This error occurs because after this [recent commit], the field `resource_id` was replaced by `resource_ids` with a M2M relation. When the user searches by date, the system attempts to group planning slots by `resource_id`, which raises the error[1]. After this [new commit], _leave_intervals_batch expects resources grouped by timezone, but here only resources are passed [2], which raises the error [3]. This commit ensures that `search_fetch` is used to retrieve `resource_ids`, since `read_group` cannot group records by M2M fields. It also ensures that resources with their timezone are correctly passed to _leave_intervals_batch. [recent commit]: https://github.com/odoo/enterprise/commit/fbf8b2ac67c71ca0abfc75df543069696bd2d29b [new commit]: https://github.com/odoo/odoo/commit/2dff65ab8b5a9db21d5b476065a72755cc4625be#diff-11ecbc9f00711187e60b88f84c618046bb24ada8c39cb29037568c1aa46f06a5 [1]: https://github.com/odoo/enterprise/blob/288c7d9c1f29746e0abe0338801621c033a2280c/website_sale_renting_planning/models/product_template.py#L30 [2]: https://github.com/odoo/enterprise/blob/288c7d9c1f29746e0abe0338801621c033a2280c/website_sale_renting_planning/models/product_template.py#L50 [3]: https://github.com/odoo/odoo/blob/9e41753a14c7398927445d8dc8f69dc57047b0b6/addons/resource/models/resource_calendar.py#L453 sentry-7325252044 Forward-Port-Of: odoo/enterprise#110306
This update fixes an error in the reports generated for sales in Ecuador (l10n_ec_reports_ats). The system now correctly identifies foreign partners ('partner_ext') using the appropriate tax identifier ('02') based on their company status, aligning with AFIP requirements. This ensures accurate reporting and compliance for export sales transactions.
Original PR description
Since `tipoCliente` is now determined using the computed `is_company` field, the test data must reflect this logic. `partner_ext` represents a foreign partner and is considered a company, therefore its `tipoCliente` should be set to '02'. See: https://github.com/odoo/enterprise/commit/a779badac35cf4a8f483f490e8ae29eb6bf3d2c5 `l10n_ar_edi`: For foreign partners, AFIP requires the CUIT pais based on the partner’s country and document type, not on partner.is_company. In multi-localization databases, is_company may be influenced by local heuristics and lead to picking the wrong foreign tax identifier. Use the identification type instead: VAT documents map to the legal-entity CUIT pais, while non-VAT documents map to the natural-person one. See: https://github.com/odoo/enterprise/pull/86089#discussion_r2128977870 runbot-241126 Forward-Port-Of: odoo/enterprise#110055
This update resolves a performance issue related to reading large spreadsheets in Odoo. Previously, Odoo used base64 encoding/decoding, which slowed down processing. Now, the system can directly read the spreadsheet data, resulting in a significant performance improvement.
Original PR description
We used to read from the attachment linked to the `spreadsheet_snapshot` binary field to avoid useless base64 encode/decode. On large spreadsheets, it would have a significant impact on performance. However, since odoo/odoo@41fe2ebdb9cc37341362d7af829c087a5f72f9f1, the orm no longer use base64 internally. We can now directly read the field. Task-6055190
This update ensures invoices accurately reflect subscription end dates, especially when they fall mid-period. It automatically prorates charges for products with prorated pricing, preventing overbilling and improving customer billing accuracy. This resolves a previous issue where subscriptions were billed for the full period regardless of the end date.
Original PR description
Before: - Invoicing ignored the subscription end date when it occurred within an invoiced period. Customers were billed for the full period even if the subscription ended earlier. After: - Invoicing period now ends at the subscription end date when it falls within the billing cycle. Invoice amounts are prorated when the product is configured for prorated pricing. Task-5870935
This update fixes an issue where the PayRun interface wasn't displaying correctly on resized windows, causing information to disappear from the user interface. The changes ensure that all PayRun details are consistently visible and accessible, regardless of screen size, improving usability.
Original PR description
**Description:** In the new payrun flow (https://www.odoo.com/odoo/project/1251/tasks/5362147) If you resize the window, the title is not well displayed and depending on the size, some information disapear event for the kanban cards without informations: Title issue Status bubble invisible: First button invisible (all in the dropdown): **Iplementation:** . Update payrun_card & payrun_button_box views to adapt window resizing task-5955169
This update corrects a technical issue impacting UK top-up payments. The system previously used incorrect country data due to a change in the UK account payload structure. This change ensures accurate top-up processing for UK customers, resolving a potential payment disruption.
Original PR description
Fix the UK top-up logic as UK accounts payload structure shifts from the EU where the country data is located in the EU payload it could be found under bank_transfer[financial_adresses][0][iban][country] and bank_transfer[country] but in the uk payload it can only be found in the second As we used the first one, we are now switching it to the second as it's the only common ground Forward-Port-Of: odoo/enterprise#111588
This update resolves an issue where a payslip would fail to generate correctly when an employee's contract started mid-period. The fix ensures the system handles contract start dates accurately, preventing errors and guaranteeing proper payroll processing for new hires. This improves the reliability of payroll calculations.
Original PR description
An error is thrown when an employee's contract starts mid-period. ```py Invalid Operation Wrong python code defined for: - Employee: Cesar Osbaldo Cruz Solorzano - Version: False - Payslip: Payslip -…
An error is thrown when an employee's contract starts mid-period.
```py
Invalid Operation
Wrong python code defined for:
- Employee: Cesar Osbaldo Cruz Solorzano
- Version: False
- Payslip: Payslip - Cesar Osbaldo Cruz Solorzano - 01/16/2026 - 01/31/2026
- Salary rule: Integrated Daily Wage (Base) (INT_DAY_WAGE_BASE)
- Error: AttributeError("'bool' object has no attribute 'year'") while evaluating
'\nresult = round(payslip.l10n_mx_integration_factor * payslip.l10n_mx_daily_salary, 4)\n
```
Steps to reproduce:
1. Install `l10n_mx_hr_payroll` modules
2. Switch to ESCUELA KEMPER URGATE company
3. Go to Employees and open Cesar Osbaldo Cruz Solorzano
4. Go to Payroll tab, change the start date of contract to 01/10/2026 and save
5. Go to Payroll > Payslips > Payslips and create a new pay run
6. Select Salary Structure 'Mexico: Regular Pay', Pay Schedule 'Monthly' and Period '01/01/2026 -> 01/31/2026'
7. Click on Continue, select Cesar and click on Select
8. An error is thrown
Problem:
In `_compute_integration_factor` method, `_get_first_contract_date` is called with context `before_date`, it returns `False` as the contract starts after the payslip period. This causes an error when trying to access the `year` field of `start_date`.
Solution:
Add a fallback to call `_get_first_contract_date` without context in case the first call returns `False`.
target: saas-18.4
task-6034836
Forward-Port-Of: odoo/enterprise#111417
Forward-Port-Of: odoo/enterprise#110568This update fixes an issue where DATEV exports were inaccurate when a move line's account was changed. Now, updating an account on a move line automatically updates the DATEV account, ensuring the exported data reflects the correct financial information. This prevents duplicate lines in DATEV reports.
Original PR description
Description of the issue this commit addresses: When the account of a move line is updated (e.g. replacing the suspense account with the actual one), l10n_de_datev_main_account_id was not recomputed which leads to an incorrect DATEV export with duplicate lines. Desired behavior after this commit is merged: Changing the account_id of a move line recomputes l10n_de_datev_main_account_id so that the exported DATEV data reflects the current accounts of the move. Forward-Port-Of: odoo/enterprise#111493
This fix prevents a data error that occurred when updating payroll information for Saudi Arabian companies. The issue stemmed from a missing category reference during the data update process. The change ensures that related category data is updated first, resolving the error and allowing the scheduled 'Payroll: Update Data' action to run successfully.
Original PR description
Currently, an error occurs when the "Payroll: Update Data" scheduled action is executed. **Steps to Reproduce:** - Install `l10n_sa_hr_payroll` with demo data. - Switch to `Saudi Arabian` company. -…
Currently, an error occurs when the "Payroll: Update Data" scheduled action is executed. **Steps to Reproduce:** - Install `l10n_sa_hr_payroll` with demo data. - Switch to `Saudi Arabian` company. - Go to `Payroll` > `Configuration` > `Salary` > `Rule Categories`. - Delete all records related to the Saudi Arabian company. - Go to `Scheduled Actions` and run `"Payroll: Update Data"`. `ValueError: External ID not found in the system: l10n_sa_hr_payroll.l10n_sa_category_provision` After [this commit], the category_id field becomes non-required, allowing users to delete a rule category record even if it is linked to a salary rule. When updating the data file [1], this causes an error due to the missing rule category [2]. This commit ensures that, when updating the salary rule data, the rule category data is updated beforehand, as shown here [3]. [this commit]: https://github.com/odoo/enterprise/commit/c663fd2a81b7f6b34f8199fdbdc4a75c4f21379e [1]- https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/models/hr_payslip.py#L157-L165 [2]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_sa_hr_payroll/data/hr_salary_rule_saudi_data.xml#L249 [3]: https://github.com/odoo/enterprise/blob/5ab4cb8bbf8211783a23a4334b633d52633b0324/l10n_ke_hr_payroll/models/hr_payslip.py#L9-L18 sentry-7349905716 Forward-Port-Of: odoo/enterprise#111438
This update fixes an issue where multi-select rectangles on scaled PDF signatures were inaccurately drawn, leading to incorrect selections. Additionally, the update resolves a potential error when dropping elements and ensures helper lines align correctly during dragging, improving the overall signature experience. This enhances the reliability and usability of our digital signature process.
Original PR description
When drawing the multi-select rectangle on scaled PDF pages, the rectangle corner was not properly synchronized with the mouse pointer, leading to inaccurate selection. Additional fixes: - An uncaught error could be triggered when dropping elements on the page. - Helper lines during dragging were not accurately aligned around sign items. task-6049004 Forward-Port-Of: odoo/enterprise#111156
This update fixes an issue where repositioning PDF signs caused multiple resize events, leading to unpredictable behavior. The change ensures only one resize listener is attached per sign, resulting in a more reliable and consistent resizing experience for users. This improves the overall usability of the PDF sign feature.
Original PR description
Previously, repositioning a sign item inside the PDF iframe would attach multiple resize event listeners. This led to inconsistent and unintuitive resizing behavior. This commit ensures that only a single resize listener is registered per item, avoiding duplicated handlers and restoring stable interaction. task-6048759 Forward-Port-Of: odoo/enterprise#111520 Forward-Port-Of: odoo/enterprise#111146
This update ensures that sign document deadlines are always accurate and automatically adjusts when a document's validity date changes. It also removes orphaned 'Signature Request' activities when a document is canceled, preventing clutter and improving the user experience.
Original PR description
1. **Date Sync: mail.activity & sign.request** **Before Fix:** When the validity_date on a sign.request was updated, the linked mail.activity (the "Please Sign" task) did not update its deadline.…
1. **Date Sync: mail.activity & sign.request**
**Before Fix:** When the validity_date on a sign.request was updated, the linked mail.activity (the "Please Sign" task) did not update its deadline. This led to a discrepancy where a document might expire in 2 days, but the user's to-do list still showed a deadline from a week ago.
**Expected Behavior:** The activity deadline should always reflect the current validity of the document to ensure signers are aware of the actual remaining time.
**Fix:** Overrode the write method on sign.request. When the validity_date is modified, the system now automatically updates the date_deadline of all associated records in sign_activity_ids.
2. **Activity Cleanup on Cancel**
**Before Fix:** Canceling a sign.request changed the document state but left "Signature Request" activities sitting in users' to-do lists. This resulted in "orphan" activities that pointed to canceled documents, cluttering the chatter and the activity bin.
**Expected Behavior:** Canceling a request should globally clean up any pending tasks related to that specific request.
**Fix:** Updated the cancel method to unlink associated activities.
**Note on Conflict Prevention:** To avoid a UserError/MissingRecord when canceling directly from the activity widget (where the interface attempts to delete the activity immediately after calling the cancel method), a context flag skip_sign_activity_unlink was introduced. This ensures that if the activity is already handling its own deletion, the backend doesn't "double-delete" it.
Task: 5989542
Forward-Port-Of: odoo/enterprise#111592