Current behaviour:
If you export a view with a (some) filters and you set a custom
layout in the dashboard, you will get a traceback, preventing
you for accessing your newly exported dashboard.

Expected behaviour:
Should not crash when trying to view your exported view,
even with a custom domain.

Steps to reproduce:
- Install Dashboard, Sales
- Export from Sales > List View with a filter Creation Date before
  XX:XX (date is irrelevant)
- Go to Dashboard > My Dashboard > Change Layout to something else
- Exit the page and retry to reopen it, a stacktrace is shown.

Reason for the problem:
When preprocessing the arch of the view in the dashboard, which is an
xml string, there is the domain included, which contains symbols that
are unparsable by `etree` unless escaped (like `<`).

Fix:
Escape the domain client side before being sent and saved in the database,
so when requesting it we don't have a parsing error. Then we unescape it when
the clients reads the domain from the server. The unescaping before
escaping is to avoid problem of double escaping when changing subsequently
the layout of the board view.

Affected versions:
- 16.0
- saas-16.1
- master

opw-3130117

closes odoo/odoo#110662

Signed-off-by: Géry Debongnie <ged@odoo.com>

To reproduce the issue:
(Use demo data)
1. In Settings, enable "Multi Locations"
2. Create a storable and tracked-by-lot product P
3. Create an immediate receipt R
4. Add a line for 1 x P and save
5. Open the wizard 'Detailed Operations' and add a line:
   - 1 x P, lot 123, to WH/Stock/Shelf 1
6. Save
7. Open the wizard again

Error: The destination location of the line is now WH/Stock

When creating the SML, because we write on its done quantity, we
will automatically write the same on the new done quantity of the SM
on the demand of that SM. Doing so, it will trigger the assign
process:
https://github.com/odoo/odoo/blob/57ac92fc4c14bf305ffd9ef98212cc80013345f5/addons/stock/models/stock_move.py#L599-L602
(And it will therefore lead to the putaway rules feature)

Once the above issue is fixed, there will be another one. When
marking the SML as done, if it's needed, we assign it a lot. However,
writing on such a field will trigger the reservation process:
https://github.com/odoo/odoo/blob/c9fdd4f2ac2d8afb18cb0dd126bb0b88c54f374e/addons/stock/models/stock_move_line.py#L330-L333


And it will lead, again, to the putaway rules feature

OPW-3086704

closes odoo/odoo#112267

X-original-commit: 86b78b2a4a8bc350d7df19e6786bf4ee00021457
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>
Signed-off-by: Adrien Widart <awt@odoo.com>

Usecase to reproduce:
Create a replenishment of warehouses sheme. E.g:
Production WH -> Distribution WH -> Shops
Set all the rules from SHOP to PRODUCTION as replenish on order.

Go to the replenishment report. Usererror due to a loop in the
rules.

It's wrong because he found twice the same rule that pull from
interwarehouse transit. Fix the code to handle intertransit rules

closes odoo/odoo#109640

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

Usecase to reproduce:
- Set the warehouse as 3 steps receipt
- Put a security delay of 3 days for purchase
- Set a product with a vendor and 1 days as LT
- Replenish with the orderpoint

You expect to have a schedule date for tomorrow that contains all the
product needed in the incoming 4 days.

Currenly the internal transfer from QC -> Stock is for tomorrow (ok).
The transfer from Inpur -> QC is plan for 2 days in the past. (not ok)
The PO date is plan for 5 days in the past. (not ok)

It happens because the system check at each `stock.rule` application if
purchase is part of the route. If it's then it applies the security lead
time. It's a mistake because we should apply it only the first time.

To fix it we directly set it when the orderpoint run and not during
`stock.move` creation.
However for MTO it's not that easy. We don't want to deliver too
early the customer. So we keep applying the delay during the
`stock.move` creation but only when it goes under the warehouse stock
location.

Part-of: odoo/odoo#109640

