For some reason, “New” has been translated as “Nieuw” in Bulgarian, but
this is not Bulgarian, this is Dutch.

This commit replaces all occurrences of “Nieuw” with “Нов”, which is the
correct translation for “New” in Bulgarian.

closes odoo/odoo#133621

X-original-commit: 73512e95
Related: odoo/enterprise#46568
Signed-off-by: Louis Wicket (wil) <wil@odoo.com>

Steps to reproduce the bug.

- In website edit mode, add a form snippet to a page.
- Add a "number" field within this form.
- Modify the label of this field in the options and name it "Field 1".
- Add a "text" field to the form.
- In the options of the "Text" field, select "Visible only if" for the
"visibility" option.
- Then, choose "Field 1" and "Is greater than" in the two dropdowns that
follow.
- Enter "10" in the input below.
- Save the page.
- Enter "2" in the "Field 1" input.
- Bug: The text field is displayed, even though it should only be
visible if "Field 1" is greater than 10.

This bug exists since the "conditionally show form fields" feature was
added to Website (in this commit [1]). The bug happened because we were
comparing strings instead of numbers.

[1]: https://github.com/odoo/odoo/commit/2dcbfecf3c10687a2cd3af36335d5be70c904fce



opw-3449900

closes odoo/odoo#133579

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

This reverts [this commit]. Indeed, [this commit] was too restrictive on
the visibility dependencies and blocked the creation of some conditions.

Example:
- Add a form on the website.
- Add two fields and rename them (by "test" for example).
- Change the visibility of the first one and set it to "Visible only if
Your Name is equal to Boule"
- Change the visibility of the second one and set it to "Visible only if
Your Name is equal to Bill"

-> The field "test" will be visible if "Your name" is "Boule" or "Bill".

[this commit]: https://github.com/odoo/odoo/commit/acb4a2764ca31a856d452e788afe4cb99d7d54af



closes odoo/odoo#133011

Signed-off-by: Arthur Detroux (ard) <ard@odoo.com>

When posting again an account move related to an expense, the sheet's
state and the expense's state won't be updated

To reproduce the issue:
1. Create an expense
   - Paid By: Company
2. Create the related report
3. Submit to manager, Approve, Post Journal Entries
4. Open the related journal entry
5. Reset & Post

Error: States of both expense and sheet are incorrect (sheet:
"Posted" instead of "Done", expense: "Approved" instead of "Paid")

The state of the expense depends on the one of the sheet:
https://github.com/odoo/odoo/blob/1c517b6e67127971f343ffac0a4c29d684c8c13e/addons/hr_expense/models/hr_expense.py#L141-L153

The state of the sheet is manually written, each time the user does
an action. For instance, when posting the journal entries from the
sheet, we update the state of the sheet (which will change the state
of the expense, as shown in the above `compute`)
https://github.com/odoo/odoo/blob/1c517b6e67127971f343ffac0a4c29d684c8c13e/addons/hr_expense/models/hr_expense.py#L642-L643
https://github.com/odoo/odoo/blob/1c517b6e67127971f343ffac0a4c29d684c8c13e/addons/hr_expense/models/hr_expense.py#L1164-L1165

Same thing will happen when resetting the AM to draft:
https://github.com/odoo/odoo/blob/f6a13938f904f275b0360507b7ec987ef3bc2ddc/addons/hr_expense/models/account_move.py#L16-L20



But here is the issue: nothing updates the expense/sheet states when
posting again the AM

OPW-3322836

closes odoo/odoo#131060

Signed-off-by: Josse Colpaert <jco@odoo.com>

Description of the issue/feature this PR addresses:
In project module, if milestone name is long then name is overflowing.

Current behavior before PR:
milestone name is overflowing when name is too long.

Desired behavior after PR is merged:
when milestone name is long it would show with '...' format.

Fix:
add some bootstrap class so that long name should be formatted in '...' .

task-3217427

closes odoo/odoo#116811

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

Description of the issue/feature this PR addresses:
when logged in user name is too long then it take whole header to display it
name.

Current behavior before PR:
whole header is occupied when username is long.

Desired behavior after PR is merged:
when username is long it would show with '...' format.

