Knowledge is a wonderful tool for collecting, organising and sharing
documents with colleagues. However, Knowledge lacks an effective search
feature allowing people to search within the content of their documents.

The existing search feature only searches for documents with a specific
title. If the users don't know which document contains the information
they need, they can waste time reading a bunch of articles before finding
what they want. This can be time consuming and frustrating when there
are a lot of documents in the knowledge base and when the articles are
not well organised.

To help people to quickly find the information they need in the knowledge
base, we will improves the command palette search algorithm. The search
algorithm will now be able to find documents containing the search terms
inputted by the user.

Technical
---

The new search algorithm uses the PostgreSQL's built-in full-text search
feature. This feature will do all the heavy lifting for us: It will be able
to strip the html tags from a document, quickly find article matching with
the given search terms, highlight the matching terms in the document, etc.

To index the documents, we will define a custom text configuration that
is independent of the user's language: It will not discard any words and
will not apply any stemming methods to the documents and the search query.
It will also ignore the HTML tags stored in the article body.

To reduce the query runtime, the search algorithm limits the number of
candidates to consider (see: the "cut_off" parameter) and pre-selects
relevant candidates incrementally:

The algorithm first selects articles matching with the title and the body
of the article. If there are not enough matches, the algorithm will select
articles matching with the title only. If there are still not enough matches,
the algorithm will select the articles matching with the body only.

After that, the algorithm ranks the selected articles using a scoring
function and returns the most relevant ones. This should ensure that the
results we get are relevant and that the query response time is acceptable.

Benchmark
---

To evaluate the efficiency of the new search algorithm, we loaded in
Knowledge 100, 1000 and 10 000 articles coming from an online
encyclopaedia using a populate script. The script will nest these
articles under one another to form a tree with a branching factor of 5.
The articles will be written in English and will be placed in the
workspace of Knowledge.

We then randomly selected 100 different words from the loaded articles
and we searched them using the new search algorithm. We then measure the
query response time and we calculate the average, the standard deviation,
the minimum and the maximum response time.

Response time:

- Admin user:

|     N |       AVG | Std Dev |  Minimum |   Maximum |
|-------|-----------|---------|----------|-----------|
|   100 |  188.92ms |   172.5 |   18.4ms |  540.31ms |
|  1000 |  406.56ms |  316.31 |  28.54ms | 1236.47ms |
| 10000 | 1467.31ms |  901.12 | 138.56ms | 3670.40ms |

- Demo user:

|     N |       AVG | Std Dev |  Minimum |   Maximum |
|-------|-----------|---------|----------|-----------|
|   100 |     184ms |  165.41 |  25.86ms |  571.79ms |
|  1000 |  457.69ms |  275.76 |  76.02ms | 1456.63ms |
| 10000 | 1504.90ms |  662.64 | 600.57ms | 3199.80ms |

**Observation**: The response time can vary greatly depending on the
number of times the search terms appear in the documents. The more
often the search term is used, the more results there will be and the
slower the query will be.

- The minimal response time observed is when the search term appears in
the body of a single article.
- The maximal response time observed is when the search term appears in
the body of many article but does not appear frequently in the titles.

Index disk usage:

|     N |                    Index name |   Size |
|-------|-------------------------------|--------|
|   100 | knowledge_article__name_index |  229kB |
|   100 | knowledge_article__body_index | 2318kB |
|  1000 | knowledge_article__name_index | 1458kB |
|  1000 | knowledge_article__body_index | 8536kB |
| 10000 | knowledge_article__name_index | 5447kB |
| 10000 | knowledge_article__body_index |   32MB |

Column disk usage:

|     N | Column name |   Size |
|-------|-------------|--------|
| 100   |        body |  855kB |
| 1000  |        body | 6799kB |
| 10000 |        body |   71MB |

Legend:

- N: Number of articles stored in the database

Reference:

PostgreSQL documentation: https://www.postgresql.org/docs/15/textsearch.html

task-3071299

The goal of this task is to improve onboarding experience of new users. The idea
is that when a user start an odoo instance without demo and installed the
point_of_sale module, the user is welcomed with options to create configuration
and data sets from different predefined scenarios, namely Furnitures, Bakery,
Clothing, Bar and Restaurant. The original sets of demo data are now categorized
in the Furnitures and Restaurant scenarios and the other scenarios are added
with new data sets.

As for the installation of pos modules in demo mode, we automatically load the
scenarios, so now, there will be 5 configurations when both point_of_sale and
pos_restaurant are installed.

The demo products (and related records) are put in .xml files. These files are
loaded using `convert` module on demand -- based on what scenario the user
selected. This is the reason we have exposed few methods that will be called
from the backend interface. When in demo mode, we pretend that all scenarios are
selected and we call the action that loads the scenarios.

Small fixes and improvements are also included in this commit:

- Fix styles and layouts in the components related to opening and closing dialogs.
- Resize of selection pills during product configuration.
- Reduce the size of the anchor to resize tables in the floor screen during edit mode.
- Remove CancelConfirmationDialog as it doesn't serve so much purpose. We just
  use the normal confirmation dialog when asking users about the closing amount
  difference.

TASK-ID: 3598952

Linked PR: https://github.com/odoo/odoo/pull/154995

The main goal of this task is to allow the user to work on a chosen time range via two date pickers. This will ease the edition of records by making possible to move, resize, create, edit records on time periods that are not arbitrarily fixed to a given day, week, month, or year. Two new scales are also available: week_2 and month_3. The principal effect of scales is now to determine the duration of the gantt columns ("hour", "day", "month") and their widths. The scale can be chosen via a slider.

We also have added some new buttons:
- two buttons for sorting the rows by the time their first pill occur  (i.e. groups can be sorted by date_start:min asc or desc)
- a button to change the display mode ("dense"/"sparse") introduced in https://github.com/odoo/enterprise/pull/58338

Note that for performance reason, we do not allow time range bigger than 10 years. We also forbid to load more than 1000 records. In case that limit is reached a notification is displayed. This has been done in order to keep the number of rows/columns in the css grid within the bounds allowed by Firefox (https://bugzilla.mozilla.org/show_bug.cgi?id=1336679). Note that we do not render all loaded records. The gantt view is now also virtualized in the horizontal direction and we only add to the css grid the rows/columns  effectively needed to display the visible elements.

In mobile mode, the date selection is done in a dialog instead of a popover. We plan to extend that behavior everywhere.

Task ID: `3601456`

Co-authored-by: Bruno Boi <boi@odoo.com>
Co-authored-by: Julien Carion <juca@odoo.com>
Co-authored-by: Mathieu Duckerts-Antoine <dam@odoo.com>
Co-authored-by: Romeo Fragomeli <rfr@odoo.com>
Co-authored-by: Pierre Pulinckx <pipu@odoo.com>
Co-authored-by: Luca Vitali <luvi@odoo.com>

https://github.com/odoo/odoo/pull/162017