The access rights tests would fail on databases created on day 0 and
test executed on day 1 because of the stress day demo data, they would
overlap.

Testing for stress days' access rights are done in dedicated tests, thus
it's ok to delete all the existing ones here.

closes odoo/odoo#112266

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

Before this commit, if a many2x fall the quickcreate, it will fall back
correctly to the slow create, but it will also raise an error.

Now, the error is not raised anymore.

closes odoo/odoo#112201

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

In werkzeug 2.2.2, the following characters "$!'()*+,;" are now
considered as safe by url_quote. This makes the filename_secure test
fail with the hard coded expected string containing a single quote as
'%27'.

This commit adapt the filename_secure test in order to work with all
versions of werkzeug.

closes odoo/odoo#112197

Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>

The path matching logic got reimplemented in werkzeug 2.2[^1] and the
new router is no more compatible with regexp groups[^2]. Our custom
converter for slugged-records in urls (`'/partner/agrolait-5'` => `5`)
has been adapted to match the route using non-capturing groups. It still
extracts the slug/id pair using the groups-capturing regexp.

[^1]: https://github.com/pallets/werkzeug/pull/2433
[^2]: https://github.com/pallets/werkzeug/pull/2519

Part-of: odoo/odoo#112197

Since Werkzeug 2.1.0, the Response.autocorrect_location_header is
disabled by default.

As it's RFC compliant and supported by browsers, the base_url is simply
removed from the assertions.

Part-of: odoo/odoo#112197

When redirecting when a double slash appears in url, werkzeug >= 2.2.0
redirects with a status 308 instead of a 301.

Part-of: odoo/odoo#112197

Quick and dirty fix to avoid `'connection': 'close'` header with
websocket.

Part-of: odoo/odoo#112197

In werkzeug 2.2.2, the NumberConverter class was moved in routing.
Needed as Debian Bookworm provides werkzeug 2.2.2.

See https://github.com/pallets/werkzeug/pull/2433

Part-of: odoo/odoo#112197

closes odoo/odoo#112068

Signed-off-by: Stockbauer Matthieu (tsm) <tsm@odoo.com>

Usecase to reproduce:
- Set product as FIFO and a cost of 10$
- Sell 5 units
- Modify the cost method to average

We expect the value of the stock to remain -50$.
However it went to -150$

It happens because the change of cost method is not supported
with negative quantity of stock. It's not really a huge bug because
it will be reconcile to the real value in the next in and when the
stock will be positive again but at least it gives a proper valuation
of the inventory.

opw-3100717

closes odoo/odoo#111341

X-original-commit: 3ff51daa
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

Follow-up reports were not going through due to the background clipping
into the address area.

closes odoo/odoo#109615

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

closes odoo/odoo#112259

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

*: website_slides

In some cases, components had dark text over dark background (or light
text over light background) by mistake.

Example:
- Enter edit mode.
- In the theme tab, choose "boxed" as page layout.
- A color picker appears below to control the color behind the box.
- Set it to a dark color (if your box main color is light)
- Go to a course page (install website_slides)
- Check the mobile version
=> The bootstrap tab and its section uses the dark color you set up as
   body color instead of the expected boxed layout color.

Another example:
- Do the same thing (set up a dark color behind a boxed layout).
- Go to a shop / product page.
=> The inputs are dark with dark text.

This is because of bootstrap which uses `$body-bg` as default value for
other variables, such as `$nav-tabs-link-active-bg` in the first case
described above. It also uses the variable in the creation of CSS rules
not controlled by explicit variables.

In 16.0, bootstrap was updated to 5.1.3 with [1] and this actually
increased the problem: input backgrounds now default to `$body-bg`,
amongst other things. Since [2], `$body-bg` is also used as the default
color for range thumbs.

