Inside the Images Wall snippet, images are dispatched to columns
depending on the height already reached by each column. This computation
relies on a sub-pixel height which leads to a confusing behavior.

This commit rounds the sub-pixel height to a visible pixel height to
avoid the confusion.

Steps to reproduce:
In the default images of the Images Wall snippet, the third image (sign)
is one pixel taller than the other ones.
- Drop an Images Wall snippet.
- Select the "sign" image.
- Move it to the first position.
(Because of another bug involving a race condition with the loading of
images, you might observe a different behavior. Move to first position
again to recompute the layout several times.)

=> The compass image moved to the first column.

task-2990053

X-original-commit: 1fc45be924e904dc595af61e0845b91cc5d24a49
Part-of: odoo/odoo#124608

When using the previous button in an image wall, the image wraps around
but skips the last position.
When using the next button in an image wall, the image does not wrap
around.

This commit fixes this inconsistency by using the same behavior as the
one in 15.0 since [1]: wrap through all positions in both directions.

Steps to reproduce:
- Drop an "Images Wall" snippet.
- Add 6 images.
- Select an image.
- Click repeatedly on "Move to previous".

=> The image wraps around all positions except the last one.

- Click repeatedly on "Move to next".

=> The image does not move anymore once it reached the last position.

[1]: https://github.com/odoo/odoo/commit/3931f0a67f904daea6c891a3a80aa984760a7682

task-2990053

Part-of: odoo/odoo#124608

If applied, this commit will solve the issue of unsupported operand type in
journal item(s) when currency is not set.

Steps to produce:
- Accounting > Journal Entries > Create new entry.
- Add a line in Journal Items and remove the currency from that line.
- Save > Error will be generated.

Fix this issue by calling the compute of the currency when the currency is not
available.

sentry - 4069681536

closes odoo/odoo#122462

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

Steps to reproduce
==================

- Go to Accounting > Accounting > Journal Entries

The total at the bottom is not displayed and there is a `-` instead.

Cause of the issue
==================

The `amount_total_signed` field uses the currency_field
`company_currency_id`.
It should be present in the view for the web client to be aware of it's
value.

opw-3316448

closes odoo/odoo#125360

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

In JavaScript, createTextNode() escapes it's contents, so instead of
appending ' ' as text, we should append the character corresponding
to a non-breaking space. Alternative would be to use innerHTML.

odoo-helpdesk ticket 3372476

closes odoo/odoo#125089

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

To reproduce (V16):
 0. Install Accounting (can also be reproduced with just Invoicing, but
 there is no "journal item" menu that will ease the process to show the
 issue)
 1. (In debug), change the dollar currency rounding to 0.0001
 (instead of 0.01)
 2. Go to Accounting > Customers > Invoices
 3. Create a first invoice with:
  - a partner P1
  - set an invoice date
  - make sure that there is a payment term set (for example "30 days")
  - at least one invoiced line (the product does not matter) with the
  tax 15 % and the price to 12.36
 DO NOT confirm the invoice
 4. Create another invoice with
  - ANOTHER partner P2
  - set an invoice date
  - make sure that there is a payment term set (for example "30 days")
  - at least one invoiced line (the product and the price does not
  matter)
 5. Go back to the Invoices list view and select the 2 new (unposted)
 invoices then Action > Post entries.
 6. Check Force and "Post Journal Entries"
 7. Go to Accounting > Reporting > Journal Items
 8. Group by "Journal Entry" and unfold the 2 last invoices (that should
 be the one validated in 6.)
=> The "Partner" set on the Debit Line is the one of the other invoice
(and vice versa)

