The goal of this PR is to replace the "Toggle underline" option [1]
from the website's text editor by a new "Highlight effects" option which
should allow applying some highlights on the selected text and setting
their color & thickness.

For this purpose, the JS code used for text animations will be updated
to be more generic and handle text highlights too. Moreover, The "Text
Highlight" options will be applied by adding a SVG to the targeted text
element (allowing to adjust their `stroke` and `stroke-width`).

To simplify adapting highlights when the text content is updated,
we follow this generic structure:
```XML
<span class="o_text_highlight">
    <span class="o_text_highlight_item">
        line1-textNode1 [line1-textNode2,...]
        <svg.../>
    </span>
    [<br/>]
    <span class="o_text_highlight_item">
        line2-textNode1 [line2-textNode2,...]
        <svg.../>
    </span>
    ...
</span>
```

Rendered line breaks in text nodes are detected using range client
rectangles (see: `text_processing.js` > `splitNodeLines()`), and the
highlights are updated on window resize...

We also need to adjust highlight SVGs to fit an updated text in "edit
mode" (mainly using editor's commands), a `MutationObserver` is used
for this purpose (we only redraw the SVG for each text unit).

A simple SVG path generator was implemented in this PR (see:
`text_processing.js` > `drawPath()`) to build highlights. It applies a
list of SVG path commands according to text dimensions in a specific
mode (E.g. on "pattern" mode, we repeat the same elementary path to fit
targeted text node...).

Remarks:

- The `--text-highlight-width` and `--text-highlight-color` properties
are used to control the highlight effect's thickness and color.

- We build the highlight option preview in the same way as text content.
To achieve this, a hack was used (we open the `<we-select/>` first since
we need the right `getBoundingClientRect()` dimensions to correctly draw
highlight SVGs).

[1]: Also, the text editor "Toggle strikethrough" option will be moved
to the list of highlight effects in the new option.

task-3285817 (rd-website)
task-3269759 (rd-design)

Co-authored-by: Chrysanthe(CHGO) chgo@odoo.com

This PR redesigns all headers and improves and adapts some related features.

**New Header redesigns:** 
All previous header designs have been removed in favor of the new redesigned set of headers.

**New Elements feature:**
This new feature allows the user to select the elements he wants to display in the header (e.g. social links, call to action, ...)

**Mobile menu feature:**
Since we decided to keep the mobile version with an "off canvas" layout, the Mobile Menu feature has been removed.

**Alignment feature:**
This feature has been adapted to match the new headers.

**Mobile Alignment Feature:** 
Since the mobile header layout is always "off canvas", this feature allows the user to choose the menu alignment for the mobile version.

Requires: 
- https://github.com/odoo/design-themes/pull/651
- https://github.com/odoo/upgrade/pull/5214

task-3060986
task-3474743

Co-authored-by: Brieuc-brd [brd@odoo.com](mailto:brd@odoo.com)
Co-authored-by: robinlej [role@odoo.com](mailto:role@odoo.com)

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

When using the media dialog, the dialog always seems glitchy as its size
is always changing with the loading files. This behavior is not really
convenient as it can make the user click on unwanted images. Another
"issue" of the current media dialog is that when loading more images,
the dialog auto-scrolls to the "Load More" button, which can make the
user miss new images and he therefore needs to revert the scroll. A last
issue encountered by the users is that some of them think that the "Add"
button in the footer is used to upload files from their device, while it
only adds the selected media to the page.

This commit improves the UX of the media dialog:
- The dialog height is now fixed and has the same size as when it is
fully filled by images.
- The top bar with the search input now stays at the top when scrolling.
- There is now a small footer under the attachments (for the Images and
Documents tabs only) and containing the following:
    - When there is content to scroll, a small circle with an arrow that
scrolls one row when clicking on it.
    - When there is nothing to scroll, the "Load More" button which will
load more images. When new images are loaded, if we can scroll, the
small arrow is displayed again.
    - When there is nothing to scroll and to load anymore, the "All
images/documents have been loaded" text.

Note that the main goal of this footer is simply to indicate to the user
when there is still content to scroll and when he can load more files.

In order to solve the "Add" button issue, this commit also enables and
disables this button, depending on whether some media are selected:
- if a media is already selected, we can click on the button;
- if not, the button is greyed out and we cannot click on it.

task-3441587

Purpose
=======

Make it possible to compare analytic values between plans by inputting
up to one account per plan on each line.
For instance, if we have 2 plans: "Country" and "Product Type", with the
following accounts

| Country | Product Type |
| ------- | ------------ |
| BE      | Drinks       |
| LU      | Food         |

