# Description
The absence of those fields can generate a log note spam & performance issue when updating an order line value.

# HOW TO REPRODUCE
- Create PO with 40+ order lines (50 recommend) (* SA to reproduce would be nice)
- Confirm PO (state needs to be "purchase")
- Update the Ordered Quantity of the first line.
- Save
=> PO Lines from page 2 and beyond have each created the following log message:
"The ordered quantity has been updated."

# Explanation
The purchase.order.line onchange will not save any update on 'price_total' because it is not on the onchangeSpec.
Then a purchase.order onchange is done, and this one does have 'order_line.price_total' on the onchangeSpec, forcing the onchange method to return the field 'order_line' (aka ALL the order lines) as updated.
When saving the changes, the JS framework, who does not have the data for the order_lines on the 2nd page, will not correctly filter the fields with real changes, and add the 'product_qty' field (and more) to the "write" call for every order_line not in the 1st page.
Then the write method, without checking if there is any real change on the product_qty, for each lines that has product_qty in the Write's values, will write in the log note and call a performance intensive method: _create_or_update_picking()

OPW-2982004

closes odoo/odoo#104490

X-original-commit: e99cdd64
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: David <dafr@odoo.com>

Before this PR when you select a pos.payment in custom, it raise.
It doesn't make sens to use api.model here

closes odoo/odoo#99237

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Before this commit if a Table of Content entry was a too long word
without spaces, it span beyond the width of the menu part of the Table
of Content block.
Note that in Chrome, during Edit mode the words are already split
across several lines because the `contenteditable="true"` of the
`#wrap` node applies some built-in extra styles (not from user agent
stylesheet) among which `overflow-wrap: break-word;`.

After this commit long words are split across several lines.

task-2965279

closes odoo/odoo#99114

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

closes odoo/odoo#104216

X-original-commit: e058add2
Signed-off-by: Louis Baudoux (lba) <lba@odoo.com>
Signed-off-by: Solan Delvenne (sode) <sode@odoo.com>

Prevent "per line" rounding taxes when tax rounding method is round globally.

closes odoo/odoo#104172

Task: opw-2963947
Signed-off-by: Laurent Smet <las@odoo.com>

Steps to reproduce:

1. Create a product named "Component A" (type = Storable)
2. Create a product named "Kit" (type = Storable)
3. Create a bom for the product "Kit" (type = Kit, lines=1x "Component A")
4. Create a Sale Order, with a sale order line for Kit (qty = 1)
5. Save the Sale Order without confirming it
6. Open a second browser tab, for the same sale order form
7. On the first tab, confirm the sale order
8. On the second tab, confirm the sale order (it's already confirmed in fact but this tab doesn't know it)
9. Go to the deliveries and open the generated picking

Current behavior:
* 2x "Component A" have been added to the picking.

Expected behavior:
* Only 1x "Component A" should be in the picking.

The fix is actually a backport of the commit 6eaea02d merged in 15.0+.

The objective is a little different than the original commit, because we don't really
support automatically decreasing picking quantities from SO after the delivery in 14.0,
however the same patch solves this issue too.

Closes #99659

closes odoo/odoo#99683

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

The clone page behavior in the page properties and the page manager was
changed with [1].
But it was actually not working anymore since [2]  as the input URL
could not be found, so it was crashing (`this.$ does not exist`).

This commit repair that clone page dialog but it is actually only fixing
the consequence of the issue and not the root cause as it should.

A deeper fix fixing the root cause will be done at [3].
In the meantime, this commit will be enough to prevent the issue as we
have more and more opw about that.

[1]: https://github.com/odoo/odoo/commit/4e340cc5f0c1fe9de17a2b852de4faf65a33926a
[2]: https://github.com/odoo/odoo/commit/4b8b079a7d9991a8dc481fe71a45185d672135c9
[3]: https://github.com/odoo/odoo/pull/104220



Courtesy of daramousk for this fix

opw-3033878
opw-3043224
opw-3046485
opw-3042542

closes odoo/odoo#104372

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

Steps to reproduce the bug:
- Create a Kit product "Kit 1":
    - Add a BOM with a component “C1”
    - Add a sales description