Fix:
some property is added in oe_topbar_name class to display the  username in short
and '...' format

task-3217427

Part-of: odoo/odoo#116811

There were 2 errors fixed by this commit:
1. The form registry fields added in [1] and [2] in Odoo 13 had a
   `string` attribute translated with `_t()` while now it should be
   translated with `_lt()`. It was surely working in Odoo 13 but not
   anymore. It's not worth investigating to be sure.
2. The IMP done at [3] added a lot of fields but all of those forgot the
   `_t()`/`_lt()` translation.

Note that:
1. A fix to replace `_t` by `_lt` was done at [4] but it was badly done
   as it was not targetting the correct version... and only fixed one of
   many occurences.

[1]: https://github.com/odoo/odoo/pull/32565
[2]: https://github.com/odoo/enterprise/pull/4063
[3]: https://github.com/odoo/odoo/commit/617eba941785aa680edb826e14b0009637d60dee
[4]: https://github.com/odoo/odoo/commit/2be83cae7bcda369ed5bc7806aef845c6c76e687



opw-3471873

closes odoo/odoo#132975

Related: odoo/enterprise#46206
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

Somehow, there is not .pot file for this module while there is a
translated term.

A proper investigation wasn't made, but here is the history:
- The "Project" translatable term was added in JS with commit [1] in
  April 2019 as an IMP in master so there was no addition in the `.pot`
  file, as expected.
- The `.pot` file was added by a `[I18N] export saas-12.4 terms` commit
  at [2] in Augustus 2019.
- The `.pot` file was removed by a `[I18N] export 15.0 source` commit at
  [3] in September 2021.
  This was probably an error as the "Project" term from this module was
  never removed and always existed since it was added in 2019.

[1]: https://github.com/odoo/odoo/commit/6df3ba8b22ff16e9fd8ad6d87ea55e7eaf13e67b#diff-529f47293f2a178209115a2bc74ce79c5a880e58497a5e9d86ad4d7fd29676baR17
[2]: https://github.com/odoo/odoo/commit/8be6470a826fc6e467a3bef1696d236249ca29f9#diff-29cc1f256a825ea298abd8b7780984bacca6b874c5d139412fed5fb164794cd2R1
[3]: https://github.com/odoo/odoo/commit/63e6807437295519a0f4705fb88644d6d557ca3a#diff-29cc1f256a825ea298abd8b7780984bacca6b874c5d139412fed5fb164794cd2L1

Part-of: odoo/odoo#132975

Issue:
In the project's portal view, if the user is previewing his tasks of a
project with a specific order that is not date or name, and then
goes back to the project list view via the breadcrumb, he is met
with an error 500.

Steps to reproduce:
- Install Project
- With the portal user, go to Project
- Click on a project and sort the task by 'project'
- Go back to the project view via the breadcrumbs.
- Error 500

Cause:
Due to the definition of the url of the breadcrumbs which is
set with `keep_query` which keeps the arguments of the url. The
issue with that is that for the project list view, some of the sort
arguments are not defined, as they are only present in the task view.
So if we sort based on 'project' there is a `KeyError` in the
controller of the project portal view.

Fix:
If the `sortby` is not one of the valid keys, we fallback on 'date'
sorting, which is the behaviour in case when there is no `sortby`
argument in the url. This will keep the `sortby` in the arguments of
the URL, but just ignoring it. This is better UX than having a hard
redirection, because if the user decides to click on a project, the
tasks will be sorted with his previous order specified, which is
usually the wanted behaviour.

Affected versions:
15.0 -> 16.0

opw-3425342

closes odoo/odoo#129016

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

A new text has been introduced in 863eba62
but not added in the .pot file, this commit fixes this.

closes odoo/odoo#133571

Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

The inherited field of a custom field cannot be deleted

Steps to reproduce:
1. Install Contacts and Studio
2. Go to Contacts and open any contact
3. Toggle Studio
4. Add a field of any type in the view, remove it and close Studio
5. Go to Settings > Technical > Database Structure > Fields and search
   for `x_studio`

Solution:
Mark the inherited field as manual if its parent field is manual and
allow the deletion of inherited custom field if we also delete its
dependency

