Removed an unused piece of WhatsApp messaging code that was left over after a related interface change. This has no expected change for users, but keeps the codebase simpler and easier to maintain.

Since odoo/odoo#186084, the `hasSendButtonNonEditing` getter has been removed from the composer template. This commit removes that getter, as it's now dead code.

Related to odoo/odoo#192103

Cohort reports can now be viewed using quarterly periods, giving teams a broader time-based perspective alongside existing options. This helps business users spot longer-term trends more easily when analyzing customer or activity cohorts.

Adds the ability to see cohort on a quarterly basis.

Restaurant teams can now update the table booking appointment type even while a point-of-sale session is open. After reloading, the POS resynchronizes with the updated setting, giving staff more flexibility without needing to close active sessions.

Previously, the setting "Table booking: appointment type" could not be modified while a session was open.
With this commit, this setting can now be modified, and the POS will resynchronize after reloading

Requires Community PR https://github.com/odoo/odoo/pull/191396
task-4380609

The contract signing setup wizard now offers an Upload PDF button when no signing templates are available. This makes it easier for HR users to continue preparing contract signature requests without first creating or finding an existing template.

This PR improves the configuration of the sign request template by adding an `Upload PDF` button in the wizard when no templates are available.

task-4243509

The Field Service Tasks Analysis report was adjusted to match recent changes that removed an inactive-task filter. This keeps reporting views working correctly without requiring broader changes to field service or task analysis reports.

- Removed the inactive filter in the Tasks Analysis report, so we need to update 
  the xpath accordingly.

Technical:
 - If the `inactive` filter is added in the `project_task_view_search_fsm_base` view,
   it will require the removal of both the Task Analysis report and the FSM report. 
   Hence, we should not include the `inactive` filter in the `project_task_view_search_fsm_base`.

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

task-4037091

When a quotation or sales order is deleted, its custom spreadsheet is now removed as well. This prevents order-specific spreadsheets from being reused accidentally in quotation templates, keeping sales documents cleaner and more accurate.

Currently, when deleting a quotation/SO with a custom `sale.order.spreadsheet`, the latter will see its field `order_id` empty and will become available to be linked to a quotation template.

Since it's a custom spreadsheet for that specific SO, it makes no sense to keep it.

opw-4385254

IoT Boxes now receive both device-specific and generic handler files when updating. This prevents missing components that could stop connected hardware integrations from working correctly.

