Issue:
----------------------------------------
The default values aren't kept when using the previous/next arrows in planning calendar view.

Steps to reproduce:
----------------------------------------
- Go on a Project task
- Click the "To Schedule" button
- Switch to calendar view
- If we create now, the new slot will have the task as default value
- Click the arrow to switch to next week
- If we create there will be no default values

Cause:
----------------------------------------
Since 7b844902e5c3a7aeedda6cc2be61366caad2d144 the context is lost when using the arrows.

When switching to calendar view `load()` is called with the context in the params:

https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/web/static/src/model/model.js#L163-L164

But when using the arrows, it is called with only a date:

https://github.com/odoo/odoo/blob/786c373d5ac8afdfb79eb7a7d69c5eb83b919625/addons/web/static/src/views/calendar/calendar_controller.js#L426

So `...params.context,` is empty, and the context is only `hide_planned_dates: true,`.

Solution:
----------------------------------------
If no context is specified in params, we use the one in `this.meta` to allow changing the context by giving it in the params but keeping the previous context when it's not given.

opw-6211055

Forward-Port-Of: odoo/enterprise#118527

Problem: When both line discounts and global discounts are applied on a product in an invoice, the method `_add_and_round_raw_gross_total_excluded_and_discount` does not return the exact raw_gross_total_excluded before the modification done by other AccountTax helper methods, such as dispatching and squashing global discount lines.

Current Behavior: The calculation is done in the wrong order of operations. For example, there is an invoice for Product A valued at $100 with a discount of 10% and a global discount of $10. The raw_total_excluded will be $80 after the both discounts. The discount_factor is based on only the line discount of 10%. The formula of the current calculation for raw_gross_total_excluded is: (raw_total_excluded / (1 - (line_discount / 100))) - global_discount = (80 / 0.90) - (-10)
= 98.889
This does not equal the expected outcome of $100.

Expected Behavior: Based on the previous example, the formula for the calculation should be:
(raw_total_excluded - global_discount) / (1 - (line_discount/100)) = (80 - (-10)) / 0.9
= 100
The global discount needs to be added back to the raw_total_excluded to get the line discounted amount in order to divide by the discount_factor to gain the expected raw_gross_total_excluded before taxes and discounts.

Steps to reproduce the issue:
- Bug was encountered when implementing a global discount solution for l10n_co_dian.
- Create an invoice with a product line and in-line discount and another line for global discount
- Setup the base lines for the invoice and attempt the following:
 - _dispatch_global_discount_lines
 - _squash_global_discount_lines
 - _add_and_round_raw_gross_total_excluded_and_discount

opw-5412446


---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#266584
Forward-Port-Of: odoo/odoo#262137

**Steps to reproduce:**
- Create a flexible 32h/week calendar (8h/day, 4 days)
- Assign it to an employee with the Default Ruleset
- Create attendances: 8h on Monday, Tuesday, Friday, and Saturday (32h total, matching the weekly budget)
- Select the list view and go to the month of the attendances
- Employee shows 16:00 Worked Extra Hours (8h on Fri + 8h on Sat)

**Cause:**
`resource.calendar._attendance_intervals_batch` generates work intervals for flexible calendars by front loading the weekly hour budget onto the first days of the week (Mon 8h, Tue 8h, Wed 8h, Thu 8h for a 32h calendar), But days beyond the budget (Fri, Sat, Sun) get zero hours.

The two overtime rule paths relies on these synthetic intervals:

1) The quantity rule: `_get_daterange_overtime_undertime_intervals_for_quantity_rule()` computed `expected_duration` by intersecting the synthetic schedule with each day. For Fri/Sat the intersection was empty (expected = 0) -> all worked hours counted as overtime.

https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L302-L304

**update** solved by: https://github.com/odoo/odoo/pull/265120/changes/94d4bfffa053cd78ce07ff07ab14b53e8d931053

