Monday, March 24, 2025
32 changes · master
Enhancements to existing features
The rental date picker in the website sales flow now uses clearer action buttons instead of the previous close and apply labels. This makes selecting or changing rental periods easier for customers and helps reduce confusion during checkout.
Original PR description
…ly" buttons
Payroll screens and settings have been refined to make common tasks easier to understand and complete. Users get clearer labels, helper text, improved search and filters, and localized form improvements for Belgium and the United States.
Original PR description
_ * = hr_contract_salary, hr_work_entry_holidays_enterprise, l10n_us_hr_payroll, l10n_be_hr_{contract_salary, payroll_fleet}, test_l10n_be_hr_payroll_account
This PR introduces various improvements to the payroll module, focusing on ux and functionality enhancements:
- improved UX for kanban, form, and list views across other inputs, payslips, and contracts.
- Added helper text to salary attachments, payroll dashboards, contracts, headcount, master reports, and offers for better clarity.
- Improved payroll settings for easier configuration.
- Updated module titles, menus, and column headers in list views.
- improved filters and search functionality in batch payslips and other inputs.
- Localized improvements: - Belgium: Enhanced individual records, contracts, resumes, and form views. - USA: Improved contract form views.
task-4334973In Studio, the Cohort view is now grouped under the Reporting section instead of Timeline. This makes it easier for users to find cohort analysis alongside other reporting tools, improving navigation without changing the view itself.
Original PR description
SPECIFICATION: In Studio, the Cohort view has been moved from the Timeline section to the Reporting section. Task-4648873
Contracts created through signed salary offers now keep a direct link to the contract template used. Users are also redirected to the relevant contract template instead of the contract form, making the offer-to-contract flow clearer and easier to follow.
Original PR description
This PR improves contract generation through the offer signing process. Now, the contract template is directly linked to the contract when created from an offer. Additionally, the redirection will correctly lead to the contract template instead of the contract form from the offer. task-4573828
Payroll users can now see each bank account's Bank Identifier Code directly in the bank account list. This makes it easier to review and verify payroll banking details without opening each record individually.
Original PR description
- add `bic` (Bank Identifier Code) field in the list view in model `res.partner.bank` task-4622435
The Argentina electronic invoicing connection test now shows a clearer warning window instead of an error-style message. This reduces confusion when services are available and returns users to the accounting settings page after the message.
Original PR description
The previous connection test window showed up as an UserError with the title "Invalid Operation" which can be confusing to users when all services show as available.
Replace the UserError with a RedirectWarning that has a better title message ("Odoo Warning"). As it needs to redirect to somewhere, we redirect back to the current accounting page in settings.
task-4288536Timesheets on helpdesk tickets now show the newest entries at the top. This makes it easier for users to review recent work and quickly add today's timesheet without scrolling.
Original PR description
This commit changes the order uses inside the list view to display the most recent timesheets first. Also, when the user would like to create a new timesheet in that list view, the new row will be on the top of the list since in the most of the cases, the user will create a timesheet for today. task-4637865
A new contract checkbox lets companies decide whether overtime from attendance should be included when calculating work entries, regardless of the planning source. This gives payroll and HR teams clearer control over extra hours and helps avoid unintended overtime calculations.
Original PR description
add a checkbox to control whether overtimes are taken from attendance when computing work entries regardless of the source task-4360628
This update adds missing database indexes across several Odoo Enterprise apps after a continuous integration check identified potential performance gaps. It should help common background searches and reporting operations run more efficiently without changing user workflows.
Original PR description
See https://github.com/odoo/odoo/pull/198860
WhatsApp message content is now handled more consistently when stored and displayed, reducing the risk of formatting issues. This helps ensure business communications appear correctly and safely for users.
Original PR description
Enterprise counter-part. https://github.com/odoo/odoo/pull/199262
The payroll payslip line report has been improved with a clearer list view, making it easier for users to review payroll details. The update also adjusts the pivot report behavior so payroll data is displayed more appropriately and avoids confusing interactions.
Original PR description
- add list view for more clarity on the new payslip line report Task: 4626207
The inventory accounting setting has been renamed from “Automatic Accounting” to “Inventory Valuation,” with the related method now labeled “Perpetual.” This makes the setting easier for users to understand and clarifies how inventory valuation is managed in accounting.
Original PR description
The 'Automatic Accounting' setting name was unclear and did not accurately describe its function. It has been renamed to 'Inventory Valuation,' and the accounting method is now explicitly referred to as 'Perpetual' to better reflect its purpose. This improves clarity and helps users understand how inventory valuation is managed. task-4328288
Resolved issues and error corrections
This update corrects a test setup issue in the Indian payroll accounting module related to spreadsheet handling. It helps keep automated checks reliable, reducing the chance of development delays from false test failures.
Miscellaneous changes
If a list contains multi-line content, only the first line of the content is shown in the spreadsheet cells. This commit fixes this with an `AUTORESIZE_ROWS`, which now works for multi-line formulas. Task: [4609545](https://www.odoo.com/web#id=4609545&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#81929 Forward-Port-Of: odoo/enterprise#81325
Original PR description
If a list contains multi-line content, only the first line of the content is shown in the spreadsheet cells. This commit fixes this with an `AUTORESIZE_ROWS`, which now works for multi-line formulas. Task: [4609545](https://www.odoo.com/web#id=4609545&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form) Forward-Port-Of: odoo/enterprise#81929 Forward-Port-Of: odoo/enterprise#81325
This update prevents a payroll report test from running when a required spreadsheet tool is not installed. It helps avoid unnecessary test failures during upgrades without changing day-to-day payroll functionality.
Original PR description
In this commit, the openpyxl import has been fixed. This ensures that if openpyxl is not present, the test case will not execute. Error Log: https://upgradeci.odoo.com/upgradeci/run/193786 Related Upgrad PR : https://github.com/odoo/upgrade/pull/7417
Versions -------- - 18.0+ Steps ----- 1. Have a second company & select it; 2. create a project w/out `company_id`; 3. set its documents folder to "Projects"; 4. create a service product that creates a project on confirm; 5. set created project as its project template; 6. add service product to a quotation; 7. confirm quotation. Issue ----- Access Error. Cause ----- Commit ac051d00e96c added a constraint on the `website_id` of documents: - OR the document's `company_id` h
Original PR description
Versions -------- - 18.0+ Steps ----- 1. Have a second company & select it; 2. create a project w/out `company_id`; 3. set its documents folder to "Projects"; 4. create a service product that creates…
Versions -------- - 18.0+ Steps ----- 1. Have a second company & select it; 2. create a project w/out `company_id`; 3. set its documents folder to "Projects"; 4. create a service product that creates a project on confirm; 5. set created project as its project template; 6. add service product to a quotation; 7. confirm quotation. Issue ----- Access Error. Cause ----- Commit ac051d00e96c added a constraint on the `website_id` of documents: - OR the document's `company_id` has to match the website's `company_id`; - OR the website's `company_id` has to be in `self.env.companies`. The Projects folder was created without `website_id`, but was assigned company 1's website by the `_compute_website_id` method. When a document gets created by the sale order, it inherits the `website_id` of the Projects folder. Hence having a shared folder between companies can lead to access errors if the website's `company_id` isn't selected in the company selector. Solution -------- Bypass the constraint when in sudo mode, so you don't have to enable the website's company in the company selector when setting up a sale order. opw-4548619 Forward-Port-Of: odoo/enterprise#81470 Forward-Port-Of: odoo/enterprise#80966
### Steps to reproduce: - Create 3 products: Final product (FP), components COMP FP using the UOM category of Unit and COMP using Weigth for instance. - Create and confirm an MO for 1 unit of FP - Process the MO from the barcode app. - Click on "Add Component" select COMP as a product and set 1 unit - Confirm the additional move line #### > Invalid operation: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure g defined on the pr
Original PR description
### Steps to reproduce: - Create 3 products: Final product (FP), components COMP FP using the UOM category of Unit and COMP using Weigth for instance. - Create and confirm an MO for 1 unit of FP -…
### Steps to reproduce: - Create 3 products: Final product (FP), components COMP FP using the UOM category of Unit and COMP using Weigth for instance. - Create and confirm an MO for 1 unit of FP - Process the MO from the barcode app. - Click on "Add Component" select COMP as a product and set 1 unit - Confirm the additional move line #### > Invalid operation: "The unit of measure Unit defined on the order line doesn't belong to the same category as the unit of measure g defined on the product. Please correct the unit of measure defined on the order line or on the product. They should belong to the same category." ### Cause of the issue: When processing an MO from the barcode app and adding a component the method `_getNewLineDefaultContext` will be called to set the default context of that new line before creation: https://github.com/odoo/enterprise/blob/83268aa3a5a7afdc8c09b0ac9bbee2b673fd25e9/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L367-L372 However, in this flow, `this.record` is an `mrp.production` and its `product_uom_id` is the product_uom_id of FP. In particular, the `default_product_uom_id` key will be used to alter the vals_list used in the create of our stock move line and an error will be raised since the unit category of COMP2 is Weight and is not compatible with the default product uom set by the context. opw-4527706 Forward-Port-Of: odoo/enterprise#81832 Forward-Port-Of: odoo/enterprise#79266
### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and **start** an MO with that bom. - Through Shop Floor, on your operation > Wheel > add components - Set the quantity of COMP to 10 instead of 1. #### > In the backend, observe that the picking Stock -> Pre-Prod has not been updated ### Cause of the issue: Adding a product already referenced
Original PR description
### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and…
### Steps to reproduce: - In the settings, enable multi-step routes. - Set Warehouse to 2-step Manufacturing - Create a BoM with an operation and one move raw: 1 x COMP - Create confirm, plan and **start** an MO with that bom. - Through Shop Floor, on your operation > Wheel > add components - Set the quantity of COMP to 10 instead of 1. #### > In the backend, observe that the picking Stock -> Pre-Prod has not been updated ### Cause of the issue: Adding a product already referenced as a raw material via the catalog will trigger a call of the `_update_order_line_info` which will update the demand of the move raw: https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2895-L2898 https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/mrp_production.py#L2913-L2914 If you did not start the MO, this would run the procurement to update the demand and thus update the picking: https://github.com/odoo/odoo/blob/38821f7ffae0aa15c10f3e6972b01aafade6bc60/addons/mrp/models/stock_move.py#L434-L438 However, since the MO was started the state of the MO is 'in_progress' instead of 'confirmed'. ### Note: The issue was not reproducible before 18.0. Since adding a component was done via a call that would create and confirm a new move (hence running the procurements): https://github.com/odoo/enterprise/blob/b3febe5a1afd5c1c8fd598db95e8c58fa4131563/mrp_workorder/wizard/additional_product.py#L63-L68 Community: https://github.com/odoo/odoo/pull/201592 opw-4638371 Forward-Port-Of: odoo/enterprise#81902 Forward-Port-Of: odoo/enterprise#81361
The bug has been introduced by this commit : https://github.com/odoo/enterprise/commit/4cba2fb58560a95d5ce93eb6e6c1483ef0428ba5 The bug appears when trying to generate batch of payslips with fully flexible working schedules. When the contract linked to the payslip has no working schedule, the check of the timezone is done on the employee linked to the payslip. The fix only consists on taking the employee of each slip instead of taking the employee on self, which was causing a 'singleton expe
Original PR description
The bug has been introduced by this commit : https://github.com/odoo/enterprise/commit/4cba2fb58560a95d5ce93eb6e6c1483ef0428ba5 The bug appears when trying to generate batch of payslips with fully flexible working schedules. When the contract linked to the payslip has no working schedule, the check of the timezone is done on the employee linked to the payslip. The fix only consists on taking the employee of each slip instead of taking the employee on self, which was causing a 'singleton expected' error. This commit also contains a test for the related fix in the following related PR: task-4623219 Forward-Port-Of: odoo/enterprise#80785
The customer statement should show the same info as the partner ledger, but in a more condensed way (less columns, same rows). Same for the Follow-up report, but here we should by default filter on sales journals. Ticket - 4606122 Forward-Port-Of: odoo/enterprise#81951 Forward-Port-Of: odoo/enterprise#81369
Original PR description
The customer statement should show the same info as the partner ledger, but in a more condensed way (less columns, same rows). Same for the Follow-up report, but here we should by default filter on sales journals. Ticket - 4606122 Forward-Port-Of: odoo/enterprise#81951 Forward-Port-Of: odoo/enterprise#81369
Since odoo/enterprise@a94227b, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now possible to greatly improve the configuration of consolidation reports, by grouping the move lines by account_id.code, then account_id.name, provided that non-stored related fields are added on account.move.line for those values. This way, it becomes possible to configure multiple accounts mapped to the same code, without having to ensure a 1 to 1 relationship
Original PR description
Since odoo/enterprise@a94227b, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now possible to greatly improve the configuration of…
Since odoo/enterprise@a94227b, it is possible in standard report engines to group by non-stored related fields. Thanks to this, it is now possible to greatly improve the configuration of consolidation reports, by grouping the move lines by account_id.code, then account_id.name, provided that non-stored related fields are added on account.move.line for those values. This way, it becomes possible to configure multiple accounts mapped to the same code, without having to ensure a 1 to 1 relationship between the accounts of the source and consolidating company. This, however, was only implemented for standard engines. Custom engines were not modified, and none of them did the proper call to _fields_to_sql, to ensure the join condition of the query is adapted to run this grouping. This commit adds it, together with a test ensuring the custom engines are all evaluated on runbot with a non-stored custom groupby, so that errors are spotted directly and the developers just don't have to remember this "by heart". task-4596355 Forward-Port-Of: odoo/enterprise#81627 Forward-Port-Of: odoo/enterprise#81495
Even though it's been commonplace in Odoo for a while, tags (or more precisely facets) with index-0/False color where still shown on Documents kanban cards. This should remain the case functionally as users are not expected to go and change the color of all their tags, nor can we decide for them at upgrade (and it'd be too late for many as well). Task-4645015 Also, cleaning up some test stuff for hoot. See details in individual commits. Task-3861500 Forward-Port-Of: odoo/enterpris
Original PR description
Even though it's been commonplace in Odoo for a while, tags (or more precisely facets) with index-0/False color where still shown on Documents kanban cards. This should remain the case functionally as users are not expected to go and change the color of all their tags, nor can we decide for them at upgrade (and it'd be too late for many as well). Task-4645015 Also, cleaning up some test stuff for hoot. See details in individual commits. Task-3861500 Forward-Port-Of: odoo/enterprise#81969 Forward-Port-Of: odoo/enterprise#76201
Before this PR the function _compute_unpaid_invoices is using an antipattern of running a search in a for loop. This PR performs a single search and uses a python dictionary for faster lookup in the forloop and fewer queries. Benchmarks: |num res.partner | time before | no. queries| time after | no. queries after| |-----|-----|----|------|----| | 80 | ~18s | 80 | ~0.4s | 1| Forward-Port-Of: odoo/enterprise#81438
Original PR description
Before this PR the function _compute_unpaid_invoices is using an antipattern of running a search in a for loop. This PR performs a single search and uses a python dictionary for faster lookup in the forloop and fewer queries. Benchmarks: |num res.partner | time before | no. queries| time after | no. queries after| |-----|-----|----|------|----| | 80 | ~18s | 80 | ~0.4s | 1| Forward-Port-Of: odoo/enterprise#81438
Now that hr_recruitment correctly use standard mail tools to create partners from emails it correctly calls model tools to deduce partner name, which prioritize partner_name over name found in email. See community PR for more details. Task-4656218 Forward-Port-Of: odoo/enterprise#81884
Original PR description
Now that hr_recruitment correctly use standard mail tools to create partners from emails it correctly calls model tools to deduce partner name, which prioritize partner_name over name found in email. See community PR for more details. Task-4656218 Forward-Port-Of: odoo/enterprise#81884
Currently on the Frontdesk welcome screen the words "Welcome" and "to" (welcoming visitors to your company) were exported separately, because they weren't in the same parent node. This caused translation issues, since the word "to" is translated differently depending on the context and was not scoped to the module (Javascript translation). This commit puts "Welcome to" together in the same parent node, so the phrase is exported as a whole. [task-4421055](https://www.odoo.com/odoo/project.t
Original PR description
Currently on the Frontdesk welcome screen the words "Welcome" and "to" (welcoming visitors to your company) were exported separately, because they weren't in the same parent node. This caused translation issues, since the word "to" is translated differently depending on the context and was not scoped to the module (Javascript translation). This commit puts "Welcome to" together in the same parent node, so the phrase is exported as a whole. [task-4421055](https://www.odoo.com/odoo/project.task/4421055) Forward-Port-Of: odoo/enterprise#80851 Forward-Port-Of: odoo/enterprise#78781
Use case: -Create a parent company and a child company. -Create two journals, assigning one to each company. -Connect with a normal user (not an admin, I connected with marc demo) after adding both companies to their allowed companies list. -activate the child company, and attempt to access the General Ledger. --> there is an access right error raised because the user doesn't have access to the parent company. ticket - 4577222 Forward-Port-Of: odoo/enterprise#81452
Original PR description
Use case: -Create a parent company and a child company. -Create two journals, assigning one to each company. -Connect with a normal user (not an admin, I connected with marc demo) after adding both companies to their allowed companies list. -activate the child company, and attempt to access the General Ledger. --> there is an access right error raised because the user doesn't have access to the parent company. ticket - 4577222 Forward-Port-Of: odoo/enterprise#81452
- Removed VAT report banners for warnings but kept rejection banners. task-4575302 Forward-Port-Of: odoo/enterprise#79469
Original PR description
- Removed VAT report banners for warnings but kept rejection banners. task-4575302 Forward-Port-Of: odoo/enterprise#79469
[[FIX] account_batch_payment: show correct amount in reconciled batch payments](https://github.com/odoo/enterprise/pull/80862/commits/d9f837d4bb459a10e74b65c10204e2c31573e7a5) **Issue:** When reconciling a batch payment, its amount is incorrectly displayed as zero in the list view. **Steps to Reproduce:** 1. Install the Accounting app. 2. Navigate to Accounting > Customers > Payments. 3. Create or select two payments, then click Create Batch. 4. Validate the batch payment. 5. Go to Das
Original PR description
[[FIX] account_batch_payment: show correct amount in reconciled batch payments](https://github.com/odoo/enterprise/pull/80862/commits/d9f837d4bb459a10e74b65c10204e2c31573e7a5) **Issue:** When…
[[FIX] account_batch_payment: show correct amount in reconciled batch payments](https://github.com/odoo/enterprise/pull/80862/commits/d9f837d4bb459a10e74b65c10204e2c31573e7a5) **Issue:** When reconciling a batch payment, its amount is incorrectly displayed as zero in the list view. **Steps to Reproduce:** 1. Install the Accounting app. 2. Navigate to Accounting > Customers > Payments. 3. Create or select two payments, then click Create Batch. 4. Validate the batch payment. 5. Go to Dashboard > Transactions. 6. Create a new transaction with the same value as the batch payment. 7. Click on the transaction, select the batch payment, and click Validate to reconcile them. 8. Navigate to Customers > Batch Payments. 9. Observe that the batch payment in the list view shows an amount of zero. Expected Behavior: The list view should display the sum of the payments included in the batch. Actual Behavior: The amount displayed in the list view is always zero after reconciliation. **Root Cause** During reconciliation, when execution reaches line 138 in account_batch_payment.py https://github.com/odoo/enterprise/blob/08084d8423a7d75c1ee2647256e01a464eec0b14/account_batch_payment/models/account_batch_payment.py#L137 , the batch payments are already in the paid state. However, _valid_payment_states() https://github.com/odoo/enterprise/blob/08084d8423a7d75c1ee2647256e01a464eec0b14/account_batch_payment/models/account_batch_payment.py#L69-L70 calls _get_invoice_in_payment_state(), which returns "in_payment". As a result, _valid_payment_states() only returns "in_process", excluding payments in the "paid" state from the computation. Consequently, in _compute_from_payment_ids(), the loop over valid payments is skipped, leaving the amount variable at its initial value of zero. https://github.com/odoo/enterprise/blob/08084d8423a7d75c1ee2647256e01a464eec0b14/account_batch_payment/models/account_batch_payment.py#L132-L162 **Fix** Always compute `amount`. Skip `amount_residual` and `amount_residual_currency` for valid payment states. Opw-4585624 Forward-Port-Of: odoo/enterprise#80862
Before this PR: - The computation used `start_yearly_period` as the start date. - This caused incorrect depreciation calculations when an asset was disposed of early. - Example: - Prorata Date: 01/01/2025 - Disposal Date: 20/02/2025 - Computed Days: 326 (incorrect, should be 20) After this PR: - `period_start_date` is now set as `max(start_yearly_period, self.paused_prorata_date)`. - Ensures depreciation is calculated only for the valid period before disposal. - Example: - P
Original PR description
Before this PR: - The computation used `start_yearly_period` as the start date. - This caused incorrect depreciation calculations when an asset was disposed of early. - Example: - Prorata Date: 01/01/2025 - Disposal Date: 20/02/2025 - Computed Days: 326 (incorrect, should be 20) After this PR: - `period_start_date` is now set as `max(start_yearly_period, self.paused_prorata_date)`. - Ensures depreciation is calculated only for the valid period before disposal. - Example: - Prorata Date: 01/01/2025 - Disposal Date: 20/02/2025 - Computed Days: 20 (correct). OPW: 4599614 Forward-Port-Of: odoo/enterprise#81888 Forward-Port-Of: odoo/enterprise#80214
**=pos_urban_piper_swiggy Following this commit: ==== - Previously, static values like 'CGST' and 'SGST' were used. However, 'SGST' has been renamed to 'SGST/UTGST'. - To prevent similar issues in the future, tax group names are now fetched dynamically instead of using hardcoded values. - This ensures accurate tax computation and better maintainability. task-4626494 Forward-Port-Of: odoo/enterprise#81858 Forward-Port-Of: odoo/enterprise#80756
Original PR description
**=pos_urban_piper_swiggy Following this commit: ==== - Previously, static values like 'CGST' and 'SGST' were used. However, 'SGST' has been renamed to 'SGST/UTGST'. - To prevent similar issues in the future, tax group names are now fetched dynamically instead of using hardcoded values. - This ensures accurate tax computation and better maintainability. task-4626494 Forward-Port-Of: odoo/enterprise#81858 Forward-Port-Of: odoo/enterprise#80756
Before this commit: === - When reloading the POS, the delivery order count in pos_store was lost. After this commit: === - The order count is now properly retained even after a reload. - Ensures that delivery orders persist correctly in pos_store. task-4585831 Forward-Port-Of: odoo/enterprise#79560
Original PR description
Before this commit: === - When reloading the POS, the delivery order count in pos_store was lost. After this commit: === - The order count is now properly retained even after a reload. - Ensures that delivery orders persist correctly in pos_store. task-4585831 Forward-Port-Of: odoo/enterprise#79560
Currently an error occurs when the user tries to uninstall `Sales` or `helpdesk_sale_timesheet` after creating a helpdesk ticket. Steps to generate an error: - Create a database without a demo and install helpdesk_sale_timesheet. - Create a helpdesk ticket. - Now try to uninstall sale_management (Sales). Error `KeyError: 'helpdesk.ticket.sale_line_id'` This issue was generated because in the helpdesk ticket we have the `use_helpdesk_sale_timesheet` field (see [1]), which is a depen
Original PR description
Currently an error occurs when the user tries to uninstall `Sales` or `helpdesk_sale_timesheet` after creating a helpdesk ticket. Steps to generate an error: - Create a database without a demo and…
Currently an error occurs when the user tries to uninstall `Sales` or `helpdesk_sale_timesheet` after creating a helpdesk ticket. Steps to generate an error: - Create a database without a demo and install helpdesk_sale_timesheet. - Create a helpdesk ticket. - Now try to uninstall sale_management (Sales). Error `KeyError: 'helpdesk.ticket.sale_line_id'` This issue was generated because in the helpdesk ticket we have the `use_helpdesk_sale_timesheet` field (see [1]), which is a depends field of the `compute_sale_line_id` method, which is the compute method of the field sale_line_id (see [2] and [3]) in the helpdesk ticket. In helpdesk code line [4] tries to update the value of the field `use_helpdesk_sale_timesheet` since this field is related to the helpdesk ticket (see [1]) value of this field also changed in the helpdesk ticket, and the value was changed the compute method trigger because this field depends on the compute method. This commit will solve the above issue by executing an SQL query instead of writing the team field so it doesn't trigger depending on that field. [1]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk_sale_timesheet/models/helpdesk_ticket.py#L27 [2]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk_sale_timesheet/models/helpdesk_ticket.py#L31-L38 [3]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk_sale_timesheet/models/helpdesk_ticket.py#L77-L78 [4]- https://github.com/odoo/enterprise/blob/1619b74b7895108a80d466c57972fc97923c860c/helpdesk/models/ir_module.py#L15 sentry-6308112739 Forward-Port-Of: odoo/enterprise#81008