WhatsApp unread message counts are now tracked at the conversation member level instead of on the general thread. This makes unread indicators more accurate for each participant and supports more reliable message status handling.

part of task-3605717

community: https://github.com/odoo/odoo/pull/169404

Payroll contracts can now support fully flexible employees who do not have a fixed working calendar. The calendar is only required when pay work entries are based on a working schedule, reducing setup friction for flexible work arrangements.

Prior to this commit, the field `resource_calendar_id` was a required field. However, with the introduction of fully flexible employee which is defined as an employee without a resource calendar, we needed to drop this requirement.

With this commit, the field will only be required when the field `work_entry_source` is set to 'Working Schedule'. A helper text is also added to the field for easier understanding of this feature.

related [enterprise PR](https://github.com/odoo/odoo/pull/170117) 

Task: 3976534

The aged partner balance report filters have been cleaned up to make them easier to use and maintain. This should provide a smoother reporting experience for accounting users without changing the core report behavior.

This commit will do some clean up on the aged partner filters.

task-3961256

Spreadsheet pivots are now correctly recognized as used even when their formulas are on another sheet. This prevents users from seeing an active pivot incorrectly marked as unused in the Data menu.

Enterprise adaptations of the community branch.

Steps to reproduce in 17.0:

There's no way to reproduce the issue in 17.0 because the faulty getter in only called on positions in the active sheet (pivot autofill, global filter auto-matching)

Steps to reproduce in saas-17.1:

- insert a pivot in a blank spreadsheet
- delete all pivot formulas
- insert a new sheet
- in the new sheet: - in A1: type "1" - in A2: =ODOO.PIVOT(A1)
- activate the first sheet again
- Open the Data menu => the pivot 1 is marked as being unused, even though it's used in the second
   sheet

Task: 3859472
X-original-commit: 0b6730496a4316d0ec19ffb823ca2cee1c2c3790

The spreadsheet selection dialog was redesigned so different spreadsheet areas can share the same experience without custom front-end work each time. This makes it easier and safer to add new spreadsheet-related features in Documents and Dashboards while keeping the user experience consistent.

The spreadsheet editing module’s automated tests were reorganized and converted to a newer testing framework. This is an internal quality improvement that helps maintain reliability while preserving legacy support needed by related modules.

This commit converts the tests of the spreadsheet_edition module to Hoot.
Some legacy helpers are kept because they are used in other modules.

Task: 4011296

Gantt views now load unavailability information together with the main schedule data instead of making extra back-and-forth requests. This streamlines scheduling screens across appointments, planning, HR, projects, manufacturing, and related areas, improving maintainability and likely responsiveness without changing the core user workflow.

We refactor the way unavailabilities are fetched in the gantt view. The main thing we want is to fetch unavailabilities along the main gantt data (groups and records). Indeed, we think it is bad to have to fetch groups, create rows, send rows to the server, enrich those rows server side, send the enriched rows back. Moreover the API of gantt_unavailability was bad and forced most overrides to traverse the rows, convert the start_date, stop_date,...

So here we have make gantt_unavailability private, rationalize its API to make it a bit closer to the API of gantt_progress_bar, and call it directly in get_gantt_data.

Since the old API did allow to enrich a single row (e.g. in the case grouby=[]) or a row with a corresponding res_id = False, we still allow here to send unavailabilities for those cases in the following way:

```py
unavailabilities = {
    '__default': { False: global_default_unavailabilities, ... },
    <field_name>: { False: default_unavailabilities, ... },
    ...
}
```

A spreadsheet-related helper and its internal tests were removed from Enterprise because the logic now lives in the shared spreadsheet library. This reduces duplicate maintenance and helps keep spreadsheet behavior consistent across products.

This commit delete the helper `mergeContiguousZones` and its tests from enterprise, as they were moved to the o-spreadsheet library.

Task: [3965270](https://www.odoo.com/web#id=3965270&cids=1&menu_id=4720&action=333&active_id=2328&model=project.task&view_type=form)

The aim of this commit is to allow to declare a 281.50 for curaçao. context: issue spotted by odoo.com prod db Before the commit: `f2018_landwoonplaats` xml tag is empty After the commit: `f2018_landwoonplaats` xml tag is filled with the onss country code of netherlands. task-id: None Forward-Port-Of: odoo/enterprise#65503 Forward-Port-Of: odoo/enterprise#65466

The aim of this commit is to allow to declare a 281.50 for curaçao.

context:
issue spotted by odoo.com prod db

Before the commit:
`f2018_landwoonplaats` xml tag is empty

After the commit:
`f2018_landwoonplaats` xml tag is filled with the onss country code of netherlands.

task-id: None

Forward-Port-Of: odoo/enterprise#65503
Forward-Port-Of: odoo/enterprise#65466

Before this commit, the "Consumidor Final Anónimo" partner could be missing due to the limited partner loading mechanism. This commit ensures that the "Consumidor Final Anónimo" partner is always loaded, regardless of the partner loading limitations. opw-3988187 Forward-Port-Of: odoo/enterprise#65296

Before this commit, the "Consumidor Final Anónimo" partner could be missing due to the limited partner loading mechanism. This commit ensures that the "Consumidor Final Anónimo" partner is always loaded, regardless of the partner loading limitations.

opw-3988187

Forward-Port-Of: odoo/enterprise#65296

Issue ---- When a rental field like (e.g. `rental_start_date`) is changed in a sales order, its lines' description is recomputed. This makes sense for rental order lines as the description depends on these fields, but it messes with non-rental orders and non-rental order lines in rental orders when the Rental app is installed, so all descriptions get overwritten. Steps ----- - Install the rental app. - Create a new Quotation Template with whose line has a description that is differen

Issue
----

When a rental field like (e.g. `rental_start_date`) is changed in a sales order, its lines' description is recomputed. This makes sense for rental order lines as the description depends on these fields, but it messes with non-rental orders and non-rental order lines in rental orders when the Rental app is installed, so all descriptions get overwritten.

Steps
-----

- Install the rental app.
- Create a new Quotation Template with whose line has a description that is different from the product name.
- Create a new Quotation from the template.
- The description gets overwritten.

You can also reproduce this with creating a new rental order, then adding non-rental products with custom description. If you change the start date / end date the custom descriptions get overwritten.

opw-3987175

Forward-Port-Of: odoo/enterprise#64675

See commit Forward-Port-Of: odoo/enterprise#65456 Forward-Port-Of: odoo/enterprise#62470

See commit

Forward-Port-Of: odoo/enterprise#65456
Forward-Port-Of: odoo/enterprise#62470

Steps to reproduce: - Create a QC with measure on quantity (move_lines) - Create a reciept and set move_line quantity to 0 - Validate and create a backorder - No QC on the backorder Bug: when create the backorder the sml is created first on the original picking and then it's picking_id is updated measure on quantity QCs are created at this time the QCs that are on the move_line should first be moved to the backorder before deleting the pending QCs on the original picking opw-3996782

Steps to reproduce:
- Create a QC with measure on quantity (move_lines)
- Create a reciept and set move_line quantity to 0
- Validate and create a backorder
- No QC on the backorder

Bug:
when create the backorder the sml is created first on the original picking and then it's picking_id is updated measure on quantity QCs are created at this time
the QCs that are on the move_line should first be moved to the backorder before deleting the pending QCs on the original picking

opw-3996782

Forward-Port-Of: odoo/enterprise#65358

This commit fixes the access error that occured while trying to rematch gstr-2b report Behaviour before this commit: When user tries to rematch the GSTR-2b Summary, an access error will be thrown that says user has no read access to the Attachments. Steps to reproduce: - Login with a user having `Accountant` group set in access rights for Account. - Install l10n_in_reports_gstr module & Switch to IN Company - Go to Accounting / Reports / GSTR Return Periods - Create new return period.

This commit fixes the access error that occured while trying to rematch gstr-2b report

Behaviour before this commit:
When user tries to rematch the GSTR-2b Summary, an access error will be thrown that says user has no read access to the Attachments.

Steps to reproduce:
- Login with a user having `Accountant` group set in access rights for Account.
- Install l10n_in_reports_gstr module & Switch to IN Company
- Go to Accounting / Reports / GSTR Return Periods
- Create new return period.
- Fetch GSTR-2b Summary and try to re-match. (An access error will popup)

![2024-06-11_11-55](https://github.com/odoo/enterprise/assets/159013339/d6958729-9320-4be2-bc84-ddf44f08be33)

Behaviour after this commit:
The access error is no longer visible. Re-match can be done successfully.

Forward-Port-Of: odoo/enterprise#64311

## Changes in the pos_preparation_display/models/preparation_display_order.py: The previous code used to have low selectivity in the initial recordset returned by the search function. Then the records were filtered on their state inside the for loop which increased the number of get requests to view the order stages. This approach caused a bottleneck in the following situation: - All the records are in the done stage and will be processed to filter them out, but not viewed which takes a l

## Changes in the pos_preparation_display/models/preparation_display_order.py:

The previous code used to have low selectivity in the initial recordset returned by the search function. Then the records were filtered on their state inside the for loop which increased the number of get requests to view the order stages.

This approach caused a bottleneck in the following situation:
- All the records are in the done stage and will be processed to filter them out, but not viewed which takes a lot of resources and no result in the end.
- Some of the records are in the done stage, This would add an overhead to the processing of the function with irrelevant records to filter out the done orders.

Solution:
- Reduce the recordset being returned in the first place from the search function by adding filters to return only the ones in progress by running an `_read_group` function that returns the orders that do not have a completed stage in the current preparation display. This recordset is then added to the new orders that still do not have stages and are in the current preparation display as well.

## Changes in the pos_preparation_display/models/preparation_display.py:
The previous code would process all the records to be in the done state even though they could be already done.

This approach causes an issue in the following situation:
- All the records are archived, but pressing on archive all again, processes all the records again with no benefit added.

Solution:
- Same as above, reduce the recordset to return the orders still in progress only.

Also note that the reset was limited for 1000 records only and with the previous setup, pressing archive multiple times would result in the same processing over the same 1000 records, Which is why the limit was removed

## Benckmark
| | Before| After| Orders done | Number of records |Speed up
|---|----|-----|------|---------|---------
Time | 15 s | 12 s | No | 170k |1.25x
Time | 6 s | 302 ms | yes| 170k |19x
 
This speed up is because all of the records are archived and put in the done state thus not selected by the _read_group function in the first place. Under different circumstances the speed up would differ on the ratio between done and not done orders. But under the assumption that the number of orders on the display order at a single time, the speed up is considerable. 


## Reference
opw-3865664

Forward-Port-Of: odoo/enterprise#64669
Forward-Port-Of: odoo/enterprise#62996

https://github.com/odoo/enterprise/commit/f510c4098cc4696dec3fbc7d6cd3164c6fb1d6bd prevented to close a subscription if there was no invoice. Unfortulately, sale_order.order_line.invoice_lines.move_id is not always a reliabable way to check for invoices. Sme flows could replaces all the sale.order.line and therefore the link to the invoices would be lost. In that case, for subscription orders, using the subscription_id field on the account.move.line is more reliable. We use both values t

https://github.com/odoo/enterprise/commit/f510c4098cc4696dec3fbc7d6cd3164c6fb1d6bd
prevented to close a subscription if there was no invoice.
Unfortulately, sale_order.order_line.invoice_lines.move_id is not always
a reliabable way to check for invoices. Sme flows could replaces all the
sale.order.line and therefore the link to the invoices would be lost.

In that case, for subscription orders, using the subscription_id field
on the account.move.line is more reliable. We use both values to be
sure.

Forward-Port-Of: odoo/enterprise#65331

- Requires https://github.com/odoo/enterprise/pull/65166 - task-4004392 - part of task-3883628 ------------------------ This PR removes an unnecessary variable override within our `.dark` files. Before `saas-17.3`. which introduces a migration to Bootstrap v5.3, the `$card-bg` was set to `white` in light mode, which needed an override in dark mode as it'd still be pure white. As we change that value to `$o-view-background-color` which matches the `$card-cap-bg` value, we can remove tha

- Requires https://github.com/odoo/enterprise/pull/65166
- task-4004392
- part of task-3883628
------------------------
This PR removes an unnecessary variable override within our `.dark` files.

Before `saas-17.3`. which introduces a migration to Bootstrap v5.3, the `$card-bg` was set to `white` in light mode, which needed an override in dark mode as it'd still be pure white.

As we change that value to `$o-view-background-color` which matches the `$card-cap-bg` value, we can remove that override.

Forward-Port-Of: odoo/enterprise#65166

When closing a session, allow the user to cancel all open order by clicking on a button. This will cancel all the orders that are in the draft state in the current session. Task ID: 3987032 Related: https://github.com/odoo/odoo/pull/169742 Forward-Port-Of: odoo/enterprise#64846

When closing a session, allow the user to cancel all open order by clicking on a button. This will cancel all the orders that are in the draft state in the current session.

Task ID: 3987032

Related: https://github.com/odoo/odoo/pull/169742

Forward-Port-Of: odoo/enterprise#64846

**Before this PR:** There were no test cases written for the following three GST treatments: deemed export, composition and UIN holder. **After this PR:** Test cases have been added for the deemed export, composition and UIN holder GST treatments. **task**-3892511 Forward-Port-Of: odoo/enterprise#65344 Forward-Port-Of: odoo/enterprise#63333

**Before this PR:**
There were no test cases written for the following three GST treatments: deemed export, composition and UIN holder.

**After this PR:**
Test cases have been added for the deemed export, composition and UIN holder GST treatments.

**task**-3892511

Forward-Port-Of: odoo/enterprise#65344
Forward-Port-Of: odoo/enterprise#63333

Only load relevant MOs based on the workcenters that are shown in the view and reintroduce a limit to the amount of MOs that can be loaded simultaneously into the view. task-3895017 Forward-Port-Of: odoo/enterprise#65139 Forward-Port-Of: odoo/enterprise#64551

Only load relevant MOs based on the workcenters that are shown in the view and reintroduce a limit to the amount of MOs that can be loaded simultaneously into the view.

task-3895017

Forward-Port-Of: odoo/enterprise#65139
Forward-Port-Of: odoo/enterprise#64551

### Steps to reproduce: - Enable multi-step routes in the settings - Inventory > Configuration > Warehouse Management > Operations types - Click on Manufacturing and put "Always" on create a backorder - Create a product P (no need for a bom) - Create and confirm a manufacturing order for 2 units of the product - Go to the barcode module > operations > manufacturing > the MO - Register only one unit of P and produce #### > A backorder is automatically created but you are redirected to

### Steps to reproduce:

- Enable multi-step routes in the settings
- Inventory > Configuration > Warehouse Management > Operations types
- Click on Manufacturing and put "Always" on create a backorder
- Create a product P (no need for a bom)
- Create and confirm a manufacturing order for 2 units of the product
- Go to the barcode module > operations > manufacturing > the MO
- Register only one unit of P and produce

#### > A backorder is automatically created but you are redirected to the backend.

Note: If you were in "ask" on create backorder or if your product had a bom and you did not register the quantities of consumed components, a pop up would appear and resolving the pop up would redirect you to the kanban view of mrp.production in the barcode module.

### Cause of the issue:

The `validate` method called by clicking will execute the action if the orm call returns one and adds an 'onClose' call to its options: https://github.com/odoo/enterprise/blob/661fd61c0f50d4bf80484227c92a3fd0b9a05c68/stock_barcode/static/src/models/barcode_model.js#L475-L482 https://github.com/odoo/enterprise/blob/661fd61c0f50d4bf80484227c92a3fd0b9a05c68/stock_barcode/static/src/models/barcode_model.js#L487-L492 If the action is a popup, the onClose method will be called once the pop up is resolved. However, if the action redirects you directly to the form view of the mrp.propduction the onClose method will not be triggered and you will not be redirected to the kanban view.

### Fix:

As pop ups are the only actions that we really want to trigger during the validate call we exclude actions from the base models (stock.picking and mrp.production) to avoid any redirection to the backend.

#### Follow up of commit 6915741

## opw-3890886

Forward-Port-Of: odoo/enterprise#64850