2) The timing rule: `_get_rules_intervals_by_timing_type()` derived "work_days" from the synthetic schedule and inverted them to get "non_work_days". (Fri, Sat, Sun) were classified as non-working days, therefore, any attendance on those days triggered full overtime.

https://github.com/odoo/odoo/blob/b31fd6816521ff43fb3a9ec37e79e9a9d628d357/addons/hr_attendance/models/hr_attendance_overtime_rule.py#L421-L433

**Solution:**
For flexible calendars in the overtime rule consumer:
- Quantity rules: read expected hours directly from the calendar's `hours_per_day` / `hours_per_week` instead of the synthetic schedule intervals, subtracting any leaves in the period
- Timing rules: treat the entire attendance date range (minus leaves) as potential work days, so that `non_work_days` is empty for flexible employees (they can work any day of the week)

opw-6067063

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#265976
Forward-Port-Of: odoo/odoo#263840

### Issue:
When a Sale Order is delivered but later reimbursed (e.g., via a credit note without a return), it is still considered as to invoice
As a result, it continues to impact the partner’s credit limit

### Cause:
Sale Orders remain included in the `credit_to_invoice` computation even when invoicing is manually considered finished
There was no way to exclude such orders from the credit limit calculation

### Fix:
Use the `invoicing_closed` field to mark Sale Orders as fully processed
When set, the order is excluded from the credit limit computation

### Steps to reproduce:
- Install `sale_management`
- In Settings, enable Sales Credit Limit (default: 3000)
- Create, confirm, and deliver a Sale Order for a new customer (any product, price: 2000)
- Duplicate the Sale Order → a credit warning is displayed
- Go back to the original Sale Order and use Close Invoicing from the gear menu
- Return to the duplicated Sale Order
The warning disappears as the closed order is no longer included in the credit computation

### Note:
For a complete business scenario, refer to the steps described in the related ticket

opw-6013369

Forward-Port-Of: odoo/odoo#262720

The "show only 1 month at a time" optimization computes the navigated month as datetime.now() + month_id, so the controller passes that (month, year) tuple to _get_appointment_slots:

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L833

For a punctual appointment whose Allow Bookings range starts in a future month, the first displayed month is start_datetime.month, so the (month, year) tuple doesn't match the month the visitor is looking at. The model fills an empty month and the recovery loop refills the first displayed month (where slots actually live):

https://github.com/odoo/enterprise/blob/57ec37b74a60c7e879a8afa66df5ab22a92c5bcd/appointment/models/appointment_type.py#L973-L988

The calendar the visitor just navigated to comes back empty.

Compute the navigation base from start_datetime when it lies in the future and keep datetime.now() otherwise. month_id is added on top of that base so it always matches the displayed month index.

Introduced by https://github.com/odoo/enterprise/commit/664857dd2c4ae2bc0dde8f44cb94136659ed2fe2

Steps to reproduce:
1. Open the Appointments app
2. Open an appointment type and set Schedule to Weekly and Allow Bookings to On specific dates with a range starting in a future month (for example 1 September to 31 December)
3. Save and click the Preview button in the header
4. Pick a staff member to reach the calendar
5. Click the right arrow to navigate to the next month

=> the next month shows "Sorry, we have no more slots available for this month"

opw-6206293

Forward-Port-Of: odoo/enterprise#117283

When a receipt dest location or delivery source location get archived, the corresponding move may not be taken into account when computing the total_value / avg_cost at date.

OPW-6099192

---

### Test result without fix

```
2026-04-23 06:30:34,016 10516 INFO oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: Starting TestStockValuation.test_archived_location_valuation ... 
2026-04-23 06:30:34,255 10516 INFO oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: ====================================================================== 
2026-04-23 06:30:34,255 10516 ERROR oes_test_19 odoo.addons.stock_account.tests.test_stockvaluation: FAIL: TestStockValuation.test_archived_location_valuation
Traceback (most recent call last):
  File "/home/odoo/Odoo/src/19.0/odoo/addons/stock_account/tests/test_stockvaluation.py", line 3326, in test_archived_location_valuation
    self.assertEqual(self.product_avco.with_context(to_date=date_1).avg_cost, 10)
AssertionError: 20.0 != 10
 ```

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#264694
Forward-Port-Of: odoo/odoo#260922