In previous versions, this fix focused on fixing a critical component:
nav-tabs, for which the fix was straightforward.
Starting from 16.0, this commit will fix everything at the small risk of
changing the `$body-bg` variable meaning in the case of boxed layouts.
Before this commit, its meaning was "the color used for the background
behind the boxed layout (the <body> background color)", so equal to the
Odoo value `o-color('body')`. After this commit, its meaning will be
"the color used for the background of the box itself", so equal to
`o-color('o-cc1-bg')`. The `<body>` background color will be forced by
using `o-color('body')` as the value for the related *CSS* variable
defined by bootstrap. This allows to have a correct CSS generation for
all components in case of boxed layouts: indeed, the components mix
their own color with `$body-bg` (or use it as it is) relying on the fact
this is the color which appears behind them... which was not right in
case of boxed layouts.

This commit actually fixes another bug that was found during adaptation.
It is 2-fold, and unfortunately, it does not make sense to fix one part
without the other as it would increase the problem without the other
part. The website_slides pages customize their default background color
to not be the one chosen by the user, but a mix of it with some
lightgray. Odoo default for the body being white, this makes it a
lightgray for website_slides pages. This is totally ok... but only in
"full" layout. In boxed layout, we have the 2-fold problem:

A. The mixed color is not applied to the boxed layout but on the
   background behind the box. So if you have a white box above a black
   background, in website_slides pages you won't have the black
   background you expected to keep but a lighter version of it and the
   website_slides box will not use the lightgray but stay white
   (creating other inconsistencies as the lightgray would also be used
   by other components like tabs, for that app only).

B. The mixed color is actually not mixing the right colors: it mixes
   the hardcoded lightgray with the color of the background behind the
   box, while it was intended to be the one of the content (the one of
   the box), like in "full" layout.

The changes explained above about `$body-bg` naturally fixes (B). Not
fixing (A) at the same time would result in a big change for the color
which is behind the box. This commit fixes it at the same time by now
applying the color to the right element. In previous version, this could
be fixed as well but would require a different fix (not relying on
`$body-bg`). So it makes sense to merge this first and backport+adapt.

[1]: https://github.com/odoo/odoo/commit/971e5a91aab96d36129a823e03f1f9f1b1293968
[2]: https://github.com/odoo/odoo/commit/46e53879749be7ba3d30338d0f25c0a68a88eb3c



opw-3151962

closes odoo/odoo#112136

X-original-commit: 03f238aa
Signed-off-by: Romain Derie (rde) <rde@odoo.com>
Signed-off-by: Quentin Smetz (qsm) <qsm@odoo.com>

The PR #105579 introduce the call of `setupCollaboration` in
`resetEditor` but did not remove the instructions in `resetEditor`
that will be called in `setupCollaboration`.

`this._getNewPtp` should be called by `setupCollaboration` as it is
called after an asynchronous call.

Additionally, `this._peerToPeerLoading` has to be awaited to prevent
concurrency issues.

closes odoo/odoo#110150

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

Steps to reproduce the bug:
- Drop a block steps on a page
- Change one of the icons
- Change the color of the icon

=> The connectors are not correct anymore.

This is due to [this commit] changing the tag `<i class="fa...` to a
`<span class="fa...` when the user replaces an icon. The steps options
assume that `<i/>` tags will remain `<i/>` tags (as it was before
[this commit]). We should not change the tagName when changing the icon
of an `<i/>` tag. This is likely to break (s)css, options, public
widgets, ... This commit fixes this bug by ensuring that `<i/>` tags do
not become `<span>` tags when replacing the icon. Moreover it allows not
to recreate an editor when you change the icon.

[this commit]: https://github.com/odoo/odoo/commit/7fd0698cf765a79959566b51e33cb76bff83d344



task-3068834
opw-3123850

closes odoo/odoo#106316

Signed-off-by: Outagant Mehdi (mou) <mou@odoo.com>

The fix that introduced `this._shouldDelayBlur = true` in
`openMediaDialog` was wrong as it was fixing a symptom rather than
the source of the problem. Later fix probably fixed the source of the
problem as the problem is not reproducible at the time of this commit.
If the symptom comes back, it ought to be fixed at it's source.