And the following invoices:
* 1000€ of drinks in Belgium
* 2000€ of food in Belgium
* 3000€ of food in Luxemburg

We want to be able to display the following pivot tables:

|     | Drinks | Food | Total |
| --- | ------ | ---- | ----- |
| BE  |   1000 | 2000 |  3000 |
| LU  |      0 | 3000 |  3000 |
| Tot |   1000 | 5000 |  6000 |

|        | Total |
| ------ | ----- |
| Food   |  5000 |
| * BE   |  2000 |
| * LU   |  3000 |
| Drinks |  1000 |
| * BE   |  1000 |
| Total  |  6000 |

Implementation
==============

* Each analytic plan corresponds to one field on `account.analytic.line`
* The fields are added dynamically in the views.
* `account.analytic.plan` doesn't have a `company_id` field anymore,
  meaning that all the companies have access to all the plans. This
  means that the applicability fields and lines are now company
  dependent, and those can be used to know which fields/plans to display
  for which company.
* There can no longer be one "Project" plan per company, even if the
  accounts of that project can still be owned by only one company.
* There is now only one method to get the default (or "Project" plan),
  which is `_get_plan_columns`

task-3497653

# Invoice states
Structure `peppol_move_state` according to the following logic:
1. Ready to Send / Invoices confirmed addressed to partners that are Peppol valid and not in one of the other statuses. Default behavior upon posting such an invoice.
2. Queued / In case of asynchronous sending only, the instruction to send has been given via the Send & Print but the cron wasn't run yet. It is still possible to cancel the sending.
3. Pending Reception / Too late to cancel, synchronous or asynchronous sending makes it now impossible to cancel the sending
4. Canceled / Once asked explicitly by the user. It's instant.
5. Done     / Upon confirmation or delivery received from the AP
6. Error / Upon confirmation of a notification of error received from the AP

# Journal Dashboard
Add an action on sale journals to open invoices that are ready to be sent via Peppol

# Other improvements
- Peppol ready filter in Customer Invoices view
- Rename `PEPPOL state` to `Peppol status` for consistency
- Pre-fill valid phone numbers in `account_peppol_phone_number` field
- Fix async sending in demo mode



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

before this commit:
===================
you can not create xml record for product.template and product.product and link them for same product if you like to achieve it you need to do it like

```
<record id="product_template_1" model="product.template">
    <field name="name">Box</field>
    .
    .
    .
    <field name="list_price">8000.0</field>
</record>
<record id="product_template_attribute_line_1" model="product.template.attribute.line">
    <field name="product_tmpl_id" ref="product_template_1"/>
    <field name="attribute_id" ref="product_attribute_color"/>
    <field name="value_ids" eval="[(6, 0, [ref('product.product_attribute_value_1'), ref('product.product_attribute_value_2')])]"/>
</record>

<function model="ir.model.data" name="_update_xmlids">
    <value model="base" eval="[{
        'xml_id': 'product.product_template_attribute_value_1',
        'record': obj().env.ref('product.product_template_attribute_line_1').product_template_value_ids[0],
        'noupdate': True,
    }, {
        'xml_id': 'product.product_template_attribute_value_2',
        'record': obj().env.ref('product.product_template_attribute_line_1').product_template_value_ids[1],
        'noupdate': True,
    },]"/>
</function>

<function model="ir.model.data" name="_update_xmlids">
    <value model="base" eval="[{
        'xml_id': 'product.product_product_red',
        'record': obj().env.ref('product.product_template_1')._get_variant_for_combination( obj().env.ref('product.product_template_attribute_value_1')),
        'noupdate': True,
    }, {
        'xml_id': 'product.product_product_4b',
        'record': obj().env.ref('product.product_template_1')._get_variant_for_combination( obj().env.ref('product.product_template_attribute_value_2')),
        'noupdate': True,
    }]"/>
</function>
```

after this commit:
==================
you can create product.tempalte and product.product from xml file and link it manully by attribute value