- Create another kit product without a sales description "Kit 2":
    - Add a BOM with a component "C2"
- Make sure you have a qty of “C1” and "C2"
- Create a SO:
    - Add "Kit 1" and "Kit 2"
    - Add any other storable product
    - Confirm the SO
- Go to the delivery → validate it
- Print the delivery slip

Problem:
The report doesn’t contain the kit product.

Because in the report, the `stock.move.line` are filtered by checking
the name of their move if it has the same name as the product in
the bill of material, but like the `stock.move` has the name
('description') of the `sale.order.line` instead of the product name,
the lines are filtered and not displayed:
https://github.com/odoo/odoo/blob/14.0/addons/mrp/report/report_deliveryslip.xml#L9



The behavior is the same for purchase orders

opw-2960467

closes odoo/odoo#101953

Signed-off-by: Tiffany Chang <tic@odoo.com>

Display the latest statement on journal dashboard.

Steps to reproduce:

- Create a bank statement for date X, with a line with date X + 1 day,
  confirm, reconcile and validate
- Create an other bank statement for date X, with a line with date X,
  confirm, reconcile and validate.
- Go to Accounting Dashboard
-> The latest statement is the first we created, instead of the last one

The reason is, the last statement was display depending on the
statements lines.

With this commit we change the domain to make it valif for bank
statement in order to search the last statement depending on the
order declared on account.bank.statement model.

opw-2752699

closes odoo/odoo#91887

Related: odoo/enterprise#33317
Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>

Steps to reproduce the bug:
- Create a Storable product “P1”:
    - UOM: unit
    - Update the qty to 100
- Create an out transfert:
    - Product: P1
    - Qty: 2
    - UOM: dozens
    - Validate the transfert
- Click on the valuation button
- an SVL is created with Qty: 24 → 2 pack of 12
- Go back to the picking:
    - Unlock it
    - change the done qty from 2 to 3
    - Lock the picking

Problem:
The quantity on the new SVL is not converted to the default UoM set on
the product.

In the write function of `stock.move.line` we calculate the difference
between the old and the new qty (3 - 2), then, the
`_create_correction_svl` is called:
https://github.com/odoo/odoo/blob/15.0/addons/stock_account/models/stock_move_line.py#L45-L48

without converting the diff qty into the product uom,
The `_create_out_svl` function is called with the `forced_quantity`
parameter:
https://github.com/odoo/odoo/blob/15.0/addons/stock_account/models/stock_move_line.py#L66
As it is a forced quantity, it will not convert it:
https://github.com/odoo/odoo/blob/14.0/addons/stock_account/models/stock_move.py#L188



Solution:
Convert diff qty in the `_create_correction_svl`, to avoid converting it
in every function it may call

opw-3041279

closes odoo/odoo#104096

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

Description is the label on invoice : tax rate is enough.
Align Finland on Odoo's new taxonomy, already available in BE
G = Goods, S = Services, IG = Investment Goods
Less active taxes for a smoother onboarding

Steps to reproduce:

  - Install finish Finnish Localization(l10n_fi) module,Accounting
  - Verify accounting taxes (brutto: 24%|14%|10%)
   price_include checkbox is deselected

Issue:

  Price_include field set to False

Cause:

  Field in locale template view not defined, model defaults to False

Solution:

  Field defined in tax template data and set to True for locale

opw-2992952

closes odoo/odoo#103725

Signed-off-by: Nicolas Viseur (vin) <vin@odoo.com>

Before this commit, following these steps:
- Go to /blog
- Activate the option Customize > Top banner - Name / Latest Post
- Disable the option Customize > Full Width Cover
- Click on the "guides" tag of the "Buying A Telescope" blog

No blog is displayed. This was because the top banner post is not shown
when the posts are filtered. Basically, once filtered, a blog post was
always missing.

Related to opw-2882492

closes odoo/odoo#104203

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

Before this commit, following these steps:
- Go to /blog
- Activate the option Customize > Top banner - Name / Latest Post
- Disable the option Customize > Full Width Cover

The URL to which we are redirected when we click on the blog of the
post presented at the top of the page leads to an error.