Problem:
The inherited field was not marked as custom so it was impossible to
delete it

opw-3093581

closes odoo/odoo#130420

Signed-off-by: Raphael Collet <rco@odoo.com>

The condition to create is wrongly evaluated and does not take into account
the country code and the picking type code. This commit fixes this by
reordering the conditions.

closes odoo/odoo#133161

X-original-commit: 30b00e5c
Signed-off-by: Josse Colpaert <jco@odoo.com>
Signed-off-by: Ricardo Gomes Rodrigues (rigr) <rigr@odoo.com>

In stock_production_lot model, there is a field last_delivery_partner_id which is displayed in a Tree View. This fields require to compute ALL the delivery_ids of each LOT, only to display the last_delivery_partner.

This implies a big performance issue for big lots with huge tracability needs in it. The idea is simple, dissociate the computation for delivery_ids, which is only used in Form View and the last_delivery_partner_id which is only used in the Tree View.

I do agree that if both are used in the same view, it would double the computation time. But currently there is a lot of useless computation. Currently the only way to mitigate is by removing the field last_delivery_partner_id in the Tree View, but if client needs that field, it doesn't works.

Benchmark

|Lots/Serial |# Lots | # Delivery | Before PR | After PR |
|:------------:|:---------:|:--------:|
|Lots| 3 | 3  | 0.2723 s |0.0091 s |
|Lots| 4 | 6699 | 307.98 s | 0.0059 s |
|Lots | 13 | 9575 | 569.85 | 0.0036 s |
|Serial | 80  | 80  | 0.30 s | 0.42 s |
|Serial | 150 | 150 |0.39 s | 0.51 s |
|Serial | 7000 | 2000 | 0.50 s/Batch of 1000 | 0.60 s/Batch of 1000|

closes odoo/odoo#129363

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Current behavior:
  If you set a specific sale_order_item for an employee on a project, and
  create a timesheet line from the "My Timesheets" menu,
  the sale_order_item will not be the one you selected for this employee.
  This happens because when you create a timesheet line from the "My
  Timesheets" menu, the employee is not set on the timesheet line.
  To fix this we fallback on the user's employee when creating a timesheet
  line from the "My Timesheets" menu.

Steps to reproduce:
  - Make sure you'r logged in as Mitchel Admin
  - Create a service product that create project and tasks
  - Create a sale order with this product
  - Go to the project and set a sale order item for Mitchel Admin in the
    invoicing tab
  - Go to the "My Timesheets" menu and click "Add Line"
  - Select the project you created
  - The sale order item will not be autofilled with the one set on the
    invoicing tab of the project.

opw-3463849

closes odoo/odoo#133478

Signed-off-by: Xavier Bol (xbo) <xbo@odoo.com>

After eb3dcd60cb88f190d6398d7cadfb7852eecf909c is_html_empty was
accepted in document layout and would no longer cause an error when
using "Configure Document Layout" wizard.

If l10n_de is installed, this caused an error itself in "Configure
Document Layout" because of the content of the external_layout_din5008
that itself use the "company" variable if available (and in the given
case, this is a NewId base.document.layout record).

To fix this issue, this commit backports the 16.0 forward-port of the
referenced commit (5f1ad0c1).

opw-3433583

closes odoo/odoo#133447

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Don't do it only at install.

closes odoo/odoo#133364

X-original-commit: 5add840b
Signed-off-by: Nicolas Seinlet (nse) <nse@odoo.com>
Signed-off-by: Christophe Simonis (chs) <chs@odoo.com>

Since [this commit], it's now possible to edit a media when it's in a
parent that is not editable thanks to `o_editable_media` class.
Unfortunately, these changes make the new class bypass the potential
`data-exclude` defined in the XML option declaration. So if the target
looks like that:
```html
<img class="o_editable_media odoo"/>
```
and the XML option declaration has a `data-exclude=".odoo"`, the option
will still be displayed. This commit corrects the way the
`o_editable_media` class works, so that it only bypasses the
`.o_not_editable` but not the entire exclude.

[this commit]: https://github.com/odoo/odoo/commit/580f1b77ce0b96b7efbf83a0ccdf6979bbf0e904



