Gantt views can now collapse consecutive unavailable time columns that contain no scheduled items, making schedules easier to read and navigate. Restaurant appointment bookings use this clearer folded view by default, reducing wasted screen space from off-hours.

This commit allows to fold gantt columns that are not "useful" on the screen: this consists in consecutive columns that are filled with unavailabilities on each row and that do not contain any pill as well. Such columns therefore are folded into a single one when the user activates the option and can be unfolded by clicking on any cell of the folded column.

task-4350760

Field service project task views now show subtasks by default, making it easier for users to see all work linked to a project without discovering an extra filter. Users who prefer a simpler view can still hide subtasks using the new hide filter.

Before this commit, the subtasks are hidden by default when the user goes into a project to see the tasks linked to that project. The problem is it is difficult to notify the sub-tasks are not displayed in the view and it is also difficult to know how to show them. The user has to discover the new filter `Show sub-tasks` in the search view.

This commit will now display all tasks (sub-tasks included) linked to the project to be sure the user will see all information first. If the user would like to hide the sub-tasks then he will just have to select the filter `Hide Sub-Tasks`.

task-4547389

The document signing screen has been adjusted so the side panel appears on the right and no longer clashes with the signing prompt. The first side panel option is selected automatically, making document preview and signing easier for users.

**Purpose
========**
This PR handles overriding the default PDF.js viewer styling to enhance the user experience while signing documents. 

Specifically, it addresses the issue where overlapping elements, such as the "Click to Start" prompt and the sign panel, create a visually unappealing interface.