Indeed the URL of that link is something like "/blog?blog=blog.blog(2,)"
because of the template wrongly using the 'blog_url' QueryURL which is
defined in the case where we are rendering a blog page where no specific
blog is selected. We define that as `QueryURL('/blog', ['tag'], ...)`
but then parts of the template used it like this: `blog_url(blog=X)`
thus generating an URL like "/blog?blog=blog.blog(2,)". Adding "blog" to
the list of params would not be right as would create "/blog/blog/2"
which is still wrong as we want "/blog/2". And of course the "/blog"
prefix in the QueryURL definition is needed in case we only specify a
tag via `blog_url(tag=X)` (we expect /blog/tag/X). Patching QueryURL or
making blog_url a custom function instead of a QueryURL instance could
be a solution but it was judged not stable enough. We'll do that in
master. Here we only support "/blog?blog=blog.blog(2,)" URLs.

Note that many parts of those templates do not use the `blog_url`
function and simply build the URL by hand, which is why the bug only
occurred for a very specific set of blog options.

opw-2882492

X-original-commit: f32992de
Part-of: odoo/odoo#104203
Co-authored-by: Guillaume (gdi) <gdi@odoo.com>

TD02 is the only document type in l10n_it_edi that requires
the invoice to be a downpayment, but this doesn't mean that
downpayments are limited to it.
The condition has been adapted to allow downpayments to fall
under the other document types cases.

opw-3033403

closes odoo/odoo#103008

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

To Reproduce
============
- on Accounting, create customer invoice with a section and a notes and a product
- go to studio, and edit list view
- the quantities of the section and the note are set to 1
- this behavior lead to some errors like having wrong value in total if we aggregate the quantity column

Problem
=======
`account.move.line` is initialized by quantity = 1

Solution
========
when creating lines of invoice, set quantity of section/note to 0

opw-3010889

closes odoo/odoo#103377

Signed-off-by: William André (wan) <wan@odoo.com>

The current implementation of the many2one file upload in website form
will lead to a traceback in case of m2o fields.
It is currently only working with x2many fields. Note that it was
introduced as such with [1].

Step to reproduce:
- install website_sale
- drag & drop form snippet and click on it
- select "create customer" as action option
- add new existing field
- select "Main attachment" and save
- try to submit the form with a file uploaded in that new field
-> Traceback `ValueError: Wrong value for..`

This commit makes it work for all type of relational field.

[1]: https://github.com/odoo/odoo/commit/a77f5cf42faa75a2dd3931d83ad8ea86648248c0



closes odoo/odoo#102704

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

This commit fixes wrong usage of t-attf of [1].
It would output in the DOM `rel="len(active_tag_ids) and 'nofollow'"`

[1]: https://github.com/odoo/odoo/commit/0f2cada32319b3910d6ace6d412cfa94a646c9c7



closes odoo/odoo#104165

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

*: web_editor

Since [1], it was not possible to edit a company team snippet image
anymore as soon as the page was saved once. Indeed that commit added
o_not_editable/contenteditable="false" on the parent column to make sure
no text can be added in that column and contenteditable="true" on the
images so that they are still editable (even though HTML-specs-wise
adding contenteditable="true" on images probably does not mean much as
images are self-closing tags, our editor understand that as the ability
to edit the image anyway). That contenteditable="true" part is however
removed when leaving edit mode... and was not restored upon entering
edit mode again.

This fixes the problems with an ugly patch. We'll review what to do in
master.

Funny enough, that bug was actually gone in 15.0... by mistake. A recent
bug fix actually reintroduced that isolated bug at [2] (by reintroducing
the fact that images in a non-editable environment are not possible to
edit). The 3 opened tickets this commit mentions were actually reported
for 15.0 immediately after that, while the 14.0 being broken about this
since the beginning apparently did not bother anyone.

[1]: https://github.com/odoo/odoo/commit/656cac1bf21c7c5a56aa569008aac58436c747fb
[2]: https://github.com/odoo/odoo/commit/e113bae04a64a8bd341a80736086ab7c25079dd3



opw-3031217
opw-3032482
opw-3035289

closes odoo/odoo#104156

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