**Problem:**

Since this https://github.com/odoo/enterprise/pull/103846, `employee_version_id` depends on `contract_start_date` to adjust the employee state based on the contract date.

This introduced an unnecessary dependency chain:
```
contract_start_date -> employee_version_id -> contract_template_id -> wages and other offer fields
```

As a result, updating `contract_start_date` invalidates and recomputes the whole chain, even when `employee_version_id` does not actually change.

In addition, offer fields were coupled in a single compute, causing unrelated fields to be reset to template values when only one field required recomputation.

**Fix:**

- `contract_template_id` compute now depends on `employee_id` instead of `employee_version_id`, and directly uses the employee's `version_id`, breaking the chain while preserving default behavior.
- The offer fields computations were also split to avoid unintended recomputations and field resets.
- Simplified `_get_version` by always copying values from the template to the currently active version.
---

**Additional fix:**

The `is_hr_payroll` context flag is used to distinguish payroll vs recruitment flows when creating an offer with both `employee_id` and `applicant_id` unset.

A recent change in [Task #6094737](https://www.odoo.com/odoo/project/1251/tasks/6094737) did not account for this flag, causing both fields to be hidden when opening the form from Payroll (a new feature added in saas-19.3).

This is fixed by properly considering `is_hr_payroll`, restoring consistent behavior across all versions.

Task: 6158245
Forward-Port-Of: odoo/enterprise#115408

**Problem:**
When a branch user with no access to the parent company tries to create a transaction for a parent company's journal with a foreign currency set, this will raise an access error.

**Steps to Reproduce:**
- Make a branch of "My Company (San Francisco)"
- Set user "Marc Demo" to only have access to the branch
- Add a new bank journal set to "EUR" currency
- Switch to Marc Demo
- Try to add a transaction in the new bank journal

**Root Cause:**
When a transaction is created, Odoo determines the amount in company currency by converting it from the foreign currency. The method to convert currency uses "with_company()" to use the company's rates, but the allowed companies of the branch user does not have access to the parent company, causing an access error.

**Solution:**
Call the currency conversion with sudo() to ensure access to the relevant companies.

Ticket [link](https://www.odoo.com/odoo/project.task/6186901)
opw-6186901

Forward-Port-Of: odoo/odoo#263968
Forward-Port-Of: odoo/odoo#263425

**Steps to reproduce:**
* Install Peru - Accounting Reports (l10n_pe_reports).
* Create a vendor bill with Document Type 50 (Declaración Aduanera de Mercancías - DAM) and a document number in the standard pediment format (e.g. C235202610-38047).
* Go to Accounting > Reporting > Purchase Electronic Record (RCE 8.4).
* Export the TXT file and open it.

**Observed behavior:**
* Field 8 contains the full first numeric block of the document name including the year and sequence digits (e.g. 235202610) instead of only the 3-digit customs dependency code.
* SUNAT/SIRE rejects the file immediately because 235202610 does not exist in Table 4 (RS 040-2022), which only defines 3-digit codes.

**Cause:**
* `_get_serie_folio()` splits the document name by taking everything before the last digit group as the serie. For a name like C235202610-38047 this produces serie = "C235202610", and the existing `serie[1:]` logic strips only the leading letter, leaving "235202610" in field 8 instead of the 3-digit customs dependency code "235".
* The same incorrect value was also written to field 28 (aduana_code).
* ref : https://www.sunat.gob.pe/legislacion/superin/2022/anexo-040-2022.pdf

**Fix:**
* For document types 50 and 52, extract the first numeric group from the document name using `re.search(r'\d+', move_name)` and slice the first 3 characters to obtain the customs dependency code as defined in SUNAT Table 4 (always a 3-digit value).
* Apply the same logic to field 28 (aduana_code) for consistency.

opw-6157662

Forward-Port-Of: odoo/enterprise#115406

### Description of the issue/feature this PR addresses: 
**Issue:** When downloading vendor bills from KSeF via the cron, the system attempts to parse the XML files sequentially. If a single XML file is missing something that is expected, the parser raises a UserError. This unhandled exception halts the entire cron job and rolls back the database transaction, clogging up the rest of the queue.

**Solution:** This PR wraps the l10n_pl_edi_get_ksef_bill_vals_from_xml parsing step inside a try/except block within the batch download loop. If a UserError is encountered for a specific invoice, the error is logged as a warning, and the cron proceeds.

### Current behavior before PR:
A single malformed XML file causes the cron to fail completely. Valid invoices in the same batch are not created due to the halted queue.

### Desired behavior after PR is merged:
The cron successfully processes the batch of downloaded XMLs even if one or more files are invalid. Errors on specific invoices are logged for the user to investigate, while the rest of the valid vendor bills in the batch are succesfully created.

opw-6179479

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#266180

### Issue before this commit:
Importing a simplified Italian electronic invoice or credit note (e.g., TD08) fails with a float division by 0 traceback if a document line consists entirely of taxes (where the total line amount equals the tax amount).

### Steps to reproduce the issue:
1. Download Accounting and l10n_it
2. Switch to IT company
3. Go to Vendors > Refunds
4. Try to import the xml from the ticket

### Cause of the issue:
The XML parser attempts to dynamically calculate the tax percentage using the formula tax_amount / (amount - tax_amount). When a line is purely a tax adjustment, the taxable base (amount - tax_amount) evaluates to exactly zero, triggering the critical division by zero crash.
https://github.com/odoo/odoo/blob/e3b0ca11d99b2ef819cdad68b169112cd73668b6/addons/l10n_it_edi/models/account_move.py#L1863-L1867

### Reason to introduce the fix:
To ensure Odoo successfully imports valid, tax-only EDI documents already accepted by the Agenzia delle Entrate.

Ticket [link](https://www.odoo.com/odoo/project.task/6217373)
opw-6217373

Forward-Port-Of: odoo/odoo#267081
Forward-Port-Of: odoo/odoo#266374

### Steps to reproduce:

- In the settings enable dropshipping
- Create a storable product P, enable the dropshipping and set a vendor
- Create and confirm a sale order for a field service
- Open the related task > Products > Add 1 unit of P
- Go back to the sale order > an RFQ has been created
#### > The delivered quantity of P is set to 1

### Cause of the issue:

Since 2361368acfe7fecbffde2ca26392eb89aecdc9e1 the `_inverse_fsm_quantity` method manually adapts the delivered quantity based on the fact that the `product.service_type` is `manual` rather than the `qty_delivered_method` of the line or future line is. In particular, because these lines: https://github.com/odoo/enterprise/blob/8f4fe902cb71c49bdb3caf9915f9a5abfe6f237f/industry_fsm_sale/models/product_product.py#L82-L83
provide a value of the `qty_delivered` to the created purchase order line and since the `qty_delivered_method` is a precomputed field: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L225-L237
The fact that the purchase order line will be created with a `stock_move` `qty_delivered_method` and that the generated PO does not generate any move prior to confirmation will not trigger the dependency of the `qty_delivered` to retrigger a computation of the `delivered_qty` of the product which is suppose to be based on stock pickings: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/sale_order_line.py#L871-L876 https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale_stock/models/sale_order_line.py#L193-L198
Leaving the created sol with a delivered quantity of 1 prior to confirmation of the PO (which will generate move_ids related to the sol and trigger the compute).

Fix:

The changes of 2361368acfe7fecbffde2ca26392eb89aecdc9e1 regarding the `_inverse_fsm_quantity` appears unjustified with respect to the purpose of the fix. In addition, the `qty_delivered` and changes are already expected to be properly computed when the `qty_delivered_method` is not manual, particularly since the '`manual'` `service_type` is actually the default `service_type` corresponding to any 'consu' product and looks unrelated by any mean to the `delivered_qty` computation: https://github.com/odoo/odoo/blob/fdfd9851393ff82a265997478886bcad6da357d0/addons/sale/models/product_template.py#L165-L167

opw-6104326

Forward-Port-Of: odoo/enterprise#118131
Forward-Port-Of: odoo/enterprise#115760

## [FIX] web_gantt,planning: apply hasGroup before compute params

Before this commit, some actions like drag and drop gantt pills are
blocked for planning manager instead of being allowed only for them. The
reason is because the compute params is something made before checking
if the user is a planning manager and so the system will consider the
user is not a planning manager. The compute params is something made
before because the methods are executed inside 2 distincts onWillStart
hook and so OWL framework cannot know one hook depends on the other one.

This commit creates a method `onWillStart` in the main gantt controller
to be able to override it and be able to wait a rpc before processing
the compute params.

## [FIX] planning_field_service_sale_timesheet: don't count unscheduled intervention

This commit filters the interventions counted to display the field
service stat button in the form view of Sale Order. Now the intervention
unscheduled will no longer be counted and also the one linked to
plannable SOL.

## [FIX] planning_field_service: send email to customer when intervention published

Before this commit, the template "Field Service Scheduled" was unsused.

This commit uses that template to send an email to the customer once the
intervention is scheduled.

## [FIX] planning_field_service: send report when intervention completed and signed

Before this commit, the customer signs the intervention completed and
does not received any email with the intervention report. He has to
create an account in the DB as portal user to be able to see his
intervention or ask to contact person to send him the report by mail.

This commit will automatically send the intervention report by mail to
the customer once the intervention is completed and signed by the
customer.

## [FIX] planning_field_service: fix label and record_name in email sent for Field service

Before this commit, the button sent to the customer to see the
intervention is `View Planning Slot` and the record name used inside the
same email is the display name which is not useful for the customer.

This commit changes the label of the button displayed to see `View
Report` and change the record_name to show `Field Service -
<intervention date>` as shown in the portal view.

## [FIX] planning_field_service: no login required to access to intervention

Before this commit, the customer cannot access to the intervention
without begin log in even if he has the access token.

This commit changes the route access to let the user access to the
intervention completed and he can also sign it.

## [FIX] planning: hide duplicated name field in kanban displayed in gantt

This commit hides the duplicated name field displayed in the popover of
the gantt view in the planning.slot model.

## [FIX] planning_field_service: rename module name

This commit renames the module to call it `Field Service` instead of
`Planning - Field Service`.

## [FIX] worksheet: only show property warning message in mobile

## [FIX] planning: define employee_public_ids field in planning.slot

Before this commit, when a planning user goes to a shift he will see
Assign to me button on a shift assigned to another human resource which
is normally not allowed. The reason because the button is visible is
because `employee_ids` field is always empty for users who are not HR
user.

This commit adds `employee_public_ids` field which is also a computed
field non stored to get the employee for the user who is not a HR user.

## [FIX] planning_field_service: always compute break_time

This commit removes the default value on break_time field to always
trigger the compute of that field, the reason is because by default the
allocated_hours computed when we create a shift, will not always cover
the whole duration of the shift, the allocated hours of the shift is
computed based on the working schedule of the shift and so the
break_time field has to be computed afterwards to make sure the break
time is correctly set instead of having 0 by default when we create a
shift.

task-6060493

Forward-Port-Of: odoo/enterprise#112420

__

## Short functional explanation of the error
When rescheduling the deadline only of a task that has dependencies, other dependencies won't be moved in time, even if we select `Auto-Reschedule (Keep Buffer)`.

## Reproduction Steps
1. Go to Project. On a given project, click on the 3 dots on the top right of the project card. Then, click settings and under Task Management, check Task Dependencies.
2. Create 2 tasks for this project. On task 1, click on the Deadline field, then click on the top right of the calendar card to set a planned date.
3. On task 2, click on the Blocked By tab. Then, add a line with task 1. Select a planned date like you did with task 1.
4. Go back to the project and on the top right, click on the Gantt view. Make sure that above the calendar, the Auto-Reschedule (Keep Buffer) option is selected. Then, move forward (or backward) the deadline of task 1 by only clicking on the right edge of the pill and dragging/dropping it to the left/right.

### Expected behavior
As task 2 depends on task 1, and we need to keep the buffer. The start date of task 2 should be moved left when we drop the deadline of task 1 further left, or right when we move the deadline of task 1 further right.

### Unexpected behavior
Nothing happens.

## Origin of the issue
### JS side
When we click on the whole task 1 and drag it to the right (thus changing the start date *and* the deadline), the dependent tasks are also moved right. When performing this action, this calls the method `dragPillDrop`. In it, we can see this piece of code: https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_renderer.js#L1484-L1489 where `this.isAutoPlan` indicates whether we checked the Auto-Reschedule (Keep Buffer) option. In that case, we call `rescheduleAccordingToDependency`, which performs this ORM call: https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_model.js#L500

However, when only moving the deadline of the task, we call the method `resizePillDrop`. In this method, we don't check if `this.isAutoPlan` is True, as we perform in all case the call to: https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_renderer.js#L2822 Which will trigger the orm call:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/static/src/gantt_model.js#L479 which will call the `web_gantt_write` method in Python, only writing on the task we changed the deadline of.

### PY side
Inside `web_gantt_reschedule`, to reschedule dependent tasks, we have to reach the method call:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L247 However, there's a condition preventing us from reaching that code when only changing the deadline:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L230-L235 Yet, we need to trigger the code and reschedule dependencies even if there's no planned date as soon as we change the deadline.

Once we're in `_web_gantt_action_reschedule_candidates`, we check if we're in the case of preponing or postponing the task (i.e the direction of the rescheduling):
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L410 This call is performed with `start_date_field_name`, which is present in the `vals` in the case of moving a whole task. Yet, in our case, we only move the deadline, so `start_date_field_name` isn't in our `vals`. So, to get the direction of our rescheduling, we have to use `stop_date_field_name` instead.

Then, we perform this call:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/web_gantt/models/models.py#L412 However, in our case, the dependent tasks are still found under the `dependency_inverted_field_name` field.

This leads us to the return of the function, where we call `_web_gantt_move_candidates`. In it, we retrieve the previous values of the pill we're modifying with:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/project_enterprise/models/project_task.py#L1366 using `vals`. Later we use `start_date_field_name` to update the dates of dependent tasks:
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/project_enterprise/models/project_task.py#L1413-L1415 Still, in our case, we don't have `start_date_field_name` in vals. Thus, we have to define `old_vals_per_pill_id[self.id][start_date_field_name]`.

Next, we define the start date and end date of the intervals in which we reschedule the dependent tasks (so, the left and right bounds of intervals):
https://github.com/odoo/enterprise/blob/e113c851e6fa9a7a3c1dca840926ed7e58b3f16f/project_enterprise/models/project_task.py#L1392-L1401 In case of a `search_forward`, this is natural. Nevertheless, in the case of a backwards search, we can't consider the start date of the first task to be the right bound for our dependent tasks, as they occur after the first task! This would mean that our right bound is set before the dependent tasks even start. So, in our case of changing only a deadline, we have to set the right bound to the latest deadline of the dependent tasks. They won't be set to later, as we are moving the deadline backward.

Finally, in the case of setting a deadline backwards, we have to keep the time gap between task 1 and the dependent tasks, based on the working hours. This feature wasn't implemented.

__
opw-6080405

Forward-Port-Of: odoo/enterprise#117815
Forward-Port-Of: odoo/enterprise#113787