like
```
<record id="product_template_1" model="product.template" context="{'create_product_product': False}">
    <field name="name">Box</field>
    .
    .
    .
    <field name="list_price">8000.0</field>
</record>

<record id="product_template_attribute_line_1" model="product.template.attribute.line" context="{'create_product_product': False}">
    <field name="product_tmpl_id" ref="product_template_1"/>
    <field name="attribute_id" ref="product_attribute_color"/>
    <field name="value_ids" eval="[(6, 0, [ref('product_attribute_value_blue'), ref('product_attribute_value_red')])]"/>
</record>

<record id="product_template_attribute_value_1" model="product.template.attribute.value">
    <field name="attribute_line_id" ref="product_template_attribute_line_1"/>
    <field name="product_tmpl_id" ref="product_template_1"/>
    <field name="attribute_id" ref="product_attribute_color"/>
    <field name="product_attribute_value_id" ref="product_attribute_value_blue"/>
</record>

<record id="product_product_blue" model="product.product">
    <field name="product_tmpl_id" ref="software_reseller.product_template_1"/>
    .
    .
    .
    <field name="product_template_variant_value_ids" eval="[(6, 0, [ref('product_template_attribute_value_1')])]"/>
</record>

<record id="product_template_attribute_value_2" model="product.template.attribute.value">
    <field name="attribute_line_id" ref="product_template_attribute_line_1"/>
    <field name="product_tmpl_id" ref="product_template_1"/>
    <field name="attribute_id" ref="product_attribute_color"/>
    <field name="product_attribute_value_id" ref="product_attribute_value_red"/>
</record>

<record id="product_product_red" model="product.product">
    <field name="product_tmpl_id" ref="software_reseller.product_template_1"/>
    .
    .
    .
    <field name="product_template_variant_value_ids" eval="[(6, 0, [ref('product_template_attribute_value_2')])]"/>
</record>
```

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

Description of the issue/feature this commit addresses:

Currently, the payment registration for vendor bills is kinda hard to figure. Noticing which bills are overdue, which require a payment is not made so easy by the interface and could be improved. Also there is no way to register a payment for multiple lines at a time which could improve the UX.

---

Desired behavior after the commit is merged :

On the dashboard, all the buttons in the "Customer Invoices" and "Vendor Bills" have been renamed to remove the "Invoices" and the "Bills" inside them.

The buttons "Bills to Pay" and "Late Bills" which now are "To Pay" and "Late" (see above) redirect to the Journal Items with specific filters to show only the necessary lines.

The order of the columns in the Journal Items has been changed and their visibility has been changed too.

The default filters of the Journal Items when coming from the dashboard buttons has been changed. Payable has been replaced by Purchases.

Filters, Group by and Search by options have been added for the Due Date and the Discount Date fields in the Journal Items.

---

task-3516496

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

- Before this commit :
    - When a task has mutliple assignees and that those assignees have
    planned/requested holidays during the same period, the warning
    message repeats itself : "Mitchell Admin has requested time off
    from the 06/13/2023 to the 06/16/2023. Marc Demo has requested time
    off from the 06/13/2023 to the 06/16/2023.". This is a bit heavy to
    read and could be simplified when the holdiays planned dates are the
    same.
    - When the user uses the magnifier button in the gantt
    view of project to schedule non-scheduled tasks, only the tasks with
    planned hours are smart scheduled. The tasks without planned hours
    are simply put the same day at the same time.

- After this commit :
    - When a task has mutliple assignees and that those assignees have
    planned/requested holidays during the same period, the message will
    be : "Mitchell Admin, Marc Demo have requested time off from the
    06/13/2023 to the 06/16/2023.
    - Smart scheduling takes into account the non-planned hours tasks.
    It does so by scheduling first all the selected tasks with planned
    hours, and then schedules all the tasks without planned hours by
    putting fictive planned hours for these tasks that depend on the
    scale of the gantt view. The confimation wizard that appeared when
    the scheduled tasks were outside of the gantt view scale has been
    removed and replaced by a toast notification.

    ####### Precisons ######
    - The smart scheduling now works even when selecting multiple tasks
    (batching) EVEN if they belong to different projects. The tasks
    are scheduled one projects after another, prioritizing the tasks
    with allocated or remaining hours. For example, if we have project A
     with task AA (allocated_hours = 2h) and task AB (allocated_hours
     = 0h) and we have project B with task BA (allocated_hours = 3h) and
      task BB (allocated hours = 0h), then the scheduling priority order
      will be AA => BA => AB => BB.
    - The precision in "week" and "month" scale is the one defined by
    default (half-day) or the one selected in the studio.
    - The precision in "day" scale is always a half-day
    - The precision in "year" scale is always one month
    - The scheduling of non-allocated hours tasks should follow the
    following behaviour :
        - A half day is always concening the working hours between
        00:00:00 AM and 12:00:00 AM OR 12:00:00 AM and 12:00:00 PM.
        The working hours inside those intervals don't matter for the
        scheduling of non-allocated hours tasks. The task is also
        planned only when the working hours in the half-day are fully
        available. For example, if we are in "week" scale and the
        precision is "half-day" then the task will be planned at the
        first half day fully available (without conflicts with other
        tasks).
        - Another example in "year" scale : we trigger the smart
        scheduling for a non-allocated hours task A in march. There is
        another task B already planned until the 10th of march. Task A
        will then be planned at the next full free interval => April.