This is a follow-up of [1] which was a backport of [2].
The backport was missing the new terms in the translation file.

Also, it was probably better to keep the hint about the page being
reloaded when adding a font.
It was removed in 16.0 because since frontend > backend revamp the
options are not warning you about changes before reload anyway, so it
was adapted to fit the new "automatic" style. But it's not the case in
lower version, so we might as well keep it.
Note that this commit will be directly squashed in 15.0 in the forward
port chain of [1].

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



closes odoo/odoo#104137

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

Steps to reproduce:
- set time effeciency of a workcenter to less than 100
- on a product page with a BoM using that workcenter
- for the cost click on compute price from BoM

Bug:
workcenter effeciency is not taken into consideration

Fix:
included time_effeciency in computing the expected duration
addepted tests to take it into consideration aswell

opw-3033672

closes odoo/odoo#103705

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

Backport of #83422

closes odoo/odoo#104101

X-original-commit: b89b70cc
Signed-off-by: Vranckx Florian (flvr) <flvr@odoo.com>

This is a backport of [1] from Odoo 16

-----------------

Before this commit, the only possibility when adding a google font was
to use google servers to serve the font.

This was not ideal as some people really want to serve it themselves
without the need of their visitors to reach google servers.
That's especially true since recently where it seems like German clients
are receiving letters about that to tell them it's illegal and this
should be changed, as it wouldn't respect the GDPR.
Somehow, it seems related to the fact that google knows you visited a
website by just downloading the font, because they very well know with
just your IP who you are exactly.

It's yet unsure if that issue is well-founded or not, but since German
courts seem to be sanctioning people about this, there is no reason to
not at least provide a workaround.

What is sure is that it makes a lot of noise and more and more people
seem to be impacted by this as many opw are getting opened, as well as
github messages.

Whether it is well-founded or not is thus not really our problem
anymore, we should just provide a way for our users to protect
themselves against this "German law problem" (or at least think they are
protecting, if Odoo thinks that's a non issue or the German court is
wrong or ambiguous).

Note that a cookies banner to inform users would not be enough for that
"problem", as the user would already have accessed your website and thus
the related problematic fonts.
Another solution which is not something we want (at all) would be to
serve local system fonts while the user did not consent about google
fonts, or having a blocking screen page telling people visiting the
website will fetch google fonts. Obviously those 2 possibilities are a
no go as it leads to terrible UX.

Finally, note that:
- in Odoo 16, the default fonts will be the system fonts, meaning there
  won't be any call to google by default, regardless of this pr
- there is a work in progress to improve the current cookies bar to
  differentiate essential and non essential cookies and to allow user
  to accept only one or both (task-2800976).

Useful links:
- https://github.com/odoo/odoo/issues/83638#issuecomment-1054470699
  ODO detailed point of view about this
- https://rewis.io/urteile/urteil/lhm-20-01-2022-3-o-1749320/
  The German law about this

[1]: https://github.com/odoo/odoo/commit/b06ce21eba6388ce34bbffffadcb489f0e8557dd



Closes #83638
task-2756486
opw-2970167
opw-2960466
opw-2960555
opw-2952427
opw-2800976
opw-2748647
(possibly many more)

Courtesy of @bso-odoo for the regex part which was inspired by another
of his google font fix attempt

closes odoo/odoo#103389

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

Have the following taxes:
- Tax A: 15%, included in price
- Tax B: 21%, included in price

Create a product P with list price 115 and tax A

Have a fiscal positions FPOS configured with:
- Detect Automatically checked
- Country: Belgium
- Map tax on product: A -> B

Open a web shop session as guest, add P to cart
Go to checkout: Price total will be 115
Fill address details with Belgium address
Go to confirmation page

Error:
Price total will be 100. In the application of fiscal position the wrong
unit price is used

opw-2973879

closes odoo/odoo#103932

X-original-commit: 17aa4051
Signed-off-by: William Braeckman (wbr) <wbr@odoo.com>

when you open course ratings view, it may show also
some project ratings, if project id is same as course id.
This commit solves the mentioned problem.

Task-2997847

closes odoo/odoo#101244

Signed-off-by: Warnon Aurélien (awa) <awa@odoo.com>