Analyse:
 This issue is a mix of different sub-issues. Solving any of this
 sub-issue would solve the issue but as other sub-issues may exists we
 will fix each of them individually.

 Sub-issue 1:
  The account.move.line (=AML) partner is set correctly before the post
  (6.), this is during the "mass posting" process that the issue happens.
  The partner is changed because of this line:
  https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2094-L2096
  The value written to AML of id `line_id` include `move_id` which
  overwrite the account.move that was originally set on the AML.
  As the `partner` is computed only in certain circumstances, if the
  `move_id` written differ from the one of the AML, most of the values
  will be updated with the write values, but the `partner_id` will keep
  its value (this is why the swap of partner happen).

  In other words, this issue happen as `line_id.move_id` order is
  different from `key["move_id"]`. So we write on the "wrong" AML.

 Sub-issue 2:
  In theory, this issue should not have happened in the first place.
  The line:
  https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2061
  should have prevent the re-edition of the AML (as actually no relevant
  datas are written). But the equality between the dictionaries fail due to some rounding errors.
  Here:
   - needed_after[<key Invoice 1>]["balance"] --> 14.214000000000002
   - needed_before[<key Invoice 1>]["balance"] -> 14.213999999999999
  N.B: if we don't set an "invoice date" on the invoice, a rewrite is
  done before which would prevent our issue to reproduce.

 Sub-issue 3:
  If we try to reproduce the issue without setting a "payment term", the
   issue would not reproduce.
  By setting a "payment term" the `to_delete` computation change at:
  https://github.com/odoo/odoo/blob/8006e7ce618f98bd26a82cf9b64eaa9b6e9c9d2a/addons/account/models/account_move.py#L2067


  This happens as the `existing_before` keys and `needed_after` keys are
   different:
  - existing_before[<key Invoice 1>]["discount_date"] -> False
  - needed_after[<key Invoice 1>]["discount_date"] ----> None
  As the values are different, Odoo all the AML to the `to_delete` which
   then trigger their overwrite.

  In other words, if no "payment terms" were set on the invoices, the
  issue would not happen either

opw-3270471,3292931,3333799

closes odoo/odoo#124517

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

before this commit, in the mobile view, in the search bar
of the website users(forum) and events leader board,
the placeholder is shown as Search courses

after this commit, the wrong placeholder will be updated
to Search users in the placeholder as in the normal view.

closes odoo/odoo#123016

X-original-commit: 7e94e8a147cc1344b87d9800db7428384aa4b8e2
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>
Signed-off-by: Hennecart Jérémy (jeh) <jeh@odoo.com>

At the moment, there is no test that checks that normal credit notes
(i.e. of type TD04, not reverse-charge refunds) are correctly exported
in FatturaPA.

So we're adding one. We're making it a complicated credit note (it
contains some negative amounts) in order to improve the test coverage.

closes odoo/odoo#122930

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

When we go into customer preview of a quotation for example and change the language different than English (to fr_BE for example)
we see that some of the content isn't translated  and still displaying in english.

Steps to reproduce the error :
1-Install sales and website app
2-Create a quotation for a customer and just save it don't confirm it.
3-Go to customer preview
4-Change the language to fr_BE
5-Click on "signer & payer"
6-You can see that it still display 'Full Name' in english and also some other terms

