### Steps to reproduce:
- Install **field service** app.
- Go to **field service**, and convert the view to **Calendar**.
- Click on a task and try to drag it. You **_can't_** drag and drop a task.

### Investigation:
- the `date_start` option is `planned_date_start` https://github.com/odoo/enterprise/blob/dab59cb6dea28f13b6b984b19d844fc9ad6f2006/industry_fsm/views/fsm_views.xml#L91
- which is a **computed -readonly-** field https://github.com/odoo/enterprise/blob/a29e55f7ac02a0c2b34c9714397c5a1322785833/project_enterprise/models/project_task.py#L31
- That's why, we can't drag the task.
- The `planned_date_start` field was added because the `start_date_begin` field was **optional** and so to be able to view tasks with only a deadline a no start date, the field `planned_date_start` was added with the compromise of not being able to drag the task
- The `planned_date_begin ` field is now **required** tho. and so no need to make such compromise as an fsm task will always have a start date `start_date_begin`

opw-3750403

Forward-Port-Of: odoo/enterprise#59256
Forward-Port-Of: odoo/enterprise#58316

When we use the `|` (or) version of this rule the ORM generates two sub-queries when checking the company. This causes sub-optimal and in some cases really bad planning for the queries and thus PG takes hours to complete them.

Example (formatted):
```sql
    SELECT "mrp_routing_workcenter".id
      FROM "mrp_routing_workcenter"
 LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
        ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
     WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
       AND (  ("mrp_routing_workcenter"."bom_id" in (
                    SELECT "mrp_bom".id
                      FROM "mrp_bom"
                     WHERE ("mrp_bom"."company_id" in (1))
                   )
              )
           OR ("mrp_routing_workcenter"."bom_id" in (
                    SELECT "mrp_bom".id
                      FROM "mrp_bom"
                     WHERE "mrp_bom"."company_id" IS NULL
                   )
              )
           )
  ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
           "mrp_routing_workcenter__bom_id"."id",
           "mrp_routing_workcenter"."sequence",
           "mrp_routing_workcenter"."id"
```

If we use the single term version the generated query has only one sub-query:
```sql
    SELECT "mrp_routing_workcenter".id
      FROM "mrp_routing_workcenter"
 LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
        ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
     WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
       AND (  ("mrp_routing_workcenter"."bom_id" in (
                    SELECT "mrp_bom".id
                      FROM "mrp_bom"
                     WHERE (("mrp_bom"."company_id" in (1))
                        OR  ("mrp_bom"."company_id" IS NULL))
                   )
              )
           )
  ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
           "mrp_routing_workcenter__bom_id"."id",
           "mrp_routing_workcenter"."sequence",
           "mrp_routing_workcenter"."id"
```
In this version PG is able to produce a better query plan resulting in better execution times.

Also, the `company_id` field is required on some models, so the "= False" comparison is useless.

Forward-Port-Of: odoo/enterprise#59406
Forward-Port-Of: odoo/enterprise#58756

### Context

In Colombia, a withholding tax is applied to the VAT, calculated as a percentage of the VAT amount. A typical scenario involves a VAT at 19% and a withholding tax at 15% of the VAT's 19%. The existing system constraints prevent directly using the value of one tax as the base for another, leading to a workaround by setting it to -2.85 (representing 15% of 19%).

### Problem

The electronic invoice requirements mandate the submission of base amounts and taxed values for each tax and invoice line. Due to our system's limitation in directly calculating the base for the withholding tax, our approach has been to reverse calculate the base using the tax amount divided by its rate. This method introduces inaccuracies because the tax amount is rounded, and those inaccuracies can in turn result in the electronic document being rejected.

### Solution

There's currently no way to properly fix this, so we have to rely on some dodgy programming. This commit changes the calculation method to focus on directly determining and computing the VAT amount subject to withholding. 


opw-3744872

Forward-Port-Of: odoo/enterprise#59221
Forward-Port-Of: odoo/enterprise#58377

Since revision 81b5ef93a773b94a4e3770632469c692b0ff57fa, adding by default the filter `sale_order_id`
which does:
```xml
<field name="sale_order_id" string="Sale Order"
    filter_domain="['|', ('sale_order_id', 'ilike', self), ('sale_line_id', 'ilike', self)]"
/>
```

becomes useless, because the final domain, with that `[('id', 'in', self.tasks_ids.ids)]` becomes:
```py
[
	"&",
	"&",
	"&",
	[
		"project_id",
		"!=",
		false
	],
	[
		"display_in_project",
		"=",
		true
	],
	[
		"id",
		"in",
		[
			3341211,
			3526685,
			3692221
		]
	],
	"|",
	[
		"sale_order_id",
		"ilike",
		"SO2023/123456"
	],
	[
		"sale_line_id",
		"ilike",
		"SO2023/123456"
	]
]
```