closes odoo/odoo#112216

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

In 15.0 this was supported. It may be also handy when editing views to
momentarily set the groups to `""`.

Steps to reproduce:
1. Install Odoo 15 locally
2. Edit or create a view with `groups=""` for some component
3. Upgrade to 16.
It fails.

Empty groups was allowed in 15.0 we want to ensure this is not broken
unintentionally anymore, such a new test was added.

Muted logged to hide the warning (also present in 15.0):
```
2023-02-08 11:09:18,697 506777 WARNING test_16_gr odoo.addons.base.models.ir_ui_view: The group '' defined in view does not exist!
View error context:
{'file': None,
 'line': 3,
 'name': 'foo',
 'view': ir.ui.view(242,),
 'view.model': 'res.partner',
 'view.parent': ir.ui.view(),
 'xmlid': ''}
 ```

closes odoo/odoo#112062

Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

The reconciliation fields of account.move.line should be independent of the move's state.

closes odoo/odoo#111962

Co-author: Habib (ayh) <ayh@odoo.com>
Related: odoo/enterprise#36815
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

This case of amls having a zero balance but an amount in foreign currency left is already managed by the new reconciliation in 16.0.
Furthermore:
-the test in POS is passing even with the revert
-the reverted commit introduces a performance issue on amount_residual by forcing the orm to fetch the whole m2m debit/credit_matched_ids.
-there is no test accounting-side depicting the issue (if there is really an issue fixed by the commit).

Part-of: odoo/odoo#111962

Before this commit, when an event containing only the creator was created in Google Calendar, the creator's attendee status in Odoo was marked as 'needsAction'. Now, when an event like this is created (in Google Calendar), the event is automatically accepted in Odoo.

A test was added to make sure that new events with only the creator are automatically accepted.

closes odoo/odoo#112179

Task: 2782961
Related-to: #68700
X-original-commit: 6d0ead3d73477614dc1bd97a95b695f80925fdd3
Signed-off-by: Arnaud Joset <arj@odoo.com>

This commit fixes a change in behavior between 15.2 and 15.3.

Previously, if an unidentified user tried to reach a route that had auth='user', it would simply redirect to the login page.

Currently, it redirects and invalidates the session_id.

This is an issue in the latest version of master after this PR https://github.com/odoo/enterprise/pull/36521


This commit changes the route of service-worker.js to auth='user'.

This route is called on the login page, which rotates the sid and therefore invalidates the csrf token. Making it impossible for a user to log in.

This is a race condition, meaning it would only appear if the user stayed on the login page for a few seconds, hence why the automated testing did not block the commit.

closes odoo/odoo#112169

Signed-off-by: Julien Castiaux (juc) <juc@odoo.com>
Co-authored-by: Julien Castiaux <juc@odoo.com>

before this commit, in active currency warning is shown in the account move form when the currency_field is empty.

after this commit, the inactive currency warning will be shown only if the currency is set and it is inactive.

forwardported manually

closes odoo/odoo#111863

X-original-commit: 0bb74026
Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

The problem happens when the company is Angelo Saxon, and
`l10n_eg_edi_eta` is installed. Also, the product should have a cost and
automatic inventory valuation.
https://github.com/odoo/odoo/commit/4b430f8e30efb15f06982e4673cd73531a2119b3


The problem is that with this commit, after calling the
`_set_next_sequence` function, it calls `flush_recordset`. It would cause
a write to be triggered and add an Automatic Balancing Line. While in
`_create_account_move` of PoS the stock output line will add later to it,
and make it unbalanced. The first Automatic Balancing Line is incorrect as
it will call `_create_stock_output_lines` later and it adds a line which
makes it balance. But with that Automatic Balancing Line as it's
unbalanced at the end it will call `_close_session_action` in PoS and
shows a pop-up to add another line to make it balance.

The solution is skip synchronize of journal entries.

opw-3137723

closes odoo/odoo#110956

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