The origin of the problem is that all the parts that were rendered via a t-call gets rendered in english.
I investigated the problem and it turns out that the language code for the _t is alwyas english(https://github.com/odoo/odoo/blob/06719a84c52c7a97487b7ee0bef3bbe166d5b502/addons/portal/static/src/js/portal_signature.js#L45)
The problem is that the user_context.lang is always undefined here (https://github.com/odoo/odoo/blob/06719a84c52c7a97487b7ee0bef3bbe166d5b502/addons/web/static/src/legacy/js/core/session.js#L201)
As a solution I copied the code from 15.0 which was working fine (https://github.com/odoo/odoo/blob/4fa2dbcaf777c23758519ab0feb9707a7592cd6b/addons/web/static/src/legacy/js/core/session.js#L199-L209

).

opw-3192666
.

closes odoo/odoo#122447

Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

By RPC an other user in other company can access to an other fec.

closes odoo/odoo#125391

X-original-commit: 857f2e02
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

In this commit we have made the following changes.
- Add new refuse reasons:
       - Languages issues
       - Role already fulfilled
       - Duplicate
       - Spam
       - Refused by Applicant
- Modify refuse reasons:
       - Refused by Applicant: don't like job
       - Refused by Applicant: better offer
- Clickable job position breadcrumb in website.
- Set default applicant when we create new email template
- Use the `selection_badge` widget in Refuse Reason wizard

task-3336247

closes odoo/odoo#122434

Signed-off-by: Kevin Baptiste <kba@odoo.com>

This commit will have nested components making use of
the usePosition hook to synchronize their repositioning.

**Before this commit**
Each component handles its own repositioning logic.
If it is mounted somehow inside another component using that
same logic, conflicts occur in some circumstances.

**After this commit**
It is now ensured that, in case of nested positioned components,
the whole chain of repositioning computations is called in the
proper order: from the parent to the children.

**Example**
- Before
  ![before]
- After
  ![after]

[before]: https://github.com/odoo/odoo/assets/1159815/3c9cfae7-db68-4707-a73c-ad7e2e71d4bf
[after]: https://github.com/odoo/odoo/assets/1159815/a21f56e0-d8e3-48c1-9509-8e6ee5040d4b



closes odoo/odoo#125359

X-original-commit: 7ceba441cc44ba6e6c7ee85008ab4b233e7f2d86
Signed-off-by: Michaël Mattiello (mcm) <mcm@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>

This reverts commit 38b689bb.

The IntersectionObserver strategy it implements do not
fullfil properly its purpose.
It was a mistake trying to use this kind of observer as
it is specifically meant for a different use case than
the one we tried to solve in the first place.

Another fix should follow directly this revert commit.

X-original-commit: 690f7b94
Part-of: odoo/odoo#125359

Issue: the xml declaration "<?xml version='1.0' encoding='UTF-8'?>" is
lost when opening the send & print wizard with existing xml attachments.

Explanation: When opening the send and print wizard, the PDF are
generated and postprocessed by `_postprocess_pdf_report`. In the
`_postprocess_pdf_report` override in `account_edi_ubl_cii`, the xml
attachments are parsed through `tree = etree.fromstring(xml)`, then the
base64 PDF is inserted, and the etree is converted to a bytes through
`etree.tostring(cleanup_xml_node(tree))` and the resulting bytes is
written back on the attachment, but the xml declaration disappeared.

Solution: include the arguments `xml_declaration=True, encoding='UTF-8'`
in the `tostring` function when converting the etree to a bytes.

opw-3144519

closes odoo/odoo#125285

X-original-commit: d89f5cb2
Signed-off-by: Laurent Smet <las@odoo.com>
Signed-off-by: Julien Van Roy <juvr@odoo.com>

create a vendor Bill
attach the PDF
go back to list view, select the bill > print Original Bills

Issue: a traceback is raised
Similar to f814c607
In some malformed PDF files zlib is unable to extract the data properly.

opw-3368907

closes odoo/odoo#125426

X-original-commit: 41f659e0
Signed-off-by: John Laterre (jol) <jol@odoo.com>

When updating taxes, all taxes are correctly created but the link
between children taxes and their parent was not correctly set.

opw-3347425 (1st issue)

closes odoo/odoo#125406

X-original-commit: 2fd0d2bb
Signed-off-by: Olivier Colson (oco) <oco@odoo.com>
Signed-off-by: Claire Bretton (clbr) <clbr@odoo.com>

Due to a change between Chrome 101 and 114, the CSS Custom Property
containing custom string are now always serialized using the type of
quotes used in their declaration (ie. single quotes will be kept ;
double quotes also) which wasn't the case in previous versions of Chrome
(and still not the case in WebKitGTK 2.40.0 at least).

This doesn't impact the value itself but only comparison between the
computed value and an arbitrary one (like we do in the design-themes
test).

This commit fixes it by removing the single/double quotes in the
`assertCssVariable` test helper.

The impacted precondition was introduced in odoo/odoo@b29e17765f4e912b2dd472493b5be500b3a32c87 and
odoo/design-themes@8b377af3a71b875dfc452a14206a9a1679371000 .

closes odoo/odoo#125404

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

Since d88409e8, taxes from different companies
are forbidden on sale.order.line records (which is the expected behavior).

Nonetheless, this highlighted some flows where the taxes were not properly
set/recomputed, especially re-invoicing, which is fixed by the current commit.

Fixes #123675

closes odoo/odoo#125394

X-original-commit: 6ce4019968bd0a1a11475910d35aa2ccfc2c6a9a
Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

It turns out `instanceof` is wonky in Firefox when multiple
documents are involved (e.g. iframe) since [1] has been fixed
and [2] has not yet been addressed accordingly.
Because of that, the check at [3] will return false and
therefore `getReference` will be a Node rather than a Function,
thus triggering the traceback.

**Solution**
Check if `reference` is typeof 'function' instead, which will not fall into the Firefox trap.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=1360715
[2]: https://bugzilla.mozilla.org/show_bug.cgi?id=1821790
[3]: https://github.com/odoo/odoo/pull/73130/commits/a9614e0babd6dc517287d547708a8be758c14e12#diff-86a5774240db76cdc93cb570596564cc6816ef4144a7c960f10cd347b7564e44R220



opw-3348172

closes odoo/odoo#125380

X-original-commit: 4ac33b76
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>
Signed-off-by: Bruno Boi (boi) <boi@odoo.com>

port of this fix
https://github.com/odoo/odoo/pull/70454



Steps to reproduce the bug:

- Let's consider a delivery carrier DC with invoice policy = 'real'
- Let's consider a consumable product P with a weight = 1kg and sales price = 10€
- Create a sale order SO with 2 P and add DC as shipping cost
- Process the shipment for 1 P and create a backorder
- Process the second shipment with the last P

Bug:

Two lines L1, L2 with DC were created on SO but only L1 as a price unit and a description.
L2 had a price unit = 0€ and no description.

opw-3219711

closes odoo/odoo#125379

X-original-commit: 4ce4f9444e5050ae30e4468ff24aecb573045dc7
Signed-off-by: Adrien Widart (awt) <awt@odoo.com>
Signed-off-by: Walid Hanniche (waha) <waha@odoo.com>

Since may 2020, M$ stopped to ship their 32 bits OS.
So, there is no need to distribute a 32 bit version anymore.

This will reduce the package size by 2.

The new package will use Python 3.10 by default, that's why the
local requirements were changed (a wheel package was missing for windows
in the previous version of PyKCS11).

closes odoo/odoo#125361

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

The modified test failed non deterministically on runbot since [1].
The test simulates an action that throws an error in its setup, and
assets that a dialog error is displayed. However, the thrown error
was incomplete (no "data" key), and it crashed in the error handler,
producing a second error, which was the one actually displayed when
the test passed. We rely on the "unhandledrejection" event to handle
errors, and an animation frame may occur between the moment the error
is thrown and the moment the event is triggered.

We fix this issue by actually fixing the root cause, which then
avoids the problem: the thrown error is now complete and the handler
doesn't crash anymore, so we are sure that the error dialog is in
the DOM when we check, and it is the dialog for the error we thrown
in the test, not for a crash in the code.

[1] https://github.com/odoo/odoo/commit/38b689bbfc2b



Runbot error~21956

closes odoo/odoo#125353

Signed-off-by: Samuel Degueldre (sad) <sad@odoo.com>

Before this commit:

Duplicating the contact that is linked to an attendee of a course also
creates a copy of an attendee as well.

After this commit:

It does not create duplicate attendee in course.

Task-3253983

closes odoo/odoo#125324

X-original-commit: e6c4937437bdf5e55c48fc80faf65b5094c96879
Signed-off-by: Thibault Delavallee (tde) <tde@openerp.com>

before this commit, on neutralizing the database the
mollie token is not cleared from the payment provider.

after this commit, on neutralizing a database, the
token from mollie payment provider is cleared.

closes odoo/odoo#125296

Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>

The bills upload widget uses a custom attr "linkText". translate.py will only generate terms that are in the TRANSLATED_ATTRS constant, thereby not including these in the po template file.

To fix this, the attribute is changed to a recognised attr "title".
The JS widget will still recognize linkText, for databases that have not updated the module.

Task-3335585

closes odoo/odoo#125276

Related: odoo/enterprise#42651
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

The bank recon custom view relies on the noContentHelper. (When there are no records, a custom noContentHelper is  displayed including buttons to clear filters)

When the view is activated from a RedirectWarning, the action's help text is not marked up
therefore displaying raw html in the UI.

With this fix, the actions help key is marked up (very similar to the doActionButton)

To reproduce:
- On a DB with demo data
- Accounting -> Actions -> Lock Dates
- Set a lock date for all users (after the last unreconciled date, ensure there are no unposted moved before this date)
- You will be presented with a Redirect Warning Dialog
- Click Show Unreconiled Bank Statement Lines
- If there are lines, use the filter to search for "SomethingThatWontReturnRecords"
- You will see raw html

Task-3366470

closes odoo/odoo#125254

Related: odoo/enterprise#42641
Signed-off-by: Laurent Smet <las@odoo.com>

Plans with no company defined were not showing in the list when
launching a plan on an employee.

task-3366394

closes odoo/odoo#124853

Signed-off-by: Kevin Baptiste <kba@odoo.com>

To reproduce:
1. Create a Sales Order for a product whose product category is set to
   FIFO and automated. Use route "dropship".
2. Confirm the PO created.
3. Deliver the products (DS transfer)
4. Create the customer invoice
5. Return, for example, 1 unit of product
6. Add a credit note to the invoice for that 1 unit returned (reset to
   draft then change qty and post)
Issues:
The value on the valuation layers of the returned picking is 0, posted
entries for COGS and stock interim (delivered) account for credit note
is also 0.

Since #85751, When create valuation layer for return, we take all svls
of origin_returned_move_id into account to calculate the price unit.
However, then dropshiping, 2 svls are created for the original move, and
the sum of them is 0 since there is no impact of the stock when
dropshiping. So when return, the price unit will be calculated as 0.

To fix, when calculate price unit for return of dropshiping, we only
take non-negative svls into account. Note that we use non-negative ones
instead of positive ones because when subcontract dropshiping,
additional negative svls will be added for the cost of the components.

opw-3283436

closes odoo/odoo#124725

X-original-commit: 1c128224dfcc85905671c3d9c01b3393bac15eb5
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Yuchen Huang (yhu) <yhu@odoo.com>

Steps to reproduce the bug:
- Install project_mrp
- Create a MO:
    - select any product
    - add an analytic account linked to a project, e.g: “field service”
    - save

- Go to the “field service” project
- click on “project Updates”

Problem:
The manufacturing order view button is not displayed, because we have
no MO in the done status

To display the button, we do a "read_group" on the
"account.analytic.line" related to the "account.analytic" of the project
 in the "Mrp" category.

https://github.com/odoo/odoo/blob/08112964f76816f11ef28d702ae49243f9cb5f91/addons/project_mrp/models/project.py#L42-L46



However, since the "account.analytic.line" records are created only
when the manufacturing order (MO) is in the "done" status, no records
are found, and so the button is not displayed.

opw-3300251

closes odoo/odoo#124714

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

task-3337958

closes odoo/odoo#122271

Signed-off-by: Kevin Baptiste <kba@odoo.com>

Before this commit:

In mobile view, the user was unable to select the table size form table
table picker, making table picker of no use.

After this commit:

In mobile view, the picker will not be visible visible and when the user will
write '/table' then a table of 3x3 dimension will automatically be inserted
without displaying the table picker.

Task id: 3283083

closes odoo/odoo#119806

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

Steps to reproduce:

1. Activate Dev mode
2. Settings > Technical > User Interface > Views
3. res.company.form
4. In the architecture add more pages
`<page name="test1" string="This is a test ABC DEF"/>
<page name="test2" string="This is a test ABC DEF"/>
<page name="test3" string="This is a test ABC DEF"/>
<page name="test4" string="This is a test ABC DEF"/>
<page name="test5" string="This is a test ABC DEF"/>
<page name="test6" string="This is a test ABC DEF"/>
<page name="test7" string="This is a test ABC DEF"/>` Save manually
5. Settings > Users & Companies > Companies
6. Open any company.

Issue:

Tabs go off the screen instead of moving down a row like in previous
versions.

Solution:

Adding the proper `overflow-x=auto` will handle the issue.

opw-3079492

closes odoo/odoo#107024

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

Have a product with internal reference
Open POS session
Create an order with the product
Invoice

Issue: Internal reference is shown twice on the invoice line

opw-3343170

closes odoo/odoo#125257

X-original-commit: 4fbcbd2b
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

For a `pos.payment.method`, it is possible to define an outstanding
account, but if this account is not defined as an outstanding account in
the company settings nor in the journal, the payment will not be
considered in the bank reconciliation, nor in the bank reconciliation
report.

Steps to reproduce (demo-data with POS and Accounting installed):
-go to 'Point of Sale/Configuration/Payment Methods'.
-click on the "Bank" payment method.
-add an 'Outstanding Account' which is not the default outstanding
 account of the company, nor an outstanding account of an
 `account.payment.method.line`.  So for example "Liquidity Transfer".
-then open a POS session, sell smth, pay with the Bank method, validate,
 then close the session.
-If you go to 'Accounting/Customers/Payments', you can see that an
 `account.payment` has been created, with the outstanding account being
 "Liquidity Transfer".
->It is not possible to reconcile that payment with a
 `account.bank.statement.line`. If you go to the accounting dashboard,
 then click the reconcile button of the journal "Bank", then on a
 statement line with no partner, you will not see the outstanding line
 of that payment.
->If you open the 'Reconciliation Report' of the journal "Bank"
 (accessible from the journal dashboard, by clicking the options of the
 journal), the line will not show in the 'Outstanding Receipts'
 category.

FIX:
Override the `_get_journal_inbound_outstanding_payment_accounts`
method of `account.journal`, to add the accounts from each
`pos.payment.method` linked to the journal.  Using the field
`pos_payment_method_ids` from `account.journal`.

opw-3271090

closes odoo/odoo#125178

X-original-commit: c002e6bf
Signed-off-by: Joseph Caburnay (jcb) <jcb@odoo.com>
Signed-off-by: Arnaud-Sibille (arsi) <arsi@odoo.com>

Most e-mail clients do not support CSS rules for hover effects.
Previously, the mass_mailing application allowed to add buttons with
such effects. This was confusing to some and introduced discrepancies
between the editor preview and the actual e-mails.

This commit removes such hover effects from buttons in the context of
mass mailing.

Task-2936682

closes odoo/odoo#125268

X-original-commit: 55aff2dcdf5537e16bdaf01ee68d776510572171
Signed-off-by: David Monjoie (dmo) <dmo@odoo.com>

Steps to reproduce
==================

- Switch to arabic
- Open a datepicker
- Select the month

The month are displayed twice in two different arabic namings.

Cause of the issue
==================

There is an issue in the moment locale files since [0]. It has been made
apparent since [1].

Solution
========

Cherry pick a fix from the moment repo [2].

Revert the ar.js locale from before [0]

[0]: 11f3e735
[1]: 6a1183f4
[2]: https://github.com/moment/moment/commit/251fba65cca5d5b2cf79f1f51a9d413c5e0cb161



opw-3349560

closes odoo/odoo#125241

Signed-off-by: Julien Mougenot (jum) <jum@odoo.com>

In a Sale Order, it is possible to select an invoice address without a
name. The partner of the transaction does not have a name, which leads
to a traceback when trying to split the name.

The idea is to force the name to be filled, with a fallback on the
partner' parent name.

OPW-3338406

closes odoo/odoo#125236

X-original-commit: 505109d4
Signed-off-by: Antoine Vandevenne (anv) <anv@odoo.com>
Signed-off-by: Vallaeys Valentin (vava) <vava@odoo.com>

closes odoo/odoo#125192

Signed-off-by: Martin Trigaux (mat) <mat@odoo.com>

With [1], the enforced black and white CSS values set on the :root were
not interpolated and rendered as the variable names instead of their
values. This commit fixes that.

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



closes odoo/odoo#125176

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