On recursive BoM with more than 3 nested levels, the cost of the child
bom is wrong resulting in a wrong total

Steps to reproduce:
1. Install Manufacturing
2. Create products C1 (with cost 5€), P1, P2, P3
3. Create BoM for 2 units of P1 with 1 unit of C1 as component
4. Create BoM for 1 unit of P2 with 1 unit of P1 as component
5. Create BoM for 1 unit of P3 with 1 unit of P2 as component
6. Go to the BoM of P3 and open 'BoM Structure & Cost'
7. BoM cost of P3 is 1.25€, it should be 2.5€

Solution:
The quantity used to compute the price of a child bom should not be
divided by the child bom quantity

Problem:
When `_get_price` calls itself (with a child bom), the factor passed is
wrongly divided by `line.child_bom_id.product_uom_qty` because the
quantity used to compute the price of a component is already divided by
`bom.product_qty`
https://github.com/odoo/odoo/blob/eaf5618dc416a4565e084316595da4a0d8377acc/addons/mrp/report/mrp_report_bom_structure.py#L207



opw-3007792
opw-2990445

closes odoo/odoo#103796

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

It is not possible for a user to add a carrier directly on a picking if
the invoicing policy of that carrier is set to "Real Cost"

To reproduce the issue:
1. Enable a carrier C
2. Setup a shipping method SM:
    - Carrier: C
    - Invoicing Policy: Real Cost
3. Create and confirm a SO with a product
4. Edit the related picking P:
    - Carrier: SM
5. Validate P

Error: a Validation error is raised "The operation cannot be completed
[...] Model: Sales Order Line (sale.order.line), Field: Description
(name)"

When validating the delivery, we try to create a new SOL with the
shipping cost. We then update its description with the carrier name.
However, since the carrier has been directly added on the picking, the
sale order does not have that information. We should rather get this
information from the delivery.

OPW-2862306

closes odoo/odoo#103764

Signed-off-by: Tiffany Chang <tic@odoo.com>

When creating a recipient from composer_suggested_recipient the user
is free to modify the partner form however they want.

This can lead to them inputing data which will create a partner
that does not match the suggested partner data.
In that case the box acts as if the partner was not created.

This aims to remove the partner in such cases and warn the user.

task #3016112

closes odoo/odoo#103596

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Before this commit: if you use the lot/serial number for the products, it
won't load correctly through the UI.

closes odoo/odoo#103815

Issue: https://github.com/odoo/odoo/issues/100888


Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Necessary improvement to the snailmail invoice layout for snailmail to work since Pingen has deprecated their v1 API with the plan to shut it down at the end of 2022 + their v2 API's validation is stricter.

closes odoo/odoo#103379

Signed-off-by: Florian Daloze (fda) <fda@odoo.com>

Pingen's v2 API does not offer an endpoint to generate a Cover Page automatically with an API call anymore, thus the need to generate it and append it to the invoice from the client-side beforehand.

Part-of: odoo/odoo#103379

When writing a workorder start or end date from its manufacturing order
(and if the MO is unplanned), an error is thrown

Steps to reproduce:
1. Install Manufacturing
2. Go to Settings > Manufacturing > Operations and enable Work Orders
3. Open an MO with Work Orders
4. Unplan the MO
5. Add a Scheduled End Date to one of the Work Orders
6. Save
7. An error is thrown

Solution:
Compute the new duration only if both `start_date` and `end_date` are
set (and one of `date_planned_start` and `date_planned_finished` is
passed in values)

Problem:
When only one of `date_planned_start` or `date_planned_finished` is
written on an `mrp_workorder` (and the other is not set), the method
`_calculate_duration_expected` is called but it fails because it passes
a False value instead of a datetime which will raise the error `'bool'
object has no attribute 'tzinfo'`

opw-3004280

closes odoo/odoo#101961

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

New phones go up to 48MP (Samsung Galaxy A22).
Also the error message was saying 4.5 instead of 45.

opw-3020614, opw-3020502

closes odoo/odoo#103603

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