which makes an "AND" connection between the task ids domain leaf and the sale order name ilike leaves, and all these task ids will come from these SO names, making the AND useless.

In addition to be useless, it downgrades the performance. On Odoo.com,
- with the filter `sale_order_id`: 15473 ms
- without the filter `sale_order_id`: 39ms

On the below screenshot: 
![image](https://github.com/odoo/odoo/assets/5822488/3f19da7a-aafb-43a7-a092-c242a3fd7318)
The first request is with the filter `sale_order_id`
The second request is without the filter `sale_order_id`


opw-3752003

Forward-Port-Of: odoo/odoo#159115
Forward-Port-Of: odoo/odoo#158898

This commit adapts `base_import`'s background that was too dark compared to other modules. This was caused by the use of a `bg-white` class that is not very "dark-mode friendly" as it will display as a pure black, which is not visually appealing and not wanted.

This commit also adapts the background color of the sidebar to make it more consistent with other modules.

We also add a `bg-view` class to the table, so it stands out more in light mode and stays the same in dark mode.

task-3814508

| Before | After |
|--------|--------|
| <img width="1728" alt="Screenshot 2024-03-22 at 08 32 26" src="https://github.com/odoo/odoo/assets/110090660/85c0d0bf-19af-4a19-aa1b-cf990a6147d8"> | <img width="1728" alt="Screenshot 2024-03-22 at 08 34 08" src="https://github.com/odoo/odoo/assets/110090660/dfe7198a-c011-4ead-bf6f-cfba50db93a9"> |
| <img width="1726" alt="Screenshot 2024-03-22 at 08 32 42" src="https://github.com/odoo/odoo/assets/110090660/ed5914c2-bf1c-44ee-baa6-58fb5f537d9a"> | <img width="1725" alt="Screenshot 2024-03-22 at 08 34 19" src="https://github.com/odoo/odoo/assets/110090660/fb80a723-d1d0-4d44-aded-d603385cce70"> |
| <img width="1714" alt="Screenshot 2024-03-22 at 08 59 52" src="https://github.com/odoo/odoo/assets/110090660/98c543a0-05dd-4b71-b5bf-9d702f513fb4"> | <img width="1715" alt="Screenshot 2024-03-22 at 08 57 41" src="https://github.com/odoo/odoo/assets/110090660/4005b050-4a2a-4137-b6c0-47ecbdbe89a7"> | 
| <img width="1726" alt="Screenshot 2024-03-22 at 08 33 08" src="https://github.com/odoo/odoo/assets/110090660/fde063f8-48f5-4ae2-a5c1-b1973d94f0b3"> | <img width="1728" alt="Screenshot 2024-03-22 at 08 33 59" src="https://github.com/odoo/odoo/assets/110090660/b5875104-7d6f-4a36-8303-0cf7c14c113d"> | 
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#158822
Forward-Port-Of: odoo/odoo#158019

Steps to reproduce:
- Install **planning** app.
- Go to **planning** app, and convert the view to **List**.
- Group by **Resource** -for example-.
- Notice how the Allocated Time column values are mis-aligned with the header label.

Investigation:
- in the planning tree view, notice the property `open_form_view` set to `True` https://github.com/odoo/enterprise/blob/418ea2114c7d935865dc52e5fd5a30d626987190/planning/views/planning_views.xml#L8
- In the `getGroupNameCellColSpan` method:
	- the `firstAggregateIndex` is `1` belonging to the `allocated_hours` (Allocated Time)column which set the `colspan = firstAggregateIndex = 1`
	- as `this.hasSelectors` is `true`, `colspan = colspan+1 = 2` (which is the correct value)
	- but now as the `open_form_view` was set to `True`, the `this.props.onOpenFormView` exists and so the `colspan = colspan+1 = 3` which makes the value be misaligned to the right by one column.

The proposed fix:
- As the `open_form_view` option add a View button to the end of the row, it makes sense to do the check with the `lastAggregateIndex` inside `getGroupPagerCellColspan` method.
- In our case:
	- the `lastAggregateIndex` is `1` belonging also to the `allocated_hours` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 1 - 1 = 1`
	- as we don't display optional fields this check fails https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = 1`
	- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 2` which is correct.
- But what if we wanted to show the optional field `allocated_percentage` would this fix still work? Yes!
	- the `lastAggregateIndex` is `2` belonging to the `allocated_percentage` which set the `colspan = this.state.columns.length - lastAggregateIndex - 1 = 3 - 2 - 1 = 0`
	- as we do display an optional fields= this check works https://github.com/odoo/odoo/blob/5af3cfc2b9ce648ae4aff69150266e4ad519050d/addons/web/static/src/views/list/list_renderer.js#L1025-L1027 and the `colspan = colspan+1 = 2`
	- Now we check the `this.props.onOpenFormView` condition which set `colspan = colspan+1 = 3` which is correct.
- One last case, what if we have no aggregates
	- both firstAggregateIndex` = `lastAggregateIndex` = -1
	- we go into the else clause inside `getGroupPagerCellColspan`, making the `colspan = this.state.columns.length > 1 ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = True ? DEFAULT_GROUP_PAGER_COLSPAN : 0 = DEFAULT_GROUP_PAGER_COLSPAN = 1`
	- if the `open_form_view` was `True`, the colspan becomes `colspan = colspan+1 = 2`.

opw-3764616

Forward-Port-Of: odoo/odoo#156647

Steps to reproduce:
-
- Create a request for quotation for a product with set vendor Taxes
- Create an alternative purchase order from that RFQ with Copy Product

Current Behavior:
-
The purchase order line of the PO associated with the created alternative does not compute the taxes.

Expected behavior:
-
The taxes should be computed in the same way as if the PO was created manually and then linked to the alternatives.

Cause of the issue:
-
When creating a PO manually, the taxes of each purchase order line are computed when the product is set during the call of the `onchange_product_id` onchange method:
https://github.com/odoo/odoo/blob/64c13193ae0fe23eb1b426f5bbcd8531e9a40967/addons/purchase/models/purchase.py#L1221 https://github.com/odoo/odoo/blob/7ed0a773b6e0711b127f236ce665c35202d973bc/addons/purchase/models/purchase.py#L1055-L1061 By contrast, PO created from the `action_create_alternative` generate each `purchase.order.line` using `Command.create`. Therefore these lines will not trigger the onchange method and their taxes will not be computed.

Fix:
-
To KISS, we compute the taxes of each line just after the creation of the record using the `_compute_tax_id` method.

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

Forward-Port-Of: odoo/odoo#155060

Steps to reproduce:
-------------------
- install calendar, project and documents;
- create an activity for a task (project.task) with meeting type;
- change attendee to the meeting;
- save;

Issue:
------
The activity is not linked to the right task.

Cause:
------
When we create a `calendar.event`, when the event is at a future date, we send an email to the attendees.
This email must include an attachment corresponding to the ICS file. Depending on the `no_document` context key, we may or may not create a document.

When we create the document, we have a value for the `activity_ids` field (one2many) which is the ORM command for linking the newly created document.

This will result in the document id being written to the `res_id` field of the `mail.activity` record.
Unfortunately, the activity contains a `res_model` which is not `documents.document`. The result is that the activity is linked to a `res_id` which is not that of the model previously set for it (i.e. `project.task`).

Solution:
---------
Add context key `no_document` when creating an attachment for ICS files.

opw-3746857

Forward-Port-Of: odoo/odoo#155873

When the user creates a new ribbon without a background color,
a traceback will appear.

Steps to reproduce the error:
- Install "website_sale"
- Go to Website > eCommerce > Products
- Pick a product > Sales > Create a new ribbon without a background color
- Save & Close

Traceback:
```
TypeError: argument of type 'bool' is not iterable
  File "odoo/http.py", line 2251, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1826, in _serve_db
    return self._transactioning(_serve_ir_http, readonly=ro)
  File "odoo/http.py", line 1847, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1824, in _serve_ir_http
    return self._serve_ir_http(rule, args)
  File "odoo/http.py", line 1832, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2057, in dispatch
    result = self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 222, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 740, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/web/controllers/dataset.py", line 34, in call_kw
    return self._call_kw(model, method, args, kwargs)
  File "addons/web/controllers/dataset.py", line 30, in _call_kw
    return call_kw(request.env[model], method, args, kwargs)
  File "odoo/api.py", line 458, in call_kw
    result = getattr(recs, name)(*args, **kwargs)
  File "addons/web/models/models.py", line 74, in web_save
    self = self.create(vals)
  File "<decorator-gen-471>", line 2, in create
  File "odoo/api.py", line 420, in _model_create_multi
    return create(self, [arg])
  File "addons/website_sale/models/product_ribbon.py", line 24, in create
    if 'bg_color' in vals and not '!important' in vals['bg_color']:
```

https://github.com/odoo/odoo/blob/806a60d9766e4e04f461a0fb7c824cf5f5c7d5ae/addons/website_sale/models/product_ribbon.py#L24 Here, when the user creates a new ribbon without a background color,
"bg_color" will be False, so when it tries to check "vals['bg_color']".
It will lead to the above traceback.

sentry-5077714703

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

Forward-Port-Of: odoo/odoo#158561

### Move common scss into web
Prior to this PR, some of the main styles related to event elements in calendars were set in the `calendar` module.
This created layout issues when we installed independent modules without installing `calendar` (eg. `planning` or `hr_payroll`).

To fix that, this PR moves the necessary styles into `web` and manages duplicated styles in order to remove them.

### Adjust hatched events for planning
Prior to this commit, the "hatched" event style in Planning wasn't displayed in Day and Week views.
This commit adjusts the css selector to fix this issue.

---
task-3617329
Part of task-3575827

---
| Before | After |
|--------|--------|
| ![Capture d’écran 2024-02-22 à 08 30 37](https://github.com/odoo/odoo/assets/80679690/a6a33398-522e-471c-ab75-884f72c214cc) | ![Capture d’écran 2024-02-22 à 08 43 32](https://github.com/odoo/odoo/assets/80679690/e6c07aac-8273-4772-a759-64c03ee125e5) |
| ![Capture d’écran 2024-02-22 à 08 31 10](https://github.com/odoo/odoo/assets/80679690/0ac54c01-a39b-45dd-afeb-5bcc29c912ae) | ![Capture d’écran 2024-02-22 à 08 44 50](https://github.com/odoo/odoo/assets/80679690/d0a69d3f-e68f-4c7f-97d1-e33c14c6f8bd) | 

| Before | After |
|--------|--------|
| ![Capture d’écran 2024-03-25 à 11 00 46](https://github.com/odoo/odoo/assets/80679690/d866eadf-5c04-451c-a98e-4af7789f6d08) | ![Capture d’écran 2024-03-25 à 11 01 06](https://github.com/odoo/odoo/assets/80679690/216ddadb-8e02-4522-a7dc-cf3f6f71069e) |


---

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

Forward-Port-Of: odoo/odoo#154964

When we use the `|` (or) version of this rule the ORM generates two sub-queries when checking the company. This causes sub-optimal and in some cases really bad planning for the queries and thus PG takes hours to complete them.

Example (formatted):
```sql
    SELECT "mrp_routing_workcenter".id
      FROM "mrp_routing_workcenter"
 LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
        ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
     WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
       AND (  ("mrp_routing_workcenter"."bom_id" in (
                    SELECT "mrp_bom".id
                      FROM "mrp_bom"
                     WHERE ("mrp_bom"."company_id" in (1))
                   )
              )
           OR ("mrp_routing_workcenter"."bom_id" in (
                    SELECT "mrp_bom".id
                      FROM "mrp_bom"
                     WHERE "mrp_bom"."company_id" IS NULL
                   )
              )
           )
  ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
           "mrp_routing_workcenter__bom_id"."id",
           "mrp_routing_workcenter"."sequence",
           "mrp_routing_workcenter"."id"
```

If we use the single term version the generated query has only one sub-query:
```sql
    SELECT "mrp_routing_workcenter".id
      FROM "mrp_routing_workcenter"
 LEFT JOIN "mrp_bom" AS "mrp_routing_workcenter__bom_id"
        ON "mrp_routing_workcenter"."bom_id" = "mrp_routing_workcenter__bom_id"."id"
     WHERE "mrp_routing_workcenter"."workcenter_id" in (1)
       AND (  ("mrp_routing_workcenter"."bom_id" in (
                    SELECT "mrp_bom".id
                      FROM "mrp_bom"
                     WHERE (("mrp_bom"."company_id" in (1))
                        OR  ("mrp_bom"."company_id" IS NULL))
                   )
              )
           )
  ORDER BY "mrp_routing_workcenter__bom_id"."sequence",
           "mrp_routing_workcenter__bom_id"."id",
           "mrp_routing_workcenter"."sequence",
           "mrp_routing_workcenter"."id"
```
In this version PG is able to produce a better query plan resulting in better execution times.

Also, the `company_id` field is required on some models, so the "= False" comparison is useless.

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#159210
Forward-Port-Of: odoo/odoo#157861

This commit "fixes" a weird behavior in Firefox where a MouseEvent ("mouseenter" in this case) can be triggered from the target's TEXT_NODE, even if it shouldn't...

Note: even though this isn't clearly defined in the spec, MouseEvent shouldn't be dispatched for TEXT_NODE, as implemented in Blink or WebKit... But not everyone agrees (cf. tickets linked below).

Steps to reproduce:
- open website
- go into edit mode
- actually edit the page
- add a snippet to the page
- click on the "Discard" button and move very fast out of it => the error `el.matches is not a function` is "sometimes" raised (if you got the right timing)

References:
- https://w3c.github.io/uievents/#event-type-mouseenter
- https://bugzilla.mozilla.org/show_bug.cgi?id=185889
- https://bugzilla.mozilla.org/show_bug.cgi?id=42717
- https://bugzilla.mozilla.org/show_bug.cgi?id=103055



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

Forward-Port-Of: odoo/odoo#158810