**Specification
=========**
1. Moves the side panel to the right side of the viewer for improved accessibility.
2. Ensures the first option in the side panel is selected by default, simplifying the document preview process (refer to: https://link.excalidraw.com/l/65VNwvy7c4X/o1Mtd7yyXD).


**Screenshots
=========**

#### Before:
![image](https://github.com/user-attachments/assets/8ef795af-fddf-4849-a43e-5300b774a035)


#### After:
![image](https://github.com/user-attachments/assets/8356460c-9cbf-49f8-b78d-efe45463a20b)

__________________________________________________________________________________________________________
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

task-id: 4369079

The Gantt view control panel has been updated to better match the Calendar view, creating a more consistent experience across scheduling tools. Users will see refreshed navigation arrows, spacing, sizing, and range selection behavior for a cleaner interface.

We make the gantt control panel look like the calendar control panel:
- We use the odoo icons oi-arrow-left/right for the left/right arrows
- The height of the control panel is set to be 50px
- The range selector becomes an extension of ViewScaleSelector
- We modify a bit some paddings/gaps

Task ID: 4502039

This update replaces deprecated internal checks with the newer supported approach in accounting reports and Studio areas. It helps keep the platform aligned with current Odoo standards and reduces future maintenance risk, without changing day-to-day user workflows.

`odoo.models.check_method_name` is deprecated, replace usages by the new method.

task-4505030
odoo/odoo#195402

Payroll users can now review working schedules more easily with clearer grouping for flexible hours, a filter for partial schedules, and total scheduled time shown in the list. This helps HR teams compare schedules faster and spot exceptions without opening each record.

changes ux for working schedule
Added grouping for flexible hours
add filter for partial working schedules
Included a field for total scheduled time in the list view

task-4313468

Sign request email links now remain valid for 15 days instead of 48 hours. This gives recipients more time to review and sign documents, reducing expired-link issues and follow-up requests.

**Purpose of the change:**

Extend the expiration duration of the link in the sign request email from 48 hours to 360 hours (15 days).

**Change summary:**

- Modified the `_generate_expiry_link_timestamp` method to retrieve a new expiration duration of 360 hours (15 days) instead of 48 hours.
- This change ensures that the sign request link remains valid for 15 days, improving usability.

**task-** 4517617

This update prevents errors that could occur when users create new records in forms across several business apps. It improves reliability during initial data entry, especially when fields are automatically calculated before the record is saved.

Companion of https://github.com/odoo/odoo/pull/195203

The customer portal ticket list now uses ticket ID as the default sorting option instead of creation date. This removes a redundant sorting choice and makes the list order better match how users expect to review tickets.

In the ticket list view of the portal, we can filter tickets by create date and by ID.
This is a bit redundant, and sorting by id reflects more accurately what we want to see.
Therefore, this PR removes the filter by create date to default to the filter by ID instead.

Task-4438387

Old sales commission screens that were no longer loaded by the system have been removed. This cleans up unused files without changing the day-to-day user experience.

Since odoo/enterprise#68424 a file holding team and team members views is not imported anymore. It seems fields have been removed anyway at least on member model, assuming it should have been removed. Anyway nobody complained.

This change reorganizes some internal model-building code into a separate file to keep the system easier to maintain. It should not change day-to-day behavior for users, but it helps developers manage related features more safely across modules.

Companion of https://github.com/odoo/odoo/pull/193559.

…nt reference for Dutch users The VAT payment reference in the Netherlands changes with each return and can be computed using a specific formula. This commit enables Odoo to automatically generate and propose the correct reference by default when users pay their VAT settlement from the dashboard. This feature streamlines the process for accounting firms, reducing the need to repeatedly log in to the Dutch Tax Authorities portal. task-4063832 Forward-Port-Of: odoo/enterprise#74770

…nt reference for Dutch users

The VAT payment reference in the Netherlands changes with each return and can be computed using a specific formula.

This commit enables Odoo to automatically generate and propose the correct reference by default when users pay their VAT settlement from the dashboard.

This feature streamlines the process for accounting firms, reducing the need to repeatedly log in to the Dutch Tax Authorities portal.

task-4063832

Forward-Port-Of: odoo/enterprise#74770

Since https://github.com/odoo/enterprise/commit/b198b60d337d2ea6a5d17872fb621322df57a20f get_invoiced should also return the invoice linked with the subscription based on the field account.move.line.subscription_id. Unfortunatly, if the query based on sale_line_ids found no invoice for a given origin_order_id, the invoice found based on subscription_id were not added. This can easily happen when the invoice are read by a user (for example odoo bot) that doesn't belong to the company of the

Since https://github.com/odoo/enterprise/commit/b198b60d337d2ea6a5d17872fb621322df57a20f get_invoiced should also return the invoice linked with the subscription based on the field account.move.line.subscription_id.

Unfortunatly, if the query based on sale_line_ids found no invoice for a given origin_order_id, the invoice found based on subscription_id were not added.

This can easily happen when the invoice are read by a user (for example odoo bot) that doesn't belong to the company of the invoice.

Solution: Invoice by origin_order_id should come from the result of the query + move_by_origin

Forward-Port-Of: odoo/enterprise#78603

Before this commit, the column of ticket ref field displayed in the list view of `helpdesk.ticket` has a size set to 30px. That hardcoded size makes the visibility of the content inside that column harder when the reference contains more than 6 digits. This commit removes the hardcoded size to let the framework computes the column size as before. opw-4524749 Forward-Port-Of: odoo/enterprise#78504

Before this commit, the column of ticket ref field displayed in the list view of `helpdesk.ticket` has a size set to 30px. That hardcoded size makes the visibility of the content inside that column harder when the reference contains more than 6 digits.

This commit removes the hardcoded size to let the framework computes the column size as before.

opw-4524749

Forward-Port-Of: odoo/enterprise#78504

Translate this new module. Translations were provided by MADI. task-4298921 Forward-Port-Of: odoo/enterprise#78659

Translate this new module. Translations were provided by MADI.

task-4298921

Forward-Port-Of: odoo/enterprise#78659

This commit aims to ensure that the expected working hours for flexible resources are not rounded to the hours when displayed on the Gantt progress bar. Previously, the total hours were being rounded to the hours, which could lead to inaccuracies in the representation of the expected working hours on the gantt view. By changing the rounding to the minutes, we ensure that the Gantt progress bar accurately reflects the precise hours worked by flexible resources. Steps to reproduce: -----------

This commit aims to ensure that the expected working hours for flexible resources are not rounded to the hours when displayed on the Gantt progress bar. Previously, the total hours were being rounded to the hours, which could lead to inaccuracies in the representation of the expected working hours on the gantt view. By changing the rounding to the minutes, we ensure that the Gantt progress bar accurately reflects the precise hours worked by flexible resources.

Steps to reproduce:
-------------------
1. Create an employee with flexible hours ex. 42:30h per week (8:30h per day)
2. Create a shift for the same employee on planning.
3. In the gantt view, when setting the date range to a week, the expected working hours of the period is showing 42h instead of 42:30h

task-id: 4506633

Forward-Port-Of: odoo/enterprise#77782

Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date - change the `date` argument while getting the `public_transport_max_amount` parameter because if it is None is gets the real date not the freeze one Task: 4509216 Forward-Port-Of: odoo/enterprise#78115

Issue: in testing with freeze_time if the date is None in `_get_parameter_from_code` arguments it takes the real today's date

- change the `date` argument while getting the `public_transport_max_amount` parameter because
if it is None is gets the real date not the freeze one

Task: 4509216

Forward-Port-Of: odoo/enterprise#78115

In this PR odoo/enterprise/pull/64323, certificates were refactored. However, one method has passed through the net and was left using the old way. This commit fixes that by removing the call and using the new refactored certificates opw-4423435 Forward-Port-Of: odoo/enterprise#78618 Forward-Port-Of: odoo/enterprise#77959

In this PR odoo/enterprise/pull/64323, certificates were refactored. However, one method has passed through the net and was left using the old way.

This commit fixes that by removing the call and using the new refactored certificates

opw-4423435

Forward-Port-Of: odoo/enterprise#78618
Forward-Port-Of: odoo/enterprise#77959

When attempting to click ``Closing Entry`` in Tax Return, an error occurs. Steps to reproduce: --- - Install the ``account_reports`` module - Create a branch in the Main Company - Accounting > Reporting > Tax Return - Click ``Closing Entry`` Traceback: --- ``AttributeError: 'account.report' object has no attribute 'show_error_branch_allowed'`` At [1], an error occurs because the attribute was used without calling the method. Because at [2], the method was added in version 18.0 bu

When attempting to click ``Closing Entry`` in Tax Return, an error occurs.

Steps to reproduce:
---
- Install the ``account_reports`` module
- Create a branch in the Main Company
- Accounting > Reporting > Tax Return
- Click ``Closing Entry``

Traceback:
---
``AttributeError: 'account.report' object has no attribute 'show_error_branch_allowed'``

At [1], an error occurs because the attribute was used without calling the method. Because at [2], the method was added in version 18.0 but later removed in the master branch.

[1]- https://github.com/odoo/enterprise/blob/2780da762cd430f45d97ea8fa230181ccc4e30f8/account_reports/models/account_report.py#L1971 [2]- https://github.com/odoo/enterprise/pull/73018/files#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ec

sentry-6237112729

Forward-Port-Of: odoo/enterprise#78482

Changes: 1. On click chatter button, scrolldown to chatter so that we know what happens. 2. Don't show 'Folders' if a record is selected. 3. Properly show control action buttons. 4. Display folder/files into 2 columns, 3 columns if landscape on mobile. Task-4380904 Forward-Port-Of: odoo/enterprise#78408 Forward-Port-Of: odoo/enterprise#76233

Changes:

1. On click chatter button, scrolldown to chatter so that we know what happens.
2. Don't show 'Folders' if a record is selected.
3. Properly show control action buttons.
4. Display folder/files into 2 columns, 3 columns if landscape on mobile.

Task-4380904

Forward-Port-Of: odoo/enterprise#78408
Forward-Port-Of: odoo/enterprise#76233

Before this commit, validating an order resulted in an error because the wrong model "account_move" was used instead of "account.move". opw-4543705 Forward-Port-Of: odoo/enterprise#78579

Before this commit, validating an order resulted in an error because the wrong model "account_move" was used instead of "account.move".

opw-4543705

Forward-Port-Of: odoo/enterprise#78579

As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box. However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root': ``` 2025-02-05 10:29:03,827 4815 ERR

As of iot box image >= 25_01 we introduces a user "odoo" which is responsible for everything related to the Odoo service on the IoT Box.

However, the Worldline related files are being downloaded and unzipped under 'sudo' command which means that the user "odoo" doesn't have access to them

This is an issue when trying to delete the old IoT handlers as it's done with the user "odoo" but Worldline files present in the 'ctep' directory belong to 'root':

```
2025-02-05 10:29:03,827 4815 ERROR ? odoo.addons.hw_drivers.tools.helpers: Failed to delete old IoT handlers 
Traceback (most recent call last):
  File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 435, in delete_iot_handlers
    unlink_file(*filenames)
  File "/home/pi/odoo/addons/hw_drivers/tools/helpers.py", line 534, in unlink_file
    path.unlink()
  File "/usr/lib/python3.11/pathlib.py", line 1148, in unlink
    os.unlink(self)
PermissionError: [Errno 13] Permission denied: '/home/pi/odoo/addons/hw_drivers/iot_handlers/lib/ctep/libeasyctep.so'
```

This PR runs Worldline related script under user "odoo" which fixes the ownership/access issues and allows Odoo service to delete the files.

task-4527243

Forward-Port-Of: odoo/enterprise#78544

Main: Encoding a SGTIN EPC requires a tracking number to make the tag unique. When the product is not tracked, a "fake" tracking number is used. Otherwise, we use the tracking number registered on the Move Line. However, depending on the state of the Move Line, lot_id may not be set and the tracking number will rather be available in lot_name. Currently, we only rely on lot_id, which may lead to an empty tracking number list, which in turn raises an unhandled exception. - We should try gett

Main:
Encoding a SGTIN EPC requires a tracking number to make the tag unique. When the product is not tracked, a "fake" tracking number is used. Otherwise, we use the tracking number registered on the Move Line. However, depending on the state of the Move Line, lot_id may not be set and the tracking number will rather be available in lot_name. Currently, we only rely on lot_id, which may lead to an empty tracking number list, which in turn raises an unhandled exception.

 - We should try getting the tracking number from lot_name when lot_id is not set;
 - We should handle the case where the tracking number list is empty.

N.B. : Only an empty tracking number list is problematic, the case of a list populated with null value is already handled by the epc_encoder.

Before:
 - We only get the tracking number from lot_id.name;
 - No verification is done on the tracking number list.

After:
 - Default to lot_name when lot_id is not set.
 - When the tracking number list is empty, set an error warning as the electronic_product_code on the concerned move lines.

Forward-Port-Of: odoo/enterprise#76702

Steps to reproduce: ------------------- 1. Install the Planning App 2. Pick a week and assign a shift from Monday to Friday for a resource A 3. Create two time offs for resource A: one on Tuesday and one on Thursday of the week after you created the shift 4. Now, in the planning gantt view, move to the next week (the week after you created the shift) 5. Use the copy previous week action 6. The copied shifts are split in a way they shouldn't. On Monday, Wednesday and Friday, there are two

Steps to reproduce:
-------------------
1. Install the Planning App
2. Pick a week and assign a shift from Monday to Friday for a resource A
3. Create two time offs for resource A: one on Tuesday and one on Thursday of the week after you created the shift
4. Now, in the planning gantt view, move to the next week (the week after you created the shift)
5. Use the copy previous week action
6. The copied shifts are split in a way they shouldn't. On Monday, Wednesday and Friday, there are two copied slots instead of just one.

Fix:
-------------------
Currently, the _merge_slots_values() method is called when we use copy previous week on a forecasted slot (> 24 hours), which is the case here. This method takes work intervals and unavailabilites in parameters, and returns merged slots by taking into account the unavailabilites. 
To fix the issue mentioned above, we removed a condition that only allows slots to be merged if their combination creates a forecasted slot (> 24 hours). But we argue that we should also be able to merge smaller slots (< 24 hours).

task-4368919
version-18.0

Forward-Port-Of: odoo/enterprise#76714

If a warehouse has multi-steps deliveries, the actual demand of a product only takes the real outgoing move into account: the move that goes directly to the customer location. Since moves are not created in advance anymore, we need to take the earlier moves in the chain into account instead while making sure that we only use a single move at a time. The move used will be the last created in the chain, the one without `move_dest_ids`. task 4510137 Forward-Port-Of: odoo/enterprise#77787

If a warehouse has multi-steps deliveries, the actual demand of a product only takes the real outgoing move into account: the move that goes directly to the customer location.

Since moves are not created in advance anymore, we need to take the earlier moves in the chain into account instead while making sure that we only use a single move at a time.

The move used will be the last created in the chain, the one without `move_dest_ids`.

task 4510137

Forward-Port-Of: odoo/enterprise#77787

Bug: When doing a departure holiday attest for an employee leaving in between years, the payslip of the current year are actually the ones from the previous year. Reason: We were computing the year based on the start of the notice period. Fix: The year is based on the end of the notice period when there is one. Task: 4547648 Forward-Port-Of: odoo/enterprise#78612

Bug:
When doing a departure holiday attest for an employee leaving in between years, the payslip of the current year are actually the ones from the previous year.

Reason:
We were computing the year based on the start of the notice period.

Fix:
The year is based on the end of the notice period when there is one.

Task: 4547648

Forward-Port-Of: odoo/enterprise#78612

After this commit https://github.com/odoo/enterprise/commit/574d608b21199d5590d2335f4360a0a6470d1257, The workflow actions have been removed and replaced by server actions and this PR is responsible for handling the migration of workflow actions into server actions.(see https://github.com/odoo/upgrade/pull/6729) ``` AttributeError: 'int' object has no attribute 'create_document_from_attachment' ``` We created server actions sending to `journal_id` as `int` when migrating dbs to 18.0. Wh

After this commit https://github.com/odoo/enterprise/commit/574d608b21199d5590d2335f4360a0a6470d1257, The workflow actions have been removed and replaced
by server actions and this PR is responsible for handling the migration of
workflow actions into server actions.(see https://github.com/odoo/upgrade/pull/6729)

```
AttributeError: 'int' object has no attribute 'create_document_from_attachment'
```
We created server actions sending to `journal_id` as `int` when migrating
dbs to 18.0. While the method originally supported only recordsets,
it's actually convenient to support `int`s here to avoid browse in the action
(more readable and more accessible to end-users).

opw-4453249

Forward-Port-Of: odoo/enterprise#76599

Steps to reproduce: CRM > Sales > Teams > Pipeline > Graph View >Insert Into Spreadsheet => Boom: Name 'active_id' is not defined. The action context contains a dynamic value, which needs the *current* to be evaluated. Task: 4548431 opw-4491590 opw-4500397 Forward-Port-Of: odoo/enterprise#78539

Steps to reproduce:
CRM > Sales > Teams > Pipeline > Graph View >Insert Into Spreadsheet

=> Boom: Name 'active_id' is not defined.

The action context contains a dynamic value, which needs the *current* to be evaluated.

Task: 4548431
opw-4491590
opw-4500397

Forward-Port-Of: odoo/enterprise#78539

Steps: - create a BOM for product A: component product B, ration 1.0, lead time 1 day - put 4 as the on-hand qty of product A - in the MPS, create records for products A & B with manufacture route for product A - put 6 as the forecasted demand of product A on the 2nd period or further (this is so that the indirect demand of B is shown on the previous period) Issue: The indirect demand of product B will be 6 instead of 2 (6-4). This is because it uses `date_stop` with the lead time, see

Steps:
- create a BOM for product A: component product B, ration 1.0, lead time 1 day
- put 4 as the on-hand qty of product A
- in the MPS, create records for products A & B with manufacture route for product A
- put 6 as the forecasted demand of product A  on the 2nd period or further
(this is so that the indirect demand of B is shown on the previous period)

Issue:
The indirect demand of product B will be 6 instead of 2 (6-4). This is because it uses `date_stop` with the lead time, see https://github.com/odoo/enterprise/pull/70232

Fix:
Subtract the starting qty from the indirect demand qty for the corresponding subproduct.
This is to make sure that the real `subproduct_indirect_demand` is compared to the
'ratioed' `replenish_qty` of the subproduct when selecting the date to use.

task 4381021

Forward-Port-Of: odoo/enterprise#75141

The following `response` was being returned when checking the CFDI status: ``` (Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None} ``` Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is h

The following `response` was being returned when checking the CFDI status:

```
(Pdb++) response {'CodigoEstatus': 'N - 601: La expresión impresa
proporcionada no es válida.', 'EsCancelable': None, 'Estado': 'No
Encontrado', 'EstatusCancelacion': None, 'ValidacionEFOS': None}
```

Since `CodigoEstatus` is already a string, there is no need to parse it again. Removing the extra line prevents the error that occurred when trying to re-parse text from a string and ensures the SAT status is handled correctly.

Forward-Port-Of: odoo/enterprise#78552

When sending templates en masse to multiple recipients they may sometimes have the same number. If their numbers are the same, and the template resolves to the same value there is no need to send them the template multiple times which could be considered as spam. Now if all template variables resolve to the same value, messages will be canceled immediately Similarly to what is done for emails. task-4029026 Forward-Port-Of: odoo/enterprise#78548 Forward-Port-Of: odoo/enterprise#66033

When sending templates en masse to multiple recipients they may sometimes have the same number.

If their numbers are the same, and the template resolves to the same value there is no need to send them the template multiple times which could be considered as spam.

Now if all template variables resolve to the same value, messages will be canceled immediately Similarly to what is done for emails.

task-4029026

Forward-Port-Of: odoo/enterprise#78548
Forward-Port-Of: odoo/enterprise#66033

Currently, an error occurs when installing the `l10n_us_hr_payroll` module, if user's default country is set to other than 'United States'. Steps to produce: - Change the default company country to other than US. - Try to install `l10n_us_hr_payroll`. - Observe the error. ``` ParseError: while parsing /home/odoo/src/enterprise/saas-18.1/ l10n_us_hr_payroll/data/hr_salary_rule_data.xml:39 Rule category and structure should belong to the same country View error context: '-no context

Currently, an error occurs when installing the `l10n_us_hr_payroll` module, if user's default country is set to other than 'United States'.

Steps to produce:
- Change the default company country to other than US.
- Try to install `l10n_us_hr_payroll`.
- Observe the error.
```
ParseError:  while parsing /home/odoo/src/enterprise/saas-18.1/ l10n_us_hr_payroll/data/hr_salary_rule_data.xml:39 
Rule category and structure should belong to the same country

View error context:
'-no context-'
```
The error occurs due to the validation rule in `hr.salary.rule` - [1]. Here, `rule.category_id.country_id`and `rule.country_id` must be the same. However, In the data record [2], `l10n_us_hr_payroll.hr_payroll_gross_pay` does not define the `country_id` [3].

According to [4], when `country_id` is not set, it defaults to the user's company country. If the user's company is not based in the US, this leads to a validation failure in `hr.salary.rule`, resulting in a `ParseError` while loading `hr_salary_rule_data.xml`.

This commit resolves the issue by setting `country_id=base.us` in the category definition [3]. It will prevent conflicts when the user's company has a different default country.

[1] - https://github.com/odoo/enterprise/blob/f3c071b6ca00fa834d6be1fc13550bbdf33c2eb6/hr_payroll/models/hr_salary_rule.py#L239-L240
[2] - https://github.com/odoo/enterprise/blob/f3c071b6ca00fa834d6be1fc13550bbdf33c2eb6/l10n_us_hr_payroll/data/hr_salary_rule_data.xml#L39-L47
[3] - https://github.com/odoo/enterprise/blob/f3c071b6ca00fa834d6be1fc13550bbdf33c2eb6/l10n_us_hr_payroll/data/hr_salary_rule_category_data.xml#L22-L26
[4] - https://github.com/odoo/enterprise/blob/f3c071b6ca00fa834d6be1fc13550bbdf33c2eb6/hr_payroll/models/hr_salary_rule_category.py#L20

sentry-6250322704

Forward-Port-Of: odoo/enterprise#78283

Currently, when cancelling a payment sent on a terminal, if you loose access to the internet, you will receive 2 different error. One of them explains Steps to reproduce: ------------------- * Connect an IoT box to the database * Configure a worldline terminal (ethernet) to be connected to the iot box * Create a payment method using that terminal and add it to a pos config * Open the corresponding pos session * Add items to order * Go to pay it, select the created payment method * Sen

Currently, when cancelling a payment sent on a terminal, if you loose access to the internet, you will receive 2 different error. One of them explains

Steps to reproduce:
-------------------
* Connect an IoT box to the database
* Configure a worldline terminal (ethernet) to be connected to the iot box
* Create a payment method using that terminal and add it to a pos config
* Open the corresponding pos session
* Add items to order
* Go to pay it, select the created payment method
* Send the request to terminal
* Disconnect ethernet cable from the worldline terminal
* Cancel the payment
> Observation: After the timeout, two errors appear:
1: underfined:undefined (Bug)
2: Please check if your iot box is still connected. (Normal)

Why the fix:
------------
This commit https://github.com/odoo/enterprise/commit/35a392c27e70ffb5f4a5d8ca32bf10c38d7f709c added one more error throwing other than `_onActionFail()` when sending requests. In our case since the error is due to a timeout, it will raise the `_onActionFail()` but also the `Promise.reject(e)`.

We consider that the `_onActionFail()` is enough for all potential failure here.

opw-4414175

Forward-Port-Of: odoo/enterprise#78348
Forward-Port-Of: odoo/enterprise#77555

Issue: Mobility budget is shown in every contract if it is installed on the db - make the budegt only visible for BE Task: 4529227 Forward-Port-Of: odoo/enterprise#78159

Issue:  Mobility budget is shown in every contract if it is installed on the db

- make the budegt only visible for BE

Task: 4529227

Forward-Port-Of: odoo/enterprise#78159

Manual forward port in 18.1 (for faster cherry-pick by internal team) of: https://github.com/odoo/enterprise/pull/77738 https://github.com/odoo/enterprise/pull/78487 Forward-Port-Of: odoo/enterprise#78594

Manual forward port in 18.1 (for faster cherry-pick by internal team) of:
https://github.com/odoo/enterprise/pull/77738
https://github.com/odoo/enterprise/pull/78487

Forward-Port-Of: odoo/enterprise#78594