task-3476644

closes odoo/odoo#132849

Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

After this commit, we prevent the slideshow from appearing when clicking
on an "Images Wall" snippet image that has been set as a link.

Steps to reproduce the bug:

- Drag and drop an "Images Wall" snippet onto the page.
- Add some images in the snippet.
- Click on an image within the snippet.
- In the editor text toolbar, click on the "Link" button.
- Set the URL of the link to "/contactus".
- Click on the "Save" button in the modal.
- Save the page.
- Click on the image with the link.
- Bug: The slideshow briefly appears before redirecting to the "contact
us" page.

task-3425624

closes odoo/odoo#133325

X-original-commit: 8b29eabb
Signed-off-by: Colin Louis (loco) <loco@odoo.com>

closes odoo/odoo#133036

X-original-commit: 854923b8
Signed-off-by: Quentin De Paoli <qdp@odoo.com>
Signed-off-by: Josse Colpaert <jco@odoo.com>

X-original-commit: b9de6fc2
Part-of: odoo/odoo#133036

The closing session popup input for bank payment methods throws an error when no cash payment method is configured.

Steps to reproduce:
 - Configure a shop without any cash payment method and with at least one bank payment method
 - Open a session for that shop
 - Click on the button to display the closing session popup
 - In the popup, change the amount of the bank payment method

An error is thrown.

The fix simply consists in correctly checking if there is a cash payment method.

closes odoo/odoo#132473

Task-id: 3468828
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>

A check was added to prevent importing records with prefixes of existing
modules: https://github.com/odoo/odoo/pull/130825

 . This queries the
known modules, but non-admin users don't have access to that by default,
causing the import to fail for them. Allow the module query regardless
of access rights.

closes odoo/odoo#133326

X-original-commit: e1dcf886
Signed-off-by: Raphael Collet <rco@odoo.com>
Signed-off-by: Merel Geens <mege@odoo.com>

steps to reproduce it:
1. Create a storable product, add a Purchase vendor with
 start date = 20/6/2022 and delay = 56
2. Create another storable product, add the same Purchase vendor with
 start date = 11/01/2023 and delay = 21
3. For both products, add Routes "MTO".
4. Create a SO with those 2 products, and confirm it
5. As you can see, the price of the first product is correctly set
but not the second product

BUG:
This is due of "Order Deadline" (date_order) being set to an old date,
which is before the second product date_order.

FIX:
set max PO date as today

opw-3167094

closes odoo/odoo#132892

X-original-commit: 72a17baf
Related: odoo/enterprise#46177
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

This commit introduces a test in Odoo 15 about a broken behavior in Odoo
16 which was not covered by a test.
A fix will be shipped alongside this commit forward-port in Odoo 16.

The behavior involved here is about:
- Having a multi-url defined route
- One of those URL not having a model converter
- One of those URL having a model converter
- Creating a 308 redirect for the URL without model converter

Something like this route (real example from the code):
```py
@http.route([
    '''/shop''',
    '''/shop/page/<int:page>''',
    '''/shop/category/<model("product.public.category"):category>''',
    '''/shop/category/<model("product.public.category"):category>/page/<int:page>'''
], type='http', auth="public", website=True, sitemap=sitemap_shop)
```
And this redirect (real usual example from clients):
```py
self.env['website.rewrite'].create({
    'name': 'Test Multi URL 308',
    'redirect_type': '308',
    'url_from': '/shop',
    'url_to': '/magasin',
})
```

In Odoo 15, everything will work as expected:
1. Accessing /shop will redirect to /magasin
2. Accessing /shop/category/categ-1 will not redirect and user will be
   on /shop/category/categ-1 still

But in Odoo 16:
In the case described above, acessing the URL with model converter from
the route will fail and redirect to a non slugified URL in the form of
`/some-url?param=test.model%287%2C%29` which is basically the
stringified encoded version of the record `test.model(7,)`.

Note:
- It doesn't matter if the route is contained in the other, the error
  will still occur even if `'''/shop'''` was `'''/abc'''`.
- Even if all URL from the route have their own 308 redirect, the error
  will still occur.
- It won't have any issue if there is a 308 on the route with model
  converter: both the one without model converter and other url with
  model converter will work and won't be impacted.

This might be because of a concept of "merging URL" from httpocalypse,
see https://github.com/odoo/odoo/commit/347a3ccf763cc6958d5dc1df3168c9c65245736c



opw-3450054
opw-3466498

closes odoo/odoo#133183

Signed-off-by: Romain Derie (rde) <rde@odoo.com>

Issue :
When you try to import a big file it will display a blank error.

Steps to reproduce the error :
1-install inventory and e-commerce
2-go to products and import records
3-upload the file attached the ticket

Reason :
Before, there was a type included in the `reason` but now
it seems that the error has no type neither a message.

Fix:
I tried to just output a general error.

opw-3410954

closes odoo/odoo#128272

Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

Crop widget is implemented as div block that is supposed to be displayed on top
of other elements. However, it's not the case for dialogs, because they want to
be on top as well (z-index of dialog is 1050 bootstrap [1])

STEPS:
* Go to Sales Order
* SO
* Schedule an activity
* Use '/' command
* select image
* click image
* crop image

BEFORE: image crop toolbar is hidden behind 'Schedule activity' Pop-up

Fix it by increasing z-index for the crop widget

[1]: https://github.com/odoo/odoo/blob/9102df15cce455205a19fb7b9a0c36186cc51e3a/addons/web/static/lib/bootstrap/dist/css/bootstrap.css#L5524



opw-3391583

closes odoo/odoo#128830

Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

There was inconsistency in the translation for the words "price unit", with this
 commit all the "price unit" are translated the same.

closes odoo/odoo#132890

Task-id: 3262408
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Signed-off-by: Maximilien La Barre (malb) <malb@odoo.com>

This PR solve two things:
- Preview: due to the hardcoded width the preview didn't take all the page and
was push on the left.
- PDF: Weird stuff happened with the header, he was hiding information below
 the header.

Task-id: 3262408
Part-of: odoo/odoo#132890

Before this PR, when there is no shipping address, the pdf show an empty
"Shipping Address" header. By changing the colspan dynamically we can manage to
keep the layout like it was and remove the useless section.

Task-id: 3262408
Part-of: odoo/odoo#132890

When the user tries to import the invoice file with space on both sides
of the date value the error will be generated.

Steps to reproduce:
1. Install the `account_edi_ubl_cii` module.
2. Generate one `factur-x.xml` file or import this file
https://drive.google.com/file/d/1RCqLT37j2g6LPkauf75LpOzZt64XHd_L/view?usp=drive_link
3. Go to the invoice app and click the `upload` button.
4. Select the `factur-x.xml` file and an error will be generated at the backend
and nothing to be imported.

This commit fixes the issue by removing the extra spaces in the date value,
if user gives the spaces in the invoice file.

see-
https://github.com/odoo/odoo/blob/a0ea6302a574624604cad7d0903711b30a4802a6/addons/account_edi_ubl_cii/models/account_edi_xml_cii_facturx.py#L315



sentry-4331059603

closes odoo/odoo#132611

X-original-commit: 1f32b5ec
Signed-off-by: Laurent Smet (las) <las@odoo.com>

Currently, the user has access to a "Switch into credit note/refund" but
not the reverse button to go from a credit note/refund to an
invoice/bill. This is now the case.

This is a partial backport of https://github.com/odoo/odoo/pull/103427



task-id 3102251

closes odoo/odoo#132969

Related: odoo/enterprise#46200
Signed-off-by: Florian Gilbert (flg) <flg@odoo.com>

Steps to reproduce:
-------------------
- create a job position without specifying the company;
- being in the first company, create an application for this job position;
- being in the second company, create an other application;
- go to the job position kanban view;

Issue:
------
Despite the selected company, the count for this job application is still two.

Solution:
---------
Include the allowed companies in the query to count the number of applicants.

opw-3453348

closes odoo/odoo#133033

Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>

It's possible to specify an existing module as the xml id prefix when
importing records from a file. This will result in `ir_module_data`
records being created with `noupdate` set to False. When the module is
upgraded, these records will be deleted.

This can lead to undesired side effects like journal items for
accounts imported this way being deleted.

This change prevents creating new records linked to existing modules
when importing from a file. Instead, the user should either use no
prefix or the name of a non-existent module, like `__import__`.

opw-3231987

closes odoo/odoo#133053

X-original-commit: 56a53e90
Signed-off-by: Merel Geens <mege@odoo.com>

The aim of this commit is to allow any tax tag to be set on a journal
item and to allow the user to put tax tag from foreign countries in
which they have a VAT number on any tax.

The end goal is to allow the user to impact tax reports from several
country with the same journal item, avoiding the creation of a whole
journal entry and setting the path for some more automation.

Context:
Our user has a company based in Belgium but has a warehouse in
Netherland. Thus, when the company sells anything from that warehouse, it
needs to fill the Dutch tax report directly.
Moreover, the company needs to fill a grid on the Belgian VAT tax report.
That means that the user would need to gather some journal items on both
the Belgian tax report and the Dutch tax report.

Before this commit:
The user can't set tax tag from another country on its tax nor in the same move.

After this commit:
The user can set tax tags from any country for which its company has a
foreign vat number on any tax and in a move

Task-id: 3196547
opw-2810712

backport of https://github.com/odoo/odoo/commit/c45a164b136f3f12eb3b203646463dfa0bddd50b



closes odoo/odoo#131088

Related: odoo/enterprise#45385
Signed-off-by: John Laterre (jol) <jol@odoo.com>

When a model selection record is going to be deleted, a _process_ondelete method is called in order to delete all the records of the corresponding model that have that selection. These records are obtained by calling _get_records, which uses a query that needs a table. Thus, we should avoid cases for non-abstract models that have _auto = False.

closes odoo/odoo#133067

X-original-commit: 408175a7
Signed-off-by: Raphael Collet <rco@odoo.com>

closes odoo/odoo#128827

Related: odoo/enterprise#43982
Signed-off-by: Sofie Gvaladze (sgv) <sgv@odoo.com>

Commit [1] does not include the amazing feature "apply on variants".
As a result, a legit configuration could lead to a `ValidationError`
(see the new test `test_cycle_on_legit_apply_variants`)

Note about the modifications of `test_11_multi_level_variants`:
because of an ORM limitation, if we create a BoM line directly:
```py
self.env['mrp.bom.line'].create({...})
```
the constraint will not be triggered... We need to write the line
creation directly on the BoM

[1] 4a4f92c5

opw-3200969

closes odoo/odoo#133039

Signed-off-by: William Henrotin (whe) <whe@odoo.com>

Steps to reproduce:
- Create a product in KIT
- The product and components must be AVCO rated.
- Sell product, confirm delivery and post the invoice

Bug:
the journal entries are not reconciled.
the lines are gouped by product but in this case the products don't match
on the stock side it's the components and on the invoice it's the kit

Fix:
match components stock moves of kits to the kit product

opw-3208169

closes odoo/odoo#128009

Signed-off-by: Adrien Widart (awt) <awt@odoo.com>

Steps to reproduce:
- Go to `/blog`.
- Enable "Show Sidebar" in the "Customize" menu.
- Edit the page.
- Click on an icon of the "Follow Us" section of the sidebar.
- Click on the "Link" icon of the editor toolbar.

=> An error popup appears.

In further versions, the link parameters can be edited - but they are
lost upon save.

The social media links sections of the blog and blog post pages is
generated and is not supposed to be editable.

This commits makes these social media links sections non editable.

If a user needs to configure such a content specifically, it can be done
inside the "About Us" section of the sidebar above.
E.g.:
- Deactivate the "Follow Us" section from the "Customize" menu.
- You can use copy/paste to duplicate the existing style of the
"About Us" section if you want.
- Click on the "File / Image" icon of the editor toolbar (or type
"/image" to use the Power Box as of 15.0).
- Select a pictogram.
- Click on the "Shape: Circle" icon of the editor toolbar.
- Select the "Font Color" from the editor toolbar.
- Click on the "Link" icon of the editor toolbar to specify an URL.

opw-3450880

closes odoo/odoo#132024

X-original-commit: 2ba1ab5f
Signed-off-by: Romain Derie (rde) <rde@odoo.com>