task-3330290

# Purpose

Currently, the templates of Knowledge only contain static HTML with text, images, tables, lists, etc. Now, we would like to include templates featuring databases and article links. It will then be possible to showcase more advanced features of Knowledge.

Unfortunately, these elements refer to an article and require an article id to work properly. For the article links, for instance, we need to provide the id of the articles we want to open. When applying a template, the system will generate new articles with new ids. To ensure that the links will redirect the user to the right article, we have to update the ids stored in the document and provide the ids of the newly generated articles.

As the templates are static and the ids are dynamic, we cannot properly integrate those elements in a template. This commit aims to eliminate that limitation by providing a magic `ref` function that people can use in their templates to refer to an external record. People will then be able to easily integrate databases and article links in their templates.

This commit will also introduce new templates containing databases and article links. People can then use those templates to try out the more advanced features of Knowledge and understand the power of Knowledge with real world examples.

## Technical aspects

To streamline our code base, we will merge the model `knowledge.article` with `knowledge.article.template`. That way, the articles and the templates will always be consistent. By merging the two models, we will not have to duplicate the logic and the views for the template preview. It will also not be necessary to: transform the favorites set on the embedded views, update the default values set in the context, etc. when turning a template into an article.

During the development, we considered different approaches to tackle the existing limitations of the static templates:

1. We considered making the ids optional by introducing fallback mechanisms. The idea was to use the id of the active record when no id was provided. This would have allowed the integration of embedded view of article items without providing any id. However, the approach was very limited: it was not possible to list the article items of another article or insert an article link.
2. We considered patching the generated template with `lxml` to update the ids stored in the document. The solution didn't work very well: In some cases, it was not possible to know if the ids should be transformed or not as the ids could refer to another model.
3. We considered turning the static templates into dynamic templates using `QWeb`. The solution was checking all the boxes but we preferred not to allow non-admin users creating templates and using `QWeb` because the rendering engine relies on the `safe_eval` function which can potentially have undiscovered security flaws. To not take any risk, we prefer not to use that approach.

For all these reasons, we prefer including a magic `ref` function in the templates and post-process the template to replace the `ref` function call with the appropriate id. With that approach, people can explicitly tell which id should be dynamically transformed.

task-3334717

Currently, the templates of Knowledge will only contain static HTML with text, images, tables, lists, etc. Now, we would like to include more advanced templates containing article links, index structures, kanban/list views of article items, etc. Unfortunately, there are a few limitations with static templates that prevent us from integrating those blocks:

1. To load a kanban or a list view of article items, we need to encode the id of the parent article in the body of the template. As the ids we need to provide are dynamics, we can not hardcode them directly in the body of the article.
2. For the embedded views of article items, we may define custom favorites that will also be encoded in the body of the article. When applying a template to an article, we will have to adapt those favorites to make them compatible with the new model.
3. To create links between articles, we will also need the encode the id of the target article in the body of the template. There can also be cyclical dependencies between articles which makes the creation of those articles difficult.

## Solution

This PR will turn the static templates of Knowledge into dynamic templates using QWeb.

The templates will now have a rendering context allowing people to define variables. The system will also expose functions that people can use to automatically convert id and fields based on the context being used.

task-3334717

Currently, the templates of Knowledge will only contain static html with text, images, tables, lists, etc. Now, we would like to integrate blocks that depend on a record. More specifically, we would like to include pre-configured templates containing a kanban or a list view of article items.

To embed a kanban or list view of article items, we need to have a reference to an article (i.e: an id). The embedded view will then display all article items of that article. The issue is that, most of the time, the id we need to provide is the id of the article itself and that article may not exist yet. The other issue is that the article items we show in the preview of the templates may also not exist. Those articles will only be created when the user applies the template. To solve these issues, we need to find a way to make the templates dynamic.

# Solution

1. Create a custom "behavior" for the article items. We will then be able to customize those blocks without introducing specific code in the generic component.
2. Make the article id of the embedded views optional: In the custom behavior we created, we will assign the `active_id` to the active record. We will then be able to specify a kanban or a list view in the data files.
3. Customize the HTML field of the template gallery and load variants of the behaviors: We will then be able to customize the display of each block for the preview. For the kanban and list view of article items, we will load the record of `knowledge.article.template` instead of `knowledge.article`.

task-3334717