Daily updates from Odoo
Navigate
Branch
Friday, May 2, 2025
35 changes
16 changes
Resolved issues and error corrections
This update improves how the point-of-sale payment screen handles removable zero-quantity order lines, reducing the chance of incorrect cleanup during due settlement. It also streamlines related automated test steps so future changes can be validated more consistently.
Original PR description
- Introduced `canBeRemoved` property in `PosOrderline` to simplify zero-qty line removal logic. - Updated payment screen to use `canBeRemoved` for cleaner filtering. - Added reusable tour helpers: `clickDropDownItemText` and `clickSettleOrderName`. See also: odoo/enterprise#84117 Task [link](https://www.odoo.com/odoo/project/967/tasks/4751971) task-4751971
This update brings the spreadsheet component to its latest maintenance version, fixing several issues around charts, pivot tables, formatting, range deletion, frozen rows, and collaborative editing. Users should see more reliable spreadsheet behavior, better chart exports and display quality, and fewer unnecessary refreshes during everyday use.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e8ff3fc46 [REL] 18.2.10 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e8ff3fc46 [REL] 18.2.10 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e6e60cb10 [FIX] selection_input: fix range deletion [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/fbccf06de [FIX] chart: avoid useless chart update [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/ad0c3ed69 [FIX] Pivot: allowDispatch invalid pivot dataset [Task: 4756759](https://www.odoo.com/odoo/2328/tasks/4756759) https://github.com/odoo/o-spreadsheet/commit/49d8d1d8e [FIX] bottom_bar_statistic: react to change in cell format [Task: 4747031](https://www.odoo.com/odoo/2328/tasks/4747031) https://github.com/odoo/o-spreadsheet/commit/bc597f95f [FIX] tables: react to change in cell format [Task: 4747031](https://www.odoo.com/odoo/2328/tasks/4747031) https://github.com/odoo/o-spreadsheet/commit/4c52b80a0 [FIX] header_overlay: restore row/col move preview [Task: 4747268](https://www.odoo.com/odoo/2328/tasks/4747268) https://github.com/odoo/o-spreadsheet/commit/5c9479c2e [FIX] xlsx: correctly export aggregated charts [Task: 4714410](https://www.odoo.com/odoo/2328/tasks/4714410) https://github.com/odoo/o-spreadsheet/commit/a280ac312 [IMP] sheetview: lazily re-compute viewports on freeze rows [Task: 3600662](https://www.odoo.com/odoo/2328/tasks/3600662) https://github.com/odoo/o-spreadsheet/commit/660057e76 [FIX] ChartRuntime: take devicePixelRatio in account [Task: 4661712](https://www.odoo.com/odoo/2328/tasks/4661712) https://github.com/odoo/o-spreadsheet/commit/8f373cc54 [FIX] chart: ignore trendline datasets in show values plugin [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/7e19305a1 [FIX] chart: align moving average trendline with bar chart offset [Task: 4653065](https://www.odoo.com/odoo/2328/tasks/4653065) https://github.com/odoo/o-spreadsheet/commit/3ca421fd7 [FIX] package: saas-18.2 is no longer the latest version [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/f81be368b [FIX] grid_overlay: stop interval on error [Task: 4746478](https://www.odoo.com/odoo/2328/tasks/4746478) https://github.com/odoo/o-spreadsheet/commit/42518534e [FIX] Collaborative: Send client position on activeSheet change [Task: 4736980](https://www.odoo.com/odoo/2328/tasks/4736980) 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: Mehdi Rachico (mera) <mera@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>
Fixed an issue that caused an error when users selected multiple posted customer invoices and used Send and Print from the list view. The change ensures the process uses the correct invoice records, allowing batch invoice sending to complete reliably.
Original PR description
Currently, a traceback is occurring when the user tries to send and print invoices in batch. <b>To reproduce this issue:</b> 1) Open the customer invoices list view in Accounting 2) Select multiple posted invoices and click send <b>Error:- </b> ``` KeyError: <NewId origin=2125> ``` <b>Cause:</b> The issue arises because the wizard record has not been saved, resulting in an issue in returning the origin id for move while computing the `_compute_alerts` method. This leads to the traceback from the below line because self.id origin id in this case. https://github.com/odoo/odoo/blob/255a612a63be883bf9b73fff1bca4f66db430091/addons/mail/models/mail_thread.py#L1953-L1955 <b>Solution:-</b> Instead of passing the record with origin id, we can pass the actual move record. opw-4750394
Miscellaneous changes
The option of "cumulatedStart" was incorrectly infered from the "cumulative" option of an Odoo graph view. However, both options are not specifically linked. Task-4701303 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 Forward-Port-Of: odoo/odoo#208112 Forward-Port-Of: odoo/odoo#204980
Original PR description
The option of "cumulatedStart" was incorrectly infered from the "cumulative" option of an Odoo graph view. However, both options are not specifically linked. Task-4701303 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 Forward-Port-Of: odoo/odoo#208112 Forward-Port-Of: odoo/odoo#204980
Versions -------- - 16.0+ Steps ----- 1. Enable Paypal as payment provider; 2. have a US-based partner; 3. sent them a payment link; 4. pay using Paypal; 5. open transaction on Paypal backend. Issue ----- No delivery address is registered, making the merchant ineligible for seller protection. Cause ----- Commit 00259dc44a981 added the `no_shipping: '1'` value to the form sent to Paypal to prevent buyers from changing their shipping address on Paypal's end. A side-effect is t
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Paypal as payment provider; 2. have a US-based partner; 3. sent them a payment link; 4. pay using Paypal; 5. open transaction on Paypal backend. Issue…
Versions -------- - 16.0+ Steps ----- 1. Enable Paypal as payment provider; 2. have a US-based partner; 3. sent them a payment link; 4. pay using Paypal; 5. open transaction on Paypal backend. Issue ----- No delivery address is registered, making the merchant ineligible for seller protection. Cause ----- Commit 00259dc44a981 added the `no_shipping: '1'` value to the form sent to Paypal to prevent buyers from changing their shipping address on Paypal's end. A side-effect is that it doesn't even register the address provided with the transaction. Solution (16.0 up to saas-17.4) ------------------------------- Use the `address_override: '1'` value instead, which prevents buyers from changing the address while still registering the address on the transaction. In stable, keep the `no_shipping: '1'` value in the rendering values so that user's cannot suddenly change the address again if template hasn't been updated yet. Solution (18.0+) ---------------- Change the `shipping_preference` value from `NO_SHIPPING` to `SET_PROVIDED_ADDRESS`[^1]. opw-4681336 [^1]: https://developer.paypal.com/docs/checkout/standard/customize/shipping-module/#:~:text=Configuring%20shipping%20preferences Forward-Port-Of: odoo/odoo#205972 Forward-Port-Of: odoo/odoo#205686
Sale status was not correctly set when ticket where sold from the POS. Steps to reproduce: ------------------- * Create an event and make sure ticket can be sold in PoS * Open PoS * Add a ticket to the order and complete the order * Add another ticket to the order but go to the backend to save it as draft > Observation: The sale status of the order appears as 'free' when it should be "Sold" and "Not Sold" Why the fix: ------------ We make sure to take the state of the PoS order
Original PR description
Sale status was not correctly set when ticket where sold from the POS. Steps to reproduce: ------------------- * Create an event and make sure ticket can be sold in PoS * Open PoS * Add a ticket to the order and complete the order * Add another ticket to the order but go to the backend to save it as draft > Observation: The sale status of the order appears as 'free' when it should be "Sold" and "Not Sold" Why the fix: ------------ We make sure to take the state of the PoS order when the ticket has been sold through the PoS. opw-4584390 Forward-Port-Of: odoo/odoo#208026 Forward-Port-Of: odoo/odoo#204514
To reproduce the issue: 1. In Settings, enable: - Storage Locations - Units of Measure & Packagings - Packages 2. In uom list, edit Pack of 6: - Package type: Pallet 3. Create a putaway rules: - From: WH/Stock - Package type: Pallet - To: WH/Stock/Shelf 1 4. Create and confirm a receipt with one Pack of 6 of any product Error: in the detailed operations of the SM, the destination location is still WH/Stock. It should be the shelf. A small mistake happened d
Original PR description
To reproduce the issue: 1. In Settings, enable: - Storage Locations - Units of Measure & Packagings - Packages 2. In uom list, edit Pack of 6: - Package type: Pallet 3. Create a putaway rules: - From: WH/Stock - Package type: Pallet - To: WH/Stock/Shelf 1 4. Create and confirm a receipt with one Pack of 6 of any product Error: in the detailed operations of the SM, the destination location is still WH/Stock. It should be the shelf. A small mistake happened during the big refactoring of UoM and packaging: commit [1] simply removed the use of the SM's packaging instead of using the new field [1] https://github.com/odoo/odoo/commit/dc24a1d1c93cf6eeb6456b1591a0ab8ccc4086ba OPW-4750639 Forward-Port-Of: odoo/odoo#208137
When an orderline is deleted, it wasn't being removed from the indexedDB. This commit ensures that deleted orderlines are also removed from the local storage, maintaining data integrity in the POS. opw-4626344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202110
Original PR description
When an orderline is deleted, it wasn't being removed from the indexedDB. This commit ensures that deleted orderlines are also removed from the local storage, maintaining data integrity in the POS. opw-4626344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202110
Versions -------- - 17.0+ Steps ----- 1. Create a product with 3 attributes; 2. add a never-create multi-select attribute; 3. archive the first two variants; 4. publish the product to eCommerce; 5. open /shop. Issue ----- > 500: Internal Server Error Cause ----- Commit 30994723e9ee5 updated the `_cartesian_product` method to handle `multi`-type attributes. When these are on the last attribute line, the method will yield the current partial combination. Issue is when conti
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a product with 3 attributes; 2. add a never-create multi-select attribute; 3. archive the first two variants; 4. publish the product to eCommerce; 5.…
Versions -------- - 17.0+ Steps ----- 1. Create a product with 3 attributes; 2. add a never-create multi-select attribute; 3. archive the first two variants; 4. publish the product to eCommerce; 5. open /shop. Issue ----- > 500: Internal Server Error Cause ----- Commit 30994723e9ee5 updated the `_cartesian_product` method to handle `multi`-type attributes. When these are on the last attribute line, the method will yield the current partial combination. Issue is when continuing after the `yield`, it attempts to get the `current_ptav_index` from the `current_line_values` recordset, which is empty for `multi`-type attributes. This causes an `IndexError`. Solution -------- Only assign the `current_ptav` variable if `current_line_values` is not falsey, i.e. isn't on a `multi` attribute line. Because `current_ptav_index` will always be `-1` in this scenario, it will skip over the conditional branches where `current_ptav` gets used, and instead go to either `continue` or `break`. opw-4653696 Forward-Port-Of: odoo/odoo#203093
This commit fixes wrongly used `isMobileOs` in attachment list. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208232
Original PR description
This commit fixes wrongly used `isMobileOs` in attachment list. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208232
When calculating earnings-based withholdings in company-branch setups, the logic incorrectly referenced accounting entries from the mother company if the user belonged to a branch. This led to incorrect accumulation of taxable base amounts and previously withheld amounts, especially when vendor bills or payments were made in a branch. This fix ensures that: - The accumulation logic in `_tax_compute_all_helper` correctly scopes move line searches using the user's company. As a result, with
Original PR description
When calculating earnings-based withholdings in company-branch setups, the logic incorrectly referenced accounting entries from the mother company if the user belonged to a branch. This led to incorrect accumulation of taxable base amounts and previously withheld amounts, especially when vendor bills or payments were made in a branch. This fix ensures that: - The accumulation logic in `_tax_compute_all_helper` correctly scopes move line searches using the user's company. As a result, withholding retention now behaves correctly in company-branch environments. opw-4581579 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203246
If a plan B has sub plans (C1, C2) already with analytics entries, and then plan B is updated to also have a parent plan A, hence the structure would be A/B/C1 and A/B/C2, the Analytic entries data on the sub plans is cleared off from C1 and C2. opw-4338406 Forward-Port-Of: odoo/odoo#207797
Original PR description
If a plan B has sub plans (C1, C2) already with analytics entries, and then plan B is updated to also have a parent plan A, hence the structure would be A/B/C1 and A/B/C2, the Analytic entries data on the sub plans is cleared off from C1 and C2. opw-4338406 Forward-Port-Of: odoo/odoo#207797
Steps: - Compare 2 views Actual result: - Header text color is dark with dark background  Expected result: - Header text color is light with dark background  Forward-Port-Of: odoo/odoo#206044
Original PR description
Steps: - Compare 2 views Actual result: - Header text color is dark with dark background  Expected result: - Header text color is light with dark background  Forward-Port-Of: odoo/odoo#206044
- In this PR (https://github.com/odoo/odoo/pull/199923) we set a default system parameter to define the number limit of partner to load in PoS by default (set to 20000). - But since this PR (https://github.com/odoo/odoo/pull/184417) the default value was was changes from 20000 to 5000. - To avoid making new similar issues, these defaults values are now extracted as constant class. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR
Original PR description
- In this PR (https://github.com/odoo/odoo/pull/199923) we set a default system parameter to define the number limit of partner to load in PoS by default (set to 20000). - But since this PR (https://github.com/odoo/odoo/pull/184417) the default value was was changes from 20000 to 5000. - To avoid making new similar issues, these defaults values are now extracted as constant class. 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 Forward-Port-Of: odoo/odoo#203432
In this version, the picking type code `dropship` has been introduced to differentiate incoming types from this one (ref: 1547d66585a4b57cd3b747f28b7514dbd9d7bef8), but the search for missing companies without this new type is still being done with the old criteria of the source and target location. Let's change this to use the new picking type code. @Tecnativa Forward-Port-Of: odoo/odoo#201968
Original PR description
In this version, the picking type code `dropship` has been introduced to differentiate incoming types from this one (ref: 1547d66585a4b57cd3b747f28b7514dbd9d7bef8), but the search for missing companies without this new type is still being done with the old criteria of the source and target location. Let's change this to use the new picking type code. @Tecnativa Forward-Port-Of: odoo/odoo#201968
### Steps to reproduce: - In the settings enable Multi-Step routes - Unarchive the MTO route - Create a storable product using the MTO and buy route - Create and confirm a sale order for 100 units of that product - Validate the delivery for only 30 units and backorder the rest #### > The purchase order demand was updated to 170 units ### Cause of the issue: Since the refactoring a72382063ee662010729d983fbf6fb6305b8adf2 the rule of the MTO route is purely MTO. Furthermore, the moves
Original PR description
### Steps to reproduce: - In the settings enable Multi-Step routes - Unarchive the MTO route - Create a storable product using the MTO and buy route - Create and confirm a sale order for 100 units of…
### Steps to reproduce: - In the settings enable Multi-Step routes - Unarchive the MTO route - Create a storable product using the MTO and buy route - Create and confirm a sale order for 100 units of that product - Validate the delivery for only 30 units and backorder the rest #### > The purchase order demand was updated to 170 units ### Cause of the issue: Since the refactoring a72382063ee662010729d983fbf6fb6305b8adf2 the rule of the MTO route is purely MTO. Furthermore, the moves creating and running a procurement are added depending solely on their `procure_method` during the `_action_confirm`: https://github.com/odoo/odoo/blob/1dd360658222c0afeb268a5c8cf435defddf55d1/addons/stock/models/stock_move.py#L1485-L1496 https://github.com/odoo/odoo/blob/1dd360658222c0afeb268a5c8cf435defddf55d1/addons/stock/models/stock_move.py#L1503-L1513 In our use case, the delivery move is therefore created as `mto` and then creates and run a procurments creating the PO during its confirmation. However, when it is backordered, the backorder move is also created and confirmed as `mto` by the `_create_backorder` call: https://github.com/odoo/odoo/blob/02a370a7a34a42f2bc9f668eee756fb466db8722/addons/stock/models/stock_move.py#L2071-L2075 It will therefore also automatically create and run a procurment that will in turn modify the current PO. opw-4633920 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205192
19 changes
Security fixes and vulnerability patches
Access to HR Settings in employee profiles is now limited to users with the right HR manager permissions. Employees can edit permitted profile sections only when self-editing is enabled, while approver fields are correctly available where allowed.
Original PR description
Steps:
- Go to 'My Profile'.
- Check the 'HR Settings' tab and other sections ('Resume', 'Work Information' and 'Private Information').
Issues:
- Users could edit 'HR Settings' without proper HR permissions.
- Approver fields were not editable even though self edit setting was on.
Fix:
- Restricted HR Settings edits to users with HR manager rights.
- Ensured all the fields in 'Resume', 'Work Information' and 'Private Information' are editable only with hr_employee_self_edit enabled.
- Approver related fields are now editable in 'Work Information' section.
Task-4319956Enhancements to existing features
Odoo adds a new communication service for IoT Boxes that first tries the usual longpolling connection and falls back to websockets if needed. This improves reliability for actions such as printing and point-of-sale hardware communication, while allowing the rollout to happen gradually.
Original PR description
This commit introduces a new `iot_http` service that allows performing an IoT action using longpolling then falling back sending a websocket message if the longpolling request fails. This commit does not adapt all action call to use the service, nor removes the `iot_longpolling` service, in order to adapt progressively. Community PR: odoo/odoo#207994 Task: 4283647
IoT Box cards now show more helpful details, including connected device counts, pairing dates, and related Point of Sale configurations. The pairing flow has also been reorganized and reworded to make setup easier and help users identify the right IoT Box faster.
Original PR description
We added back the amount of devices connected to an IoT Box on the IoT Box card. We also added the pairing date on the card, for a user to spot faster an IoT Box. If an IoT Box is linked to a PoS, the PoS configs where devices are linked are now listed on the IoT Box cards. Some elements have been moved, and some sentences have been rephrased on the wizards to pair an IoT Box. Task: 4585446
The self-order kiosk IoT integration now uses device driver actions instead of direct remote calls. This should make kiosk setup and device interactions more consistent and easier to maintain, with limited visible change for day-to-day users.
Original PR description
Community PR: [https://github.com/odoo/odoo/pull/192652](https://github.com/odoo/odoo/pull/192652)
Spreadsheet auto-complete has been updated to work better with the latest spreadsheet changes, especially for relational fields. This improves consistency when users search or select spreadsheet-related data and keeps related sales spreadsheet tests aligned.
Original PR description
See https://github.com/odoo/odoo/pull/208294
The Gantt view now makes closed tasks less prominent and shows dependency lines from closed tasks as dashed or dotted. This helps users quickly distinguish completed work from active tasks while still understanding how tasks are connected.
Original PR description
`* = project_enterprise` In this commit closed tasks in gantt view have lower opacity. When the source task in dependency is closed then resulting path is dashed/dotted. task-4645818
Spreadsheet users now get autocomplete suggestions when navigating related fields in list-based formulas, making it easier to build accurate spreadsheet references. The update improves usability across spreadsheet features and aligns related tests with the new asynchronous autocomplete behavior.
Frontdesk now automatically emails visitors when their selected host is unavailable due to time off or an archived host record. This helps visitors know who to contact instead, reducing confusion at check-in.
Original PR description
This PR includes a feature to automatically send a mail to the visitor, when a record is created if the hosts are on time off, the visitor will be notified by email that your host is unavailable you can contact to manager or responsible of frontdesk. Additionally, it will notify visitors when the host record is achieved. task-3790300
This update allows employees to have more than one active contract at the same time when those contracts do not depend on flexible schedules, planning, or attendance tracking. It helps support valid multi-contract situations while keeping stricter controls where scheduling or attendance conflicts could occur.
Original PR description
This PR refines the contract constraints by allowing multiple contracts to be in a running state simultaneously. An employee can have multiple active contracts only if the contracts are not flexible, planning-based, or attendance-based. task-4374321
Resolved issues and error corrections
Salary offer configurations now correctly use the default choices for benefits when no starting value was entered. This ensures candidates and recruiters see accurate salary calculations as soon as an offer is opened or adjusted.
Original PR description
**Steps to Reproduce:** 1. Create a new contract template with some benefits using various display types (slider, dropdown, dropdown-group). 2. Go to the Recruitment app, create an application linked…
**Steps to Reproduce:** 1. Create a new contract template with some benefits using various display types (slider, dropdown, dropdown-group). 2. Go to the Recruitment app, create an application linked to the contract template, and generate an offer. **Cause:** 1. We were filling the state based only on the initial_values. If a field's initial value was not set or was 0, we set the state to 0. If the field type was a dropdown and no initial value was set, we also set it to 0. However, in a dropdown, the default selected value is always the first option. 2. Since the value was not set the salary configuration value was not updating on initial render. **Fix:** 1. To fix the issue, put condition where if the initial_values is not set -- In dropdown and dropdown-group: If initial_values is not set then we should select the first default selected value and do our computation. -- In slider(range): If the initial_values is not set then we should take the min slider value as a default value and do our computation. task-3856395
This update ensures stipend payroll calculations include the gross stipend amount when determining net salary. As a result, stipend payments should appear correctly in payroll reports and accounting outputs, improving accuracy for Indian payroll processing.
Original PR description
This PR includes the following updates: - Added the gross amount calculation to the net salary rule for the stipend salary structure. - Ensured that stipend amounts are included in reports and COA by updating the net salary rule logic. Task - 4668024
The contract salary workflow no longer shows a "partially signed" status when a contract template only requires one signature. This avoids confusion for HR teams and employees by showing a more accurate contract status.
Original PR description
- displaying a "partially signed" state in the contract state even when the contract PDF template requires only one signature. Task: 4592653
IoT Boxes are now identified by a stable device identifier instead of their network connection address. This prevents the same physical box from appearing twice when it switches between Ethernet and Wi-Fi, reducing confusion and cleanup for users.
Original PR description
IoT Boxes have both Ethernet and Wi-Fi interfaces, each with a unique MAC address. When connected via Ethernet, the database registers the Ethernet MAC. If the Ethernet cable is later unplugged and the device switches to Wi-Fi, the database treats it as a new device due to the different MAC address, resulting in duplicate records for the same physical device. This commit changes the identifier from the MAC address, to: - the motherboard uuid on windows, - the serial number on rpi. Community PR: [https://github.com/odoo/odoo/pull/207230](https://github.com/odoo/odoo/pull/207230) Task: 4592611
Miscellaneous changes
Added required checks for generic annual closing return type. task-4627315 Forward-Port-Of: odoo/enterprise#84412
Original PR description
Added required checks for generic annual closing return type. task-4627315 Forward-Port-Of: odoo/enterprise#84412
task-4627315 Forward-Port-Of: odoo/enterprise#84426
Original PR description
task-4627315 Forward-Port-Of: odoo/enterprise#84426
Forward-Port-Of: odoo/enterprise#84391
Original PR description
Forward-Port-Of: odoo/enterprise#84391
**Traceback:** ```python ('helpdesk.helpdesk_ticket_menu_all', 117, 'Helpdesk > Tickets > All Tickets', 157): Traceback (most recent call last): File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 259, in crawl_menu self.mock_action(action_vals) File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 272, in mock_action return self.mock_act_window(action) File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 432, in moc
Original PR description
**Traceback:** ```python ('helpdesk.helpdesk_ticket_menu_all', 117, 'Helpdesk > Tickets > All Tickets', 157): Traceback (most recent call last): File…
**Traceback:**
```python
('helpdesk.helpdesk_ticket_menu_all', 117, 'Helpdesk > Tickets > All Tickets', 157):
Traceback (most recent call last):
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 259, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 272, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 432, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 463, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3814, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4045, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7031, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1303, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1485, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/base_automation/models/base_automation.py", line 816, in _compute_field_value
return _compute_field_value.origin(self, field)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 429, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5253, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/enterprise/18.0/helpdesk/models/helpdesk_ticket.py", line 298, in _compute_partner_ticket_count
partner_tickets.fetch(['stage_id']) # prevent over-fetching fields, leading to potential out-of-memory error
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4095, in fetch
self.check_access('read')
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4394, in check_access
if not self.env.su and (result := self._check_access(operation)):
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4435, in _check_access
if domain and (forbidden := self - self.sudo().filtered_domain(domain)):
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6627, in filtered_domain
data = record.mapped(key)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6470, in mapped
recs = recs._fields[name].mapped(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1377, in mapped
self.__get__(first(remaining))
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 3059, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1266, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4071, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4108, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4197, in _fetch_query
rows = self.env.execute_query(query.select(*sql_terms))
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 979, in execute_query
return [] if self.cr.description is None else self.cr.fetchall()
MemoryError
```
Issue:
------
The `_compute_partner_ticket_count` method caused a MemoryError while running the test cases due to the large number of records and over fetching of `stage_id` in the line: `partner_tickets.fetch(['stage_id'])`
followed by: `partner_tickets.filtered(lambda ticket: not ticket.stage_id.fold)`
Solution:
---------
Replaced the fetch and filtered logic with a search method to resolve the MemoryError and improve performance
upg-2707381
opw-4653413
Forward-Port-Of: odoo/enterprise#83280- and changed report type and selections' string task-4720586 Forward-Port-Of: odoo/enterprise#83352
Original PR description
- and changed report type and selections' string task-4720586 Forward-Port-Of: odoo/enterprise#83352
### Issue: - In attendance-based contracts, lunch break intervals were automatically deducted from attendances,. - However, this deduction was not reflected in the generated work entries, resulting in inconsistencies between attendance duration and payroll calculations. ### Steps To Repoduce: - Set up an attendance-based contract with lunch break in the schedule. - Log attendance from 08:00 to 20:00 without logging out for lunch. - Observe: - The attendance has the lunch b
Original PR description
### Issue:
- In attendance-based contracts, lunch break intervals were automatically deducted from attendances,.
- However, this deduction was not reflected in the generated work entries, resulting in inconsistencies
between attendance duration and payroll calculations.
### Steps To Repoduce:
- Set up an attendance-based contract with lunch break in the schedule.
- Log attendance from 08:00 to 20:00 without logging out for lunch.
- Observe:
- The attendance has the lunch break interval deducted.
- The work entry does not, and includes the full duration.
### Solution:
- revert the change introduced in https://github.com/odoo/enterprise/pull/71979/commits/0a54ef993da3ef4882acdee1b8f5e378e2e9f2e0 only for contracts without flexible hours.
- Lunch breaks are now deducted from both attendances and work entries only when the contract has flexible_hours = False.
opw-4627247
Forward-Port-Of: odoo/enterprise#83825