This commit provides a cron job to migrate attachment binary to the
cloud storage. The cron job is designed to be manually triggered from
by the "Run Manually" button of the Scheduled Action's form view.

The cron job will try to upload some attachments once
    1. size is greater than the minimum upload file size defined by
       (ir.config_parameter: cloud_storage_min_file_size)
    2. id is greater than the number defined by
       (ir.config_parameter: cloud_storage_migration_min_attachment_id)
    3. res_model is in a white list
       (ir.config_parameter: cloud_storage_migration_message_models)
       (ir.config_parameter: cloud_storage_migration_all_models)
    4. not used by documents.document
 
optional configurations to avoid timeout issues
- cloud_storage_migration_max_file_size:
  max bytes for each migrated attachment
- cloud_storage_migration_max_batch_file_size:
  max total bytes for migrated attachments in one cron job execution

The cloud_storage_migration_min_attachment_id which can be accessed
from the list view can be treated as the progress of the cron job.
Manually setting it to 0 and retriggering the cron job will retry the
upload process for previously failed or ignored attachments.

taskid: 5387110


Steps

1. install a cloud storage module (cloud_storage_google, cloud_storage_azure)
2. install the cloud storage migration module (cloud_storage_migration)
3. Go to Settings for Cloud Storage Settings <img width="505" height="206" alt="image" src="https://github.com/user-attachments/assets/d72d7b52-5ce7-4209-8645-4a8ac35dd049" />
4. [Configure the cloud storage settings](https://www.odoo.com/documentation/19.0/applications/general/integrations/cloud_storage.html)
5. Setting the Minimum File Size. Attachments smaller than the size won't be uploaded to the cloud storage <img width="457" height="96" alt="image" src="https://github.com/user-attachments/assets/8dc4e6fe-9c84-44f5-a83a-28c7b2fad30a" />
6. After 4, configure settings for the cloud storage migration 
&nbsp;&nbsp; a. <img width="464" height="209" alt="image" src="https://github.com/user-attachments/assets/37352453-ff0e-4e03-a4d5-7fdb8168dee1" />

&nbsp;&nbsp; b. Cron Job:
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i. the link to the cloud storage migration cron job
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ii. the cron job is designed to be a job only triggered by clicking "Run Manually".
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; iii. It will re-trigger itself until all relevant attachments are migrated.

&nbsp;&nbsp; c. Parameters:
<img width="882" height="571" alt="image" src="https://github.com/user-attachments/assets/9926ed9f-81ac-4917-b759-872ed2584217" />

&nbsp;&nbsp; d. Progress Bar:
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i.progress of the migration job
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ii. calculated by `cloud_storage_migration_min_attachment_id / cloud_storage_migration_max_attachment_id`

&nbsp;&nbsp; e. Attachment Report:
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i. <img width="1907" height="298" alt="image" src="https://github.com/user-attachments/assets/33a77835-c6b6-4bc4-b20a-4ec68acba783" />
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; ii. a view to help administrator analyze which model's attachments should be migrated

&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; iii. help to configure step 6.c.i.4 and step 6.c.i.5

&nbsp;&nbsp; f. Message Attachments
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i. help to configure step 6.c.i.4

&nbsp;&nbsp; g.All attachments
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; i. help to configure step 6.c.i.5


7. Click Cron Job and then Click Run Manually 
<img width="409" height="123" alt="image" src="https://github.com/user-attachments/assets/f60cdfcf-e6a6-4503-87fc-0be7f14ceede" />




Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#239052
Forward-Port-Of: odoo/odoo#235745

Description
-----------
Following odoo/odoo@238a41e35280256382f6509182b9e900fb4f7aba, the domain for `sale.order.line` in `_get_sale_order_items_query` was modified to search based on the relevant `order_id` `id` or `project_id`. `project_id` is not indexed, leading to a heavy non-selective scan on the primary key for databases with many `sale. order` records. There is poor selectivity with the filter on `sale. order.line` resulting in a heavy join between `sale.order` and `sale.order.line`.

This commit adds the missing index, allowing for `Bitmap Heap Scan` on both indexes and leveraging the selectivity of the project being currently opened.

Benchmark
---------
On a database with 3.5M `sale.order`, 12M `sale.order.line`, opening the "Settings" page of a project with a few sale lines associated with it took:

|              | Before | After |
|--------------|--------|-------|
| Timing (hot) | 9.1s   | 5ms   |

Reference
---------
opw-5280364

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

Forward-Port-Of: odoo/odoo#239114
Forward-Port-Of: odoo/odoo#238995

Step to reproduce:
- Install l10n_in_hr_payroll.
- Create 3-4 employee with labour welfare fund, all in different departments.
- Open the LWF report wizard and do not select any department.
- Download report , all employee will come in report.
- Now select any department and download report again.
- All employee(It is fetching previous data) + employee from selected
  department will come in report.

Cause:
- In '_compute_line_ids()' wizard computed field 'line_ids' doesn't properly
   reset previous lines as a result previous data remains in lines.
- When the department is changed, the wizard id remain same,
  so previously lines added to wizard are coming with new lines.
- Using `Command.link()` for new lines is invalid because it requires an
  existing database record ID, but wizard lines are creating inside a compute
  method so their IDs are only saved after the flush.

Fix:
- Since this is a stable version, clear the previously existing lines using
  'Command.clear()' before creating new ones.

Task - 5366498

Forward-Port-Of: odoo/enterprise#101190

Clicking a record in the Employee Skills pie chart report currently triggers a traceback.

Steps to reproduce the error:
- Install ``hr_skills`` module with demo data
- Open any employee > In Resume tab, Click on TIMELINE
- Switch to Pie chart > click on any record

Traceback:
```py
UndefinedColumn: column hr_employee_skill_history_report.id does not exist
LINE 1: SELECT "hr_employee_skill_history_report"."id" FROM "hr_empl...
```

``hr.employee.skill.history.report`` model is ``_auto=False``,
meaning that no database table is created for this model.
In earlier versions, clicking on the record opens the list view.
In the [commit](https://github.com/odoo/odoo/commit/341fe890d2b7001dab1e3cd65ecb0c3bb4ed327e), list view was removed.
So, now clicking on the record will lead to the above traceback.

[1]: https://github.com/odoo/odoo/commit/341fe890d2b7001dab1e3cd65ecb0c3bb4ed327e

sentry-7099766240

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

#### [FIX] snailmail: extract report PDF generation function
We extract a function `_generate_report_pdf` from `_fetch_attachment`
to create the report PDF (and its filename).
The resulting PDF's margins are fixed and a cover page is added to it
after the function is called in `_fetch_attachment`.

The new function is extended in the related enterprise commit to generate the
followup report inside `_fetch_attachment` (when sent via snailmail).
This way it will respect the cover page option and page layout / size requirements.
(See the related enterprise PR for more details.)

#### [FIX] snailmail: extract letter resending function

We extract a function `_resend_letters` from the `update_resend_action`.
It handles the regeneration of letters after the cover option has been updated.
This way the resending logic can easily extended to adjust the logic depending
on attributes of the letter.

The new function is extended in the related enterprise commit to disable
the resending for followup report letters.
This is necessary because the followup report requires special options
to be generated that are not available at the point of the regeneration.

#### references

opw-5160121
opw-5209504
opw-5226366

Forward-Port-Of: odoo/odoo#238905
Forward-Port-Of: odoo/odoo#235699

#### [FIX] snailmail_account_followup: fix address, cover page and layout

Currently there is the following potential problem when sending
the followup report via snailmail.
1. The address generation is not adjusted for snailmail. That can
   lead to problems with the service we use to send the actual letter.
   They validate the address rather strictly.
2. The cover page option does not work; it does not add a cover page.
   So we can not work around problems with the address generation
   by adding a cover page.
3. The layout / dimensions / margins of the generated document / PDF may not work
   with our current snailmail provider (Pingen). But there is no error
   message about it. (Although we do have something in the usual
   snailmail flow)
4. In case the address is invalid we do not try to "print" / send the letter,
   so the user does not receive any feedback.
   This could be an issue in case multiple follow-up reports are sent
   at the same time.

This commit fixes these issues. (See below for details.)

(1)
The logic for this already exists but it is only activated when
a context key is set. This is not the case currently.
After this commit we do set the key.

(2) & (3)
The issue is that we generate the PDF attachment before creating the
'snailmail.letter' record.
In the usual snailmail flow the PDF attachment generation is handled during the sending and
printing (in function `_fetch_attachment` on model 'snailmail.letter').
There is some special logic to
- add a cover page to the report PDF (if the option is selected)
- make sure the page dimensions of the PDF are okay
- overwrite the margins of the PDF with white to make sure the PDF is
  not rejected by Pingen because of this

But all this only happens if we do not have an attachment already.
(So it does not happen currently with the followup report)
For this a function called `_generate_report_pdf` was extracted from `_fetch_attachment`
in the related community commit to generate the report PDF (and its
filename). The function is extended here to be able to generate the
followup report.

(4)
We try to print / send the letter even if the address is invalid

Reproduce (i.e. for the cover page issue; but it explains how to get
the PDF that will be sent in general)

1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Set the "Add a Cover Page" option
   (Settings -> Accounting -> section "Customer Invoices")
   - enabled to test for the cover page
   - disabled to test that the address generation is adjusted
4. Send a follow-up report:
   - On 17.0: Accounting -> menu: "Customers" /  "Follow-up Reports"
     -> click on a line / partner -> button "Follow up"
   - On 18.0+: partner form view -> tab "Accounting"
     -> section "invoice follow-ups" -> button "Send"
5. Go to the snailmail letter:
   In debug mode: Settings -> menu: "Technical" -> section: "Email" -> "Snailmail Letters"
   (or just search for "snailmail" in the main screen)
   And select the letter
6. Download the PDF document

#### [FIX] snailmail_account_followup: forbid regenerating failed letters

The wizard to resend failed letters which allows to change the
cover page option is broken: The follow-up report can not be regenerated
correctly because it requires special follow-up specific `options` that are
lost after the initial pdf generation for the letter.

Currently it can happen that the follow-up PDF is regenerated but
without (actual) content (table listing the overdue amounts).

After this commit we cancel the snailmail letters and show an
error notification indicating that the followup needs to be done again to
create a new letter.

Reproduce
(needs credit on IAP or locally edit this function https://github.com/odoo/odoo/blob/3ffd51f1cb18e3f4fb0367c4a498d7438e0c0357/addons/snailmail/static/src/core_ui/message_patch.js#L11
to open the resend wizard `this.openFormatLetterAction()` for `sn_credit` error or always)

1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Ensure the address of the partner causes issues with Pingen
4. Ensure the cover page option is disabled:
   Settings -> Accounting -> section "Customer Invoices"
5. Send a follow-up report:
   - On 17.0: Accounting -> menu: "Customers" /  "Follow-up Reports"
     -> click on a line / partner -> button "Follow up"
   - On 18.0+: partner form view -> tab "Accounting"
     -> section "invoice follow-ups" -> button "Send"
6. Make some modifications like editing the follow-up message or a custom attachment
7. Download the snailmail letter PDF (see previous commit for details)
8. In the chatter go to the message saying "Letter sent by post with Snailmai"
9. Click on the red symbol (paper plane) next to the name
10. A "Format Error" wizard should show up
11. Select "Add a Cover Page"
12. Click the button "Update Config and Re-Send"
13. Download the snailmail letter PDF (see previous commit for details)
14. Compare PDFs from 7 and 13; they are different (not just the cover page)

#### references

opw-5160121
opw-5209504
opw-5226366

Forward-Port-Of: odoo/enterprise#101596
Forward-Port-Of: odoo/enterprise#99491

Steps to reproduce
-----
- Enable batch pickings
- Create a product
- Create 2 receptions for the product (qty > 1)
- Create a batch with the 2 transfers
- Open the batch in barcode
- Scan part of both pickings
- Go back to the barcode main screen
- Open the batch again

> Both pickings have their demand = partially delivered quantity

Cause
-----
When leaving the page, we trigger

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L65-L68

in which we end up merging the moves together

https://github.com/odoo/enterprise/blob/91d6a096e88e4f11d7504d7a4052a57e2cb09ca8/stock_barcode/models/stock_move.py#L51

This has been added by 9753c24 (ade0bef in 17.0)

The problem is that `_merge_moves` merges all of the moves into the first of `merge_into`

https://github.com/odoo/odoo/blob/26761e04bb648b46cd35697c6cbc8ed1e27fef90/addons/stock/models/stock_move.py#L1086-L1088

This, however, doesn't make much sense for batches because the moves can be from different pickings.

-----
Ticket:
opw-5163740

Forward-Port-Of: odoo/enterprise#101630
Forward-Port-Of: odoo/enterprise#100940

BUG 1:
---------
**steps to reproduce**:
1. Install documents
2. Open any document
3. Go to Action > Rename
4. Rename the document
5. Preview it and read the name showed there

**issue**:
When previewing the document, it still shows the old attachment name.

**observation**:
When renaming a document, only the document name was updated. The attachment name remained unchanged, which caused inconsistencies:

1. In the All Records section, the document name is displayed correctly. https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/views/documents_document_views.xml#L130

2. But in the Preview, the old attachment name was still shown, as it is taken from the attachment:
https://github.com/odoo/enterprise/blob/459e8ddaf6f67a556d35bf00e0fbb68eb1500a94/documents/static/src/views/hooks.js#L373-L383

**solution**:
Use the document name when previewing it

BUG 2:
---------
**steps to reproduce**:
1. Install Documents.
2. Open any document.
3. Rename it via the chatter.
4. Try renaming it again via the details panel.

**issue**:
After renaming a document twice through the details panel, the preview still displayed the old document name.

**cause**:
On the first rename, the [insert](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/core/document_service.js#L96-L129)) method creates a new [store.Document](https://github.com/odoo/enterprise/blob/691115d8a0b31322f64d35d82dc8c9ddbfcd39b0/documents/static/src/views/hooks.js#L367-L393) record with the updated attachment name. However, The write method (used by chatter) skips reloading the record and linked attachment data on the second rename.

Unlike the Rename button, which uses web_save (and triggers a record reload via web_read), the chatter directly calls write without refreshing the attachment.

**Solution**:
Ensure the preview uses the document name from the document record, keeping it consistent after multiple renames via the details panel.


**Example:** Try to rename a "Invoice.pdf" document to "Invoice_rename.pdf"
<details>
    <summary>Click here to see the results:</summary>
    Before:
    <img src="https://github.com/user-attachments/assets/563b7fb9-709c-4651-8492-032a7f353730"/>
    After:
   <img src="https://github.com/user-attachments/assets/6fc6bdfe-dd1e-4f3c-aaf7-821c44fd135d"/>

</details>

opw-5065433

Forward-Port-Of: odoo/enterprise#101183
Forward-Port-Of: odoo/enterprise#95111

Issues:

1. Resetting options when dialog is closed without modification:
When the media dialog is closed without changing any options
and "Add" is clicked, the videoSelector component is reset, causing
previously selected parameters to be lost.

- Steps to reproduce:
    - Drop a Video snippet.
    - Double-click the snippet and toggle a few options (e.g., "Loop").
    - Save the video configuration.
    - Double-click the snippet again to open the video configurator.
    - Save without making any changes.
    - The options will be reset.

2. Embedding videos via Powerbox does not capture URL query parameters:
When embedding a video via Powerbox, option values from the URL
query parameters (like loop or autoplay) are not correctly applied.

- Steps to reproduce:
  - Add any Text snippet.
  - Paste a YouTube video URL with query parameters (e.g., ?loop=1&autoplay=1).
  - Choose to embed the YouTube video from the Powerbox popup.
  - The Video snippet is added without options enabled for the pasted URL.

3. Manual URL editing does not synchronize options:
Editing the video URL manually does not update the toggle states
of corresponding options.

- Steps to reproduce:
  - Drop a Video snippet.
  - Double-click the snippet and append query parameters to the URL.
  - The option buttons should toggle according to the parameters, but they do not.

4. Dailymotion preview fails for protocol-independent URLs:
Previewing Dailymotion videos fails for URLs like //[www.dailymotion.com/](http://www.dailymotion.com/)....

 - Fixes implemented:
    - Preserve selected options when saving the Video snippet without any changes.
    - Retrieve all query parameters from the URL and include them in the RPC request.
    - Synchronize option toggles with the URL input when the user manually edits it.
    - Fixed the Dailymotion regular expression to support protocol-independent
    URLs (e.g., //[www.dailymotion.com/](http://www.dailymotion.com/)...).

task-4529118

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

Forward-Port-Of: odoo/odoo#238732
Forward-Port-Of: odoo/odoo#210596

### Issue:
When installing "l10n_tr_nilvera" on a new DB the Turkish language is installed but
the translation of previously installed modules are not updated.

### Steps to reproduce:
- Install 'l10n_tr_nilvera' and switch to a Saudi company
- Check the view "report_invoice_document"
- Click the translation icon on the view
- No Turkish translations are loaded

### Cause:
When installing "l10n_gcc_invoice" the Arabic language is installed ([src](https://github.com/odoo/odoo/blob/70404624d7ea6f971182cbe4f4fe8fc064d2afd8/addons/l10n_gcc_invoice/__init__.py#L4-L5)). But the method [`_activate_lang()`](https://github.com/odoo/odoo/blob/70404624d7ea6f971182cbe4f4fe8fc064d2afd8/odoo/addons/base/models/res_lang.py#L161-L169) only activates the language, it does not update the translations.

### Solution:
Create a new method that activate the language and calls `_update_translations()` on the installed modules.

opw-5219783

Forward-Port-Of: odoo/odoo#239310
Forward-Port-Of: odoo/odoo#237041

This improvement enhances user control over cookie preferences by making
the Cookie Policy page (/cookie-policy) more accessible and allowing
users to modify their consent at any time.

**Issue:**

- Previously, the only way to access the Cookie Policy page was through
  the link in the cookie consent popup. However, once users accepted
  cookies, the popup was no longer displayed, making it impossible to
  navigate to the policy page later.

- Additionally, the Cookie Policy page had a button to reopen the cookie
  consent popup, but it was only visible if cookies were not accepted.
  Once cookies were accepted, the button was hidden, preventing users
  from changing their preferences.

**Improvements:**

- Added a permanent link to the Cookie Policy page in the copyright
  footer, ensuring it remains accessible at all times.

- The cookie consent toggle button now remains visible even after a user
  has accepted cookies, allowing them to update their preferences at any
  time.

task-[4502416](https://www.odoo.com/odoo/project/974/tasks/4502416)

Forward-Port-Of: odoo/odoo#238772
Forward-Port-Of: odoo/odoo#203409

Currently, an error occurs when trying to create a consolidated invoice for 
multiple POS orders associated with the same customer.

**Steps to reproduce:**

- Install the `l10n_sa_pos` module and switch to the `SA company`.
- Create two POS orders for the `same customer` without invoicing at checkout.
- Close the POS session and go to `Point of Sale` > `Orders`.
- Select both orders > click `Create Invoice` > `confirm` the action. (Make sure `Consolidated Billing` is enabled)

**Error:**
`ValueError: Expected singleton: pos.order(8, 7)`

**Root cause:**
At [1], the code accesses `self.date_order` and `self.l10n_sa_reason`, but when 
consolidated billing is enabled, self contains multiple POS orders, which 
causes an error.

**Fix:**
This commit prevents the error by ensuring that the current datetime is
assigned when creating a consolidated invoice, same as [2]. 
For the refund reason, a fix similar to [3] has been applied.

[1]:
https://github.com/odoo/odoo/blob/0c87b6b8836522913dbe77b57a018ac26012edca/addons/l10n_sa_pos/models/pos_order.py#L17-L18

[2]:
https://github.com/odoo/odoo/blob/583bacdc8ad2b87b99b11d1e12dacf6e42edf22b/addons/point_of_sale/models/pos_order.py#L828-L832

[3]:
https://github.com/odoo/odoo/blob/0c87b6b8836522913dbe77b57a018ac26012edca/addons/l10n_es_edi_tbai_pos/models/pos_order.py#L103-L107

opw-5266908

Forward-Port-Of: odoo/odoo#237677

Before this commit, internal URLs (i.e. "blob:" and "data:") required                                                                                                                     
'fetch' to be mocked to work. This is wierd because these requests are                                                                                                                    
handled directly by the browser and shouldn't require any particular                                                                                                                      
manipulation from the (mocked) server.                                                                                                                                                    
                                                                                                                                                                              
This commit ensures that internal URLs still work without fetch being                                                                                                                     
mocked.    

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

Forward-Port-Of: odoo/odoo#239237
Forward-Port-Of: odoo/odoo#239011

**Steps to reproduce:**
- Go to a Contact
- Go to the actions dropdown menu of the record
- Grant Portal Access
- Revoke that Access
- Create a new Website in the same Company that Portal Access was granted
- That Contact's user will be set as the Public User for the new Website
- New orders and other default public user behavior will be assigned to this user
- The user will be mentionned in non-logged interactions

**Issue:**
Archived portal user are set as public user when revoked, and the default public user of a website is set on create to the first public user it finds in `_get_public_user`:
```
public_users = self.env.ref('base.group_public').sudo().with_context(active_test=False).users
public_users_for_company = public_users.filtered(lambda user: user.company_id == self)

if public_users_for_company:
    return public_users_for_company[0]
```

This seems to be an issue as such user can be reactivated or be assigned to some transactions it has not made (confidentiality issue).

**Fix:**
Not sure of the best way to fix this. We could ensure new website always creates a new public user, or find a better way to use by default the `self.env.ref('base.public_user')` (or its company-specific copies) for the company of the website during creation (or in `_get_public_user`).

For now the fix remove the public group on the revoked portal user, to still be able to reactivate it later on, without mistaking it for the default public user of a company.

Also we can't remove the `with_context(active_test=False)` as default public user always seems to be disabled.

related: https://github.com/odoo/odoo/commit/83e22fd0636748c4fe1058fb93adfad2623fc31b

opw-4760550

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

Forward-Port-Of: odoo/odoo#236014
Forward-Port-Of: odoo/odoo#233757

Steps to reproduce:
--------------------------
1. Install the Quality module.
2. Create a Quality Control Point with:
   * Control per: Control on Operation.
   * Operation: Receipts (set in the Operations field).
3. Create a Receipt containing one product.
4. Click the Mark as To Do button.
5. Add another product to the same Receipt and save it.

Observation:
--------------------------
Two quality checks are generated for the same picking, despite the tooltip indicating that only one check should be created per operation.

Issue:
--------------------------
No validation existed to verify whether an operation-based quality check had already been created for the picking when adding additional stock moves after confirmation.

Solution:
--------------------------
Add a check ensuring that if a quality check already exists for the same picking type and operation (with no product or category criteria), no additional operation-based quality checks are created.

opw-5249233

Forward-Port-Of: odoo/enterprise#100118

Steps to reproduce:
-
  1. Install Planning module.
  2. Create a new employee without setting a contract start date.
  3. Go to the Planning Gantt view by resource.

Issue:
-
The Planning Gantt view incorrectly grays out the entire schedule for newly created employees. It can also incorrectly gray out the initial days of a contract.

Cause:
-
1) With the introduction of `hr.version`, a version is now created for every employee by default. The logic to identify employees with a contract history was using a domain `[("employee_id", "in", ...)]`, which selects all employees, even those with no contract. This incorrectly flagged new employees as having a contract history, causing them to be marked as unavailable.

2) The view was using the computed `version.date_start` field. The computed `date_start` is calculated as the maximum of the version's creation date and the contract's start date. (e.g., contract starts Sep 1st, version created Sep 5th), the computed start date becomes Sep 5th, incorrectly graying out the period from Sep 1st to Sep 4th.

Fix:
-
1) The query that checks for an employee's contract history is now filtered by `('contract_date_start', '!=', False)`.

2) The Gantt view's working period calculation now uses the stored, `contract_date_start` and `contract_date_end` fields.

task-5058866