Before this commit, when creating a new record using the quick create on
a kanban view, a flickering was visible. We can see the quick create
form disappear, the record list goes up, the quick create form re-appear
and the record list goes down again.

This occurs because, the record list contains an empty record that is
used on the quick create form. When clicking on the add button on the
quick create form, this record is directly saved, and as is already on
the list (the quick create form disappear and the record list goes up),
only after this action, a new empty record is created and added to the
list (the quick create form re-appear and the record list goes down
again).

Now, an empty record is created independently of the list, so when we
click on the add button on the quick create form, the record is saved,
a new empty record is created (the quick create form is emptied), and
the saved record is added to the list (the record list got the new saved
record), avoiding the flickering.

task-id=3085247

closes odoo/odoo#111818

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

When trying to recover peer to peer connection, the timeout of 500ms or
1000ms might be too short and 15000ms in unnecessary too long.

If the timeout is too short, it could remove the connection before the
peer to peer had the time to reconnect to it. When we call
`_recoverConnection` on `disconnect` in `oniceconnectionstatechange`
or `onconnectionstatechange`, the signal `disconnect` does not
necessarily mean that it will remain disconnected. Doing nothing could
be enough to reconnect.
(see: https://w3c.github.io/webrtc-pc/#dom-rtcicetransportstate-disconnected

)

closes odoo/odoo#112170

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

Before this commit, the iceCandidateBuffer was emptied before finishing
the loop. This is wrong as we must add all candidates from the buffer.

X-original-commit: 520a8805
Part-of: odoo/odoo#112170

Consider field F in module X with parameter translate=False, and F is
overridden in module Y with parameter translate=True.  During the
upgrade of module X, module Y hasn't been loaded yet, and the ORM
considers the field to be `translate=False`.  Therefore it converts its
database column from type jsonb to varchar, and accidentally drops
non-en_US values:

    {"en_US": "English value", "fr_FR": "French value"} (jsonb)
        -> 'English value' (varchar)

As a result, translations are lost after upgrade.

This commit fixes the bug by checking whether the field is translated in
database and patches the field accordingly when loading the registry.
This avoids the ORM considering the field as non-translated while
upgrading modules.

In order to "force" translated fields to become non-translated ones, at
the end of the loading process the patch above is discarded, and fields
are checked again.  We then adapt the schema of models that have such
fields.  This extra step handles the uninstallation of modules like
module Y in the example above.

The patching of the fields has one potential issue.  While upgrading
module X, field F is patched with translate=True.  If module Y actually
overrides F with translate=xml_translate or so, this may cause the
behavior of the upgrade to be slightly incorrect.  Because of the
complexity, we have chosen to not support this case.

closes odoo/odoo#110572

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

For some reason the `website_id` field was added in the form view of the
`ir.asset` model in a website module overide but it was not done for the
list view where it matters equally (if not most regarding the flow).

Indeed, those views / this model is mainly accessed for debugging
purpose in which case you are most likely looking for a specific asset.
In the website case, it's most of the time to find the custom asset
that was created following a scss customization in the right panel of
the website builder.
In such a case, it will have a website_id and will be easy to find in
the list view.

It's also the case for all the records having a `website_id`, we show
that field in both form and list view, it's always important when
managing / debugging DBs in multi-website environment.

See [1] for introduction of `ir.asset`.

[1]: https://github.com/odoo/odoo/commit/8cc066173dfb61bd95b8e1f0716f71f4e251810a



closes odoo/odoo#112139

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

Previously, order lines containing gift cards or rewards disappeared when the order was closed and reopened in the pos_restaurant module

The following adaptations have been applied:

- Added a backend function in the pos_loyalty module to return active coupons (gift cards) to the frontend
- Added a frontend function in the pos_loyalty module to remap coupon_id to couponPointChanges and order lines
- Added this.partner in the init_from_json function in the pos_loyalty module to avoid deleting reward order lines

Now, command lines don't disappear when switching from one command to another.