In this [PR](https://github.com/odoo/enterprise/pull/75443), we added conditions not to download already up to date handlers.
We introduced a condition to only download Windows handlers on Windows and Linux ones on Linux: as some are not plateform-specific, we were not sending them to the IoT Box.

The condition is now adapted to download both plateform-specific and generic handlers to IoT Boxes.

This fix prevents an error when staff click the customer button after settling a customer's due account in Point of Sale. It improves checkout reliability and avoids interruptions during customer account payment workflows.

Steps to reproduce :
====
- Open POS
- Select customer and pay through the customer account payment option.
- Again go to customer and select customer.
- Settle the due amount & complete payment.
 - Click on the customer button.
- Traceback appears.

Fix :
====
- Fixed improper value parsing to ensure correct behavior.

task - 4376767

This internal update aligns the Documents Kanban view with a related platform change by making required setup information explicit. Users should not notice a feature change, but it helps keep the Documents interface stable and easier to maintain.

This commit is the counterpart of odoo/odoo#191307.

To be more clear, we add the original amount from the statement we are to reconciliating on the open balance line. task-4194671 Forward-Port-Of: odoo/enterprise#76146 Forward-Port-Of: odoo/enterprise#70785

To be more clear, we add the original amount from the statement we are to reconciliating on the open balance line.

task-4194671

Forward-Port-Of: odoo/enterprise#76146
Forward-Port-Of: odoo/enterprise#70785

This commit's purpose is to add a test for the full flow of the creation of a BOM/MO when they are linked to a project. This is to ensure that the aal generated are generated correctly and that the project profitability is then computing them into the correct section. community pr: https://github.com/odoo/odoo/pull/186607 task - 4184226 affetced version 18.0 - master Forward-Port-Of: odoo/enterprise#76157 Forward-Port-Of: odoo/enterprise#74398

This commit's purpose is to add a test for the full flow of the creation of a BOM/MO when they are linked to a project. This is to ensure that the aal generated are generated correctly and that the project profitability is then computing them into the correct section.

community pr: https://github.com/odoo/odoo/pull/186607
task - 4184226
affetced version 18.0 - master

Forward-Port-Of: odoo/enterprise#76157
Forward-Port-Of: odoo/enterprise#74398

When the `l10n_be_hr_payroll_sepa_salary_payment` context option is passed, an extra `<Ustrd>` gets generated with the Urgency SEPA flag. After the refactoring in odoo/enterprise#60393, when there is no recognized reference type in the default `_get_RmtInf()` generation[^1], we end up with 2 Ustrd elements like this: ```xml <RmtInf> <Ustrd>SPLIP/1234</Ustrd> <Ustrd>/A/ SPLIP/1234</Ustrd> </RmtInf> ``` The SEPA file then gets rejected by banks as invalid. Instead we should detect

When the `l10n_be_hr_payroll_sepa_salary_payment` context option is passed, an extra `<Ustrd>` gets generated with the Urgency SEPA flag. After the refactoring in odoo/enterprise#60393, when there is no recognized reference type in the default `_get_RmtInf()` generation[^1], we end up with 2 Ustrd elements like this:

```xml
<RmtInf>
  <Ustrd>SPLIP/1234</Ustrd>
  <Ustrd>/A/ SPLIP/1234</Ustrd>
</RmtInf>
```
The SEPA file then gets rejected by banks as invalid.

Instead we should detect the pre-existing element and update it.

[^1]: https://github.com/odoo/enterprise/blob/42b7b322d6c720de45661e3370397adaf74fe1f4/account_iso20022/models/account_journal.py#L324-L326

Forward-Port-Of: odoo/enterprise#74692

### Issue: Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the `_action_done`: https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/stock/models/stock_picking.py#L918 https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/delivery/models/stock_picking.py#L192-L196 However, since a UserError of any of the picking

### Issue:

Certain carrier's API processes validity checks and parcels generation one picking at a time so that on our end we are forced to send requests one at a time at the end of the the `_action_done`: https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/stock/models/stock_picking.py#L918 https://github.com/odoo/odoo/blob/e4f68fc6eb2a666a07b6627b9dc0ec575b79d1e3/addons/delivery/models/stock_picking.py#L192-L196 However, since a UserError of any of the picking will cause a rollback of the entire batch on Odoo's side, pikcings might end up being processed on the carrier side but non validated on Odoo's side during batch validation.

### Steps to reproduce:

- Configure sendcloud shipping method + website + payment providers
- In your sendcloud configuration select sendcloud shipping product to not be able to handle products with a weight exceeding 10 kg e.g; bpost @home (0-10kg).
- Create 2 storable products with respective weigth 1 and 100 kg.
- Publish them on the website for sale.
- Open a private window, make an order via the website for the 1kg product by filling your cart and use sendcloud as carrier.
- Repeat the operation with the other product to generate a seconde SO.
- Back to your main window > Inventory Overview > Delivery Orders
- Select both deliveries > Action > Validate (in batch)

#### > While the first delivery order was processed on carrier side (can be checked on sendcloud's website)
#### > the UserError of the second DO rollbacked its validation in Odoo.

### Fix:

As such, and since the carrier requests needs to happen after we have validated the pickings in Odoo, we should avoid any rollback of the transaction once any requests has already been successfully treated on the carrier side.

### Note:

It is not possible restructure the code to use `senf.env.cr.savepoint` in a loop in order to reset the validation of pickings that are not valid on the carrier side because savepoints can't be used more than 64 times before the server crashes and hence can't be used in record loops.

community: https://github.com/odoo/odoo/pull/190320
opw-4357325

Forward-Port-Of: odoo/enterprise#76244
Forward-Port-Of: odoo/enterprise#75502

Before this commit: Only `companyName` is included in shipping requests sent to FedEx. After this commit: `personName` is added to the request, same as `companyName`. According to FedEx documentation, it is not required if the address is `buisness` but we get an error if the `deliveryAddress` and `soldTo` address are different. Checked with FedEx support, and they said it is required to send the `personName` field always. opw-4415536 Forward-Port-Of: odoo/enterprise#76307

Before this commit:

Only `companyName` is included in shipping requests sent to FedEx.

After this commit:

`personName` is added to the request, same as `companyName`.

According to FedEx documentation, it is not required if the address is `buisness` but we get an error if the `deliveryAddress` and `soldTo` address are different.

Checked with FedEx support, and they said it is required to send the `personName` field always.

opw-4415536

Forward-Port-Of: odoo/enterprise#76307

## Issue: - Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax. ## Steps to reproduce: - Create a new invoice and add a line with an 8% tax. - Validate the invoice and export it as XML. - Upload the XML file as a vendor bill. - The vendor bill incorrectly shows two "8% taxes" instead of one. ## Solution: - The issue stems from a forward-port error from `saas-16.4` https://github.com/odoo/enterprise/commit/5681a8d5abee3a8787f3ee8612a8c3b18ed63ee6 to

## Issue:
- Uploading a Mexican XML file with an 8% tax results in the addition of an extra 8% tax.

## Steps to reproduce:
- Create a new invoice and add a line with an 8% tax.
- Validate the invoice and export it as XML.
- Upload the XML file as a vendor bill.
- The vendor bill incorrectly shows two "8% taxes" instead of one.

## Solution:
- The issue stems from a forward-port error from `saas-16.4` https://github.com/odoo/enterprise/commit/5681a8d5abee3a8787f3ee8612a8c3b18ed63ee6 to `17.0` https://github.com/odoo/enterprise/commit/56a2b66d84d8398ea870d559cd55cfeae44019d8
- In `17.0` we introduced this Extract method  `_l10n_mx_edi_import_cfdi_get_tax_from_node` to refactor the `_l10n_mx_edi_import_cfdi_fill_invoice_line`.
- We should have add the Exento checks in the new method however we mistakenly pushed code from `saas-16.4` to `17.0` without adapting it.
- I removed the extra code introduced during the forward-porting.
- Refactored the related code to ensure compatibility with the new changes in `17.0`.

OPW-4198016

Forward-Port-Of: odoo/enterprise#76209
Forward-Port-Of: odoo/enterprise#74602

Issue: After posting content through Social Marketing on Instagram, the generated link redirects to a non-existent post or page. Steps to Reproduce: 1. Install the Social Marketing tool. 3. Set up an Instagram account connection. 3. Create a post and attempt to click on the generated link for redirection to the post on Instagram. Solution: The issue stems from using Instagram's internal post_id, which does not work for direct URL access to the post. To resolve this, we need to requ

Issue: After posting content through Social Marketing on Instagram, the generated link redirects to a non-existent post or page.

Steps to Reproduce:

1. Install the Social Marketing tool.
3. Set up an Instagram account connection.
3. Create a post and attempt to click on the generated link for redirection to the post on Instagram.

Solution:

The issue stems from using Instagram's internal post_id, which does not work for direct URL access to the post. To resolve this, we need to request the permalink associated with the post rather than relying on the internal link. This will ensure accurate redirection. While using the shortcode is an alternative, requesting the permalink directly is a more reliable approach.

opw-4243329

Forward-Port-Of: odoo/enterprise#72725

### Steps to reproduce the issue: 1. Activate Mexican Localization 2. In Mexican Company, add USD as Currency and give it a Rate 3. Create a Sales Journal and a Pricelist with USD as main Currency 4. _Point of Sale > Configuration > Settings_: Select a Shop and set the USD Journal and Pricelist 5. Open a Session using the USD Shop and complete some Orders, without invoicing them 6. _Point of Sale > Orders > Orders_, select the created Orders and, in the Actions, Create Global Invoice 7.

### Steps to reproduce the issue:

1. Activate Mexican Localization
2. In Mexican Company, add USD as Currency and give it a Rate
3. Create a Sales Journal and a Pricelist with USD as main Currency
4. _Point of Sale > Configuration > Settings_: Select a Shop and set the USD Journal and Pricelist
5. Open a Session using the USD Shop and complete some Orders, without invoicing them
6. _Point of Sale > Orders > Orders_, select the created Orders and, in the Actions, Create Global Invoice
7. The document should be accepted, but TipoCambio has a rate of 1.000000.

### Explanation:

During the creation of the Global Invoice, the rate is retrieved during `pos.order._prepare_tax_base_line_values` and, since no value is given through POS, the default value is used. https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1242 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1212-L1213 https://github.com/odoo/odoo/blob/8fb7e5fd304697aebcce085602a5f3a1ecaf757a/addons/account/models/account_tax.py#L1188-L1193

### Fix reasoning:

Adding test to make sure Foreign Currency can be used in Global Invoice for `pos.order` and rate is correctly set as well.
Fix in Community

opw-4302180

Forward-Port-Of: odoo/enterprise#75185