This commit restores the possibility to control the height of the
image gallery snippet. This was indeed possible in <= 11.0 for all
snippets but it was removed in 12.0 as controlling the height via inner
paddings seemed enough and better (as responsive). For the image gallery
snippet however, this was a big regression as the height is forced to
70% of the current screen height on drop and the images inside are
displayed depending on that forced height. Trying to control via
paddings was not leading to the wanted effect.

This restores the possibility in 14.0 as 12.0 and 13.0 are now
deprecated. This is following a customer issue where not having the
ability to control the height is actually confusing as the user edits
its website across different screens and the height is forced to 70%
height of the screen used at the time of edition. With an height input
in the panel, the confusion is gone.

Note: this also introduces a `forceStyle` parameter for the
`selectStyle` option to be able to force the inline style a widget
controls. Indeed, without it, the system is "smart" and tries not to
force inline style when it is not needed (if you try to force red on
something that is naturally red (thanks to a CSS rule for example), it
won't be forced). Here, this was leading to an issue when trying to set
the height:

- Current height is 700px
- There is some code that forces a min-height on all carousel items so
  that they are the same height. As the gallery image dimensions depend
  on the block forced height (this is how the snippet work), the forced
  min-height are related to that forced height (something like 680px).
- You focus the height input and type 800px
- The same code forces new min-height on all carousel item (something
  like 780px).
- You un-focus the height input, the system tries to re-set 800px (which
  is already set)... it ends up removing it as it thinks that setting
  that height is not needed as the snippet is now "naturally" 800px tall
  thanks to the carousel items' min-heights.

opw-2838774

closes odoo/odoo#103694

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

This join is a leftover from https://github.com/odoo/odoo/pull/28248


and is not needed anymore since currency_rate is now stored on purchase.order.
Removing it allows to greatly speedup purchase.report queries.

On a database with 7000 purchase order and 1100 res_currency_rate:

From:
Planning Time: 4.411 ms
Execution Time: 19815.754 ms

To:
Planning Time: 16.914 ms
Execution Time: 77.433 ms

opw-2973044

closes odoo/odoo#101002

Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

Current behavior:
If you try to edit the form view of pos.order in studio, you get a
traceback.

Steps to reproduce:
- Install point_of_sale
- Go to PoS order
- Click on studio
- Click on the button to edit the form view
- You get a traceback

opw-3008565

closes odoo/odoo#103403

Signed-off-by: Trinh Jacky (trj) <trj@odoo.com>

Method `consume` is called at the end of a tour. Tour can be started via debug
menu by any admin with "Access rights", however the method requires `Settings`
access level.

Fix it by adding `sudo()`. This issue could be reviewed in master.

STEPS:

* change Administration access level to "Access rights"
* start tour `sale_quote_tour`
* follow the tour steps

opw-2965772

closes odoo/odoo#99378

Signed-off-by: Ivan Elizaryev (iel) <iel@odoo.com>

The liquidity line of a statement line is always expressed in journal currency.
The counterpart lines (invoice lines most of the time) are expressed in the transaction currency.
When reconciling the statement line with an invoice line, the current code sums the amounts in foreign currency to detect if there is a rounding issue or not.
However, the considered amount for the liquidity line is not expressed in the right currency (journal currency instead of the transaction one).

Note: The current test is working even without the fix in 14.0 but is failing on the next version because the code has changed.

co-author: ushyme (sesn) <sesn@odoo.com>
opw-2991183

closes odoo/odoo#103676

Signed-off-by: Quentin De Paoli <qdp@odoo.com>

Steps to reproduce:
- Edit
- Add a snippet with columns
- Save
- HTML editor
- Set up a border on one column of the snippet with different colors for
  the top/right/bottom/left sides
- Edit
- Click on the column => crash

This is only an example, but if a colorpicker widget is linked to a
SnippetOption instance's `selectStyle` method designed to handle the
"border-color" property of an element, the value received can be split
if the item uses different colors for its top/right/bottom/left borders.
For instance, you could receive "red blue" if the item has red top and
bottom borders and blue left and right borders. In that case, the
colorpicker widget code would try to add the class "bg-red blue" on its
preview item which would crash because of the space inside).

After this commit, we simply do not show any color for this case.

opw-2803311

closes odoo/odoo#103654

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