closes odoo/odoo#111864

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

Some changes were made to the default/demo/test data to be more
consistent:
  - Duplicates of "Paid Time Off" time off types are consolidated into
    one type (inluding year specific versions, ig "Paid Time Off 2019"
  - Annual Time Off is renamed back to Paid Time Off (both for the
    work entry type as the time off type) to be consistent everywhere.
  - All mentions of years in work entry types and time off types have
    been removed, as this is no longer relevant with the new allocation
    rules.
  - Time off types in the default data have been explicitely made
    company agnostic, in order for them to be available to all companies
    and not just the one company that was select when installing
    hr_holidays. This was already the case for the be_payroll data, but
    not for the standard hr_holidays ones.
  - Various small cosmetic / functional fixes and simplifications
    (eg deduplication of data)
  - expense_other_input has been made country agnostic, in order for it
    to be available in all countries.

task-2978513

closes odoo/odoo#112173

Related: odoo/enterprise#36796
Signed-off-by: Kevin Baptiste <kba@odoo.com>

Date fields are changing format if you type it in instead of using the
date selector calendar popup

Steps to reproduce:
1. Install Time Off
2. Open the current language and change the date format to `%d.%m.%Y`
3. Go to Time Off > Approvals > Allocations
4. Create a new allocation
5. Change the validity period to 10.03.2023 (by typing it in, not using
   the datepicker) and click out of the field
6. The date displayed is changed to 2010/03/20 or 20.03.2010 (if the
   datepicker was opened)

Solution:
Add dot and comma as a possible character for static format
Also deduplicated function isValidStaticFormat so we have a single
definition

Problem:
Formats using dots were not considered as valid static format so the
value entered was parsed with the format `yyyy/MM/dd` instead

opw-3081268

closes odoo/odoo#111862

Signed-off-by: Rémi Rahir (rar) <rar@odoo.com>

This commit fixes a broken selector when an avatar image (`.oe_avatar`)
is used next to a title element (`.oe_title`) to put them side-by-side.

Also it goes beyond that by ensuring the `.oe_title` element doesn't
take the whole width (cf. max 75%) to make a visual distinction between
it and the other form's fields, both in editable and non-editable form.

In small screen, as space is limited, the whole width is kept to make it
more userfriendly, only allowing a thin gap between the `.oe_title` and
the `.oe_avatar`.

Steps to reproduce:
- Open Apps
- Choose an App and, in the dropdown, click on Module Info
=> there is a huge gap at the top of the title

closes odoo/odoo#110431

Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

The PR #110241 inadvertently re-introduce the attempt to connect
in collaboration when the editor was reset. The attempt should only
be made when the user focus on the editable.

The line
`this.$editable[0].addEventListener('focus', this._joinPeerToPeer);`
in `resetEditor` will handle that case.

closes odoo/odoo#112167

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

Settings > General Settings > Section Users:
Button Invite behaves in a weird way.

In dutch, e.g., "Nodig uit" splits into 2 lines,
whereas it could expand, eating out a little bit of the
input's space.

closes odoo/odoo#112161

Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>

Steps to reproduce the bug:
- Create a repair:
    - Add any product to repair
    - Add any other product as part of the repair
    - Confirm the repair
    - Start the repair
    - End repair

Problem:
The cancel button becomes visible and clicking on it won't cancel the
moves, so it doesn't make sense to cancel a finished repair.

opw-3146606

closes odoo/odoo#112119

X-original-commit: b21bbcef
Signed-off-by: William Henrotin (whe) <whe@odoo.com>
Signed-off-by: Djamel Touati (otd) <otd@odoo.com>

currently there is an error in the configuration
of the default user for the iot windows
it is configured for "local service"
which is the French version of the local user.
Except if the pc window is not in French,
the user is not configured correctly.
We have to use the default local user name
of windows which is "LOCALSERVICE"

closes odoo/odoo#112129

Signed-off-by: Quentin Lejeune (qle) <qle@odoo.com>