Before this commit, the buttons to scroll to the next element might not
work if the next element was invisible.
Steps to reproduce the bug fixed by this commit:

(Note that these steps are only reproducible from 15.0. We decided to
merge this fix in 14.0 to be custo-friendly)

- Install two languages on a website
- Drop a cover block (1), with a height of 100% and a scroll down button
- Drop a new block (2) only visible for language B below the block 1
- Drop a new block (3) visible for everyone below the block 2
- Save and go to the site in language A
- Click on the scroll down button

=> No scroll at all while the user expects to scroll to the block
visible to everyone (3). This commit fixes that by making the user
scroll down to see the next visible element.

opw-2967706

closes odoo/odoo#105334

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

Before this commit:
 If we remove a payment line using an Adyen payment method,
 `pending_adyen_line()` return `undefined`.
 With the `_poll_for_response` still being executed,
 it will pop some JS traceback each call with:
 ```js
 TypeError: Cannot read properties of undefined (reading 'terminalServiceId')
 ```

After this commit:
 No JS traceback loop

OPW-3032391

closes odoo/odoo#105716

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

Commit 7fbb337e introduced performance slowdown when reconciling a
bank statement line with multiple invoices. This is due to the
compute function being called a lot of times and each time need to
trigger a search for CABA moves (even if the company do not use
cash basis).

This commit aims to not trigger the search if the company do not use
cash basis and add some domain conditions on indexed fields to speed up
the search when it's a cash basis company.

opw-3013391

closes odoo/odoo#105925

Signed-off-by: John Laterre (jol) <jol@odoo.com>
Co-authored-by: Arnaud-Sibille <arsi@odoo.com>

If the method `_auto_install_l10n` is called programmatically on a DB
where the localization has already been installed, useless processing is
performed by `button_install`.

Do not call this method if no module need to be installed.

closes odoo/odoo#106310

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Before this commit: if one product in one of the previous orders is
archived, it won't load the order properly for order management.

opw-3035231

closes odoo/odoo#105952

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

On large database this can take 700 ms per moves. After a few ms.

closes odoo/odoo#97000

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>
Co-authored-by: Laurent Smet <las@openerp.com>

On the ticket https://github.com/odoo/odoo/pull/101547

 a constraint was added to prevent the user from changing the product type if some moves have already been made.
This was done because changing the type creates inconsistencies (like breaking the valuation).
However, it currently only checks if there are moves on the current company, when it should check in all companies.
This can be fixed by adding sudo.

closes odoo/odoo#106313

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

Non EU vendor bills are sent to the Tax Agency as self-invoices,
so the partner actually is the seller, but the same checks on the
VAT must apply as it was the buyer.

Task: https://www.odoo.com/web#id=3010849&model=project.task


opw-3010849

closes odoo/odoo#104779

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

The dimensions UoM of the carrier packaging is useless: it is not the
one used in the requests and there is not any conversion

To reproduce the issue
(Need delivery_fedex. Use demo data. Enable debug mode)
1. In Shipping Methods, edit 'Fedex US':
    - Package Weight Unit: KG
    - Debug Requests: True
2. Edit its Fedex Package Type:
    - Height: 1m
    - Width: 1m
    - Length: 1m
    - Package Code: YOUR_PACKAGING
3. Create a SO with a US partner and one product
4. On the SO
    - Add Shipping
    - Select 'Fedex US'
    - Click on 'Get Rate'
5. In Logging, open the request sent

Error: the dimensions of the packaging are expressed with "CM" but they
are not converted:
```xml
<ns0:Dimensions>
	<ns0:Length>1</ns0:Length>
	<ns0:Width>1</ns0:Width>
	<ns0:Height>1</ns0:Height>
	<ns0:Units>CM</ns0:Units>
</ns0:Dimensions>
```

When encoding the packaging in the request, the UoM defined on the
packaging (meter) is ignored. Instead, we define a length UoM depending
on the UoM of the weight and we don't convert any dimension:
https://github.com/odoo/enterprise/blob/e4fd13a0e073b9855864b7fabc26bc05b9a5fd19/delivery_fedex/models/fedex_request.py#L172-L178
There is even a `TODO` about the issue.

It will be the same with the other carriers. For instance, with UPS:
https://github.com/odoo/enterprise/blob/c9899f7860cd19c86f215d6dcea89f73b51433f3/delivery_ups/models/ups_request.py#L98-L102


We use the UoM of `ups_package_dimension_unit` and do not convert the
dimensions.

We can't implement the dimensions conversion on stable versions, since
it will break all existing packagings. So, as temporary solution, we can
simply hide the useless UoM defined on the packagings.

OPW-3053048

closes odoo/odoo#105308

Related: odoo/enterprise#33754
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

closes odoo/odoo#106246

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

Commit [1] actually "repair" the test theme installation that was
actually not calling `_post_copy()` for the website/themes created
through the `_post_init` hook of the `test_themes` module.
By doing so, the Nano theme now correctly activated the
`footer_language_selector` view, meaning that the tour would fail as
this Nano view would mess up with the tour (that Nano view was returned
on top of the Theme custo view).

Those website standalone tests should really be part of the regular
testing suite and not in the nightly build only:
1. This is getting really annoying to fix it again and again, we
   wouldn't have to do that if it was in the regular testing base as it
   could not be broken. This is a waste of time for no reason, as we
   need to investigate, understand and find a fix.
2. For now it only broke due to no real bug, most of the time it is
   because the test need to be adapted to a theme change or something,
   but one day someone will be able to break the website core mechanisms
   (COW, theme install etc) and this will be problematic.
   Note that if this was to happen, the runbot team will be handling the
   issue and the fix with the people that broke it, as it was promised
   when we discussed about moving those tests in the regular testing
   suite. It was the conscensus for us to accept to leave those tests in
   the nightly only (we didn't really had a choice tho).

[1]: https://github.com/odoo/design-themes/commit/fea847977d8bd4b0c0ddfc7685e3d3dc0933759c



closes odoo/odoo#106026

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

Setup multicurrency, with:
* rateA for dateA
* rateB for dateB (dateB > dateA)

Have an invoice in dateA with foreign currency and duplicate it.
Checking the journal entries, you should see that Debit/Credit is the
same as the source invoice. Posting the invoice would assign today date,
keeping the wrong rate.

opw-3007740

Backport of 0ac6bb4662b537ed10eaab89a6484476c421342f

closes odoo/odoo#106146

Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

This commit aims to solve the reported issue where printers are switching states from "connected" to "disconnected" and stay unreachable for 2 minutes. Now theavailable printers will be searched for multiple times before disconnecting them
task 2891909

Fixes 2687380
Fixes 2856101

closes odoo/odoo#103292

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

Issue :
- Liechtenstein adapted the same QR-Invoice as Switzerland.
However, Odoo only allows the issuance of QR-Invoices to
swiss customers

https://www.llb.li/en/private/paying-and-saving/payment-services/qr-bill#:~:text=Standing%20orders%20based%20on%20orange%20payment%20slips%20can%20no%20longer%20be%20processed%20after%2030%20September%202022.%20Therefore%2C%20these%20standing%20orders%20need%20to%20be%20newly%20set%20up%20on%20the%20basis%20of%20QR%20bills

.

Fix:
- Allow LI users to be issued QR-Invoices

OPW-2977644

closes odoo/odoo#100470

Related: odoo/enterprise#34168
Signed-off-by: Josse Colpaert <jco@odoo.com>

- Currently the label of the lines is not limited to the number of characters. When the user gives a name that is too long, the graph will not be displayed.
- This commit limits the number of labels, if exceeded it will display as ...

closes odoo/odoo#95291

Signed-off-by: Mathieu Duckerts-Antoine <dam@odoo.com>

closes odoo/odoo#105740

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

The existing code was generating misleading errors for imported Odoo
modules that could not be loaded.  Although there was a specific hack
for module 'studio_customization', imported modules were not handled
properly.  This patch adds the right condition in the SQL query in the
module that introduces imported modules.

closes odoo/odoo#105955

Signed-off-by: Vincent Schippefilt (vsc) <vsc@odoo.com>

Steps to reproduce:
    - install a localization which uses the account_edi module;
    - define Lock date for the fiscal period;
    - choose an invoice which was sent before this date;
    - click on the "REQUEST EDI CANCELLATION" button.

Issue:
    We try to cancel the EDI document despite exceeding the fiscal period.

Cause:
	The verification of the fiscal period is done when clicking on the "RESET TO DRAFT" button which, in the flow, is after the request for cancellation of the EDI document.

Solution:
    Make a verification of the fiscal period when clicking on the "REQUEST EDI CANCELLATION" button.

opw-2990873

closes odoo/odoo#106014

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

Computing account.move.payment_state relies on this field. When
perfoming payment operations in bulk (like during an upgrade) the field
computation may become too slow.

On recent upgrade cases the abscense of this index caused delays ranging
from 5 hours to whole days in the upgrade of big DBs.

closes odoo/odoo#105794

Signed-off-by: Christophe Simonis <chs@odoo.com>

Current behaviour:
When we are printing a report and then the report fails to generate
(for ex. wkhtmltopdf memory limit/timeout),
the incorrect state is committed to the database.

Expected behaviour:
We should rollback when generating reports fails, since it is an error state.

Steps to reproduce:
To reproduce the behaviour, we need to force an error state.
- In odoo/addons/base/models/ir_actions_report.py:`_run_wkhtmltopdf()`,
raise an exception before spawning the subprocess (for ex. adding a 1/0).
- In addons/web/controllers/main.py:`report_download()`#L2126,
add this little code snippet:
```python
ids = [int(x) for x in docids.split(",")]
report = request.env['ir.actions.report']._get_report_from_name(reportname)
obj = request.env[report.model].browse(ids)
if getattr(obj, 'message_post'):
    obj.message_post(body='This report was committed!')
```
- Install Inventory
- Pick a delivery order and try to print it, there should be an error
(whatever exception you decided to raise in `_run_wkhtmltopdf()`)
- See that in the message board we got a message that the report has been committed,
which isn't the case, it failed to generate.

Reason for the problem:
Controllers are catching the exception when generating reports,
but never reset the state of the database.

Fix:
Raise an InternalServerError with an error code of 500 to trigger
a database rollback.

Affected versions:
- 14.0
- 15.0
- saas-15.2
- saas-15.3
- 16.0
- master

opw-3001950

closes odoo/odoo#104594

Related: odoo/enterprise#33443
Signed-off-by: Julien Castiaux <juc@odoo.com>

Steps to reproduce:

  - Install `Expenses` module
  - Go to Settings > Technical > Email > Aliases
  - Edit the `expense` alias
  - Ensure the model is `Expense`
  - Set `Alias Contact Security` to `Everyone`, then save

  - Send an e-mail to the expense alias, using an e-mail address not
    referenced on one of the employees.

Issue:

  Error in logs related to `currency` variable.

Cause:

  Trying to create an expense for a non-existing user, therefore,
  no currency is set.

Solution:

  If no user is found, no need to create the expense and let the orm
  raise the error that a required field is not set (field employee on
  expense).

opw-3027350

closes odoo/odoo#105771

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

Version:
V14 only

Steps to reproduce:
install Studio app (web_studio module);
inside an app create a new model with Studio;
choose the "Date & Calendar" feature for the new model;
create the model.

Issue:
An error occurs "Invalid view Default calendar view for x_modelName definition in False".

Causes:
Server log:
`odoo.tools.view_validation: <string>:1:0:ERROR:RELAXNGV:RELAXNG_ERR_INVALIDATTR: Invalid attribute edit for element calendar`
`odoo.tools.view_validation: Invalid XML: Get RNG validator and validate RNG file.`

Explanation:
".xml" files must be verified with the grammar inside the ".rng" files. The "edit" attribute is missing in the calendar tag grammar (calendar_view.rng file). This attribute is added during the validation's process of a view when it is created.

Link of the function which add the attribute: https://github.com/odoo/odoo/blob/14.0/odoo/addons/base/models/ir_ui_view.py#L899-L912



Solutions:
Add the "edit" attribute inside the "calendar_view.rng".

opw-2972415

closes odoo/odoo#100456

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

Steps to reproduce:
1. Create a membership product for a period of time in the past,
 and one including the current day
2. Create a member, make him non-free
3. Create an invoice for the member for the past membership, cancel
 the invoice
4. Note that membership state is not updated to `cancelled` (Problem 1)
5. Change the `date_cancel` on membership.membership.line
 to a date in the past
6. Add an invoice for the current membership, note that the state is
 updated to `cancelled`
7. confirm the invoice and register payment, note that the state is
 not update to `paid` (Problem 2)

This line in `_compute_membership_state` causes the bug to appear:
```
if partner.membership_cancel and today > partner.membership_cancel:
    partner.membership_state = 'free' if partner.free_member else 'canceled'
    continue
```

To solve the issue, we remove the lines of code that made the state
to be stuck and use the membership lines only to calculate the correct
state.

opw-2978902

closes odoo/odoo#104178

Signed-off-by: Grazioso Andrea (agr) <agr@odoo.com>

In rating/controllers/main.py, the method action_submit_rating accepts
only post request. This creates a problem when you're trying to use the
web editor on the template as well as when you just paste the url in
your browser, for those are get request. The current behavior is a crash
with 'method not allowed'. This commit's purpose is to change the method
so it also accept get request. The use case of editing the feedback
rating page is arguable but it schould not crash.

The behavior after this commit is that the web editor is enable for the
page, and relaoding the page does not crash anymore.

task-3047893

closes odoo/odoo#104856

Signed-off-by: Laurent Stukkens (ltu) <ltu@odoo.com>

It is not possible to consume a component tracked by serial that comes
back from a scrap location

To reproduce the issue:
1. In Settings, enable "Multi Routes"
2. Create two storable products P_compo, P_finished
    - P_compo is tracked by serial number
3. Update the on-hand qty of P_compo:
    - 1 x P_compo with serial SN
4. Process a manufacturing order MO:
    - Product: P_finished
    - Compo: 1 x P_compo with SN
5. Unbuild P_finished
    - It brings SN back to stock
5. Scrap one P_compo with SN
6. Unscrap it (thanks to an internal transfer)
7. Repeat step 4

Error: a user error is raised: "The serial number SN used for component
P_compo has already been consumed"

When checking the SN uniqueness of a component, we don't consider the
case where a product came back from a srap location

OPW-3055252

closes odoo/odoo#105843

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

When marking a WO as done, if the serial number defined is related to an
unbuilt product, an error will be raised and the user will not be able
to mark the WO as done

To reproduce the issue:
1. Create a BoM for product P with one operation
    - P is tracked by SN
2. Produce one P with serial S
3. Unbuild it
4. Create and confirm a second MO with 1 x P
5. Start the WO
6. On tablet view, set the finished lot to S
7. Mark the WO as done

Error: a UserError is raised because "This serial number [...] has
already been produced". However, this serial number has been unbuilt so
the worker should be able to use it again

When marking the WO as done, we check the uniqueness of the defined
serial number. But:
- The check is not accurate enough, hence the above error
- The lot of the WO is a computed/inverse field based on lot of the MO
- Once the WO closed, we can still change the lot of the MO
- When marking the MO as done, a better method checks the SN uniqueness
(does not fail in the above case)

Therefore, the checking on WO side is useless. We should let the MO side
handle this.

Moreover, let's say that there is already one P in stock with serial S2.
On tablet view, if the worker set the lot to S2, there should be a
warning so he can be aware of the situation. This is already the case on
MO side:
https://github.com/odoo/odoo/blob/45e37b2ad7bdcfd9f9f7e1dabbd0a99c9a0b5cdc/addons/mrp/models/mrp_production.py#L694-L705



(This commit is linked to a similar commit OE side, same opw)

OPW-3002424

closes odoo/odoo#104456

Related: odoo/enterprise#33377
Signed-off-by: Tiffany Chang <tic@odoo.com>

### Steps to reproduce
* install the *VAT Number Validation `(base_vat)`* and Contacts module.
* Create a new contact from San Marino and set their Tax Id to SM05426
* Save the contact

You should see that the leading zeros have been removed on the Tax Id
(here, SM05426 became SM5426)

opw-3007722

closes odoo/odoo#103545

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

Setup:

  - Add a checkbox to the sublist view of quotations with studio and save
  - In the chrome devtools, select a custom network throttling profile
    with 1s of latency

Steps to reproduce:

  First example:

  - Go to a quotation with at least two lines
  - Enter edit mode
  - Change the quantity of the first line
  - Double click on the price field of the second line
  -> A traceback appears: `Cannot set properties of null (setting 'props')`

  Second example:
  - Go to a quotation with at least two lines
  - Enter edit mode
  - Change the quantity of the first line
  - Click on the price field of the second line
  - Click on Save
  -> The same traceback is there

Cause of the issue:

  The checkbox field is implemented in owl and thus the
  owl_compatibility layer is used.
  Mounted is not called on the checkbox if a new rendering is being done
  cf: https://github.com/odoo/odoo/pull/75950


  Currently, it is possible to set a row mode before the previous call
  and rendering is done.

Solution:

  Use a mutex for each record to prevent simultaneous render

opw-2937444

closes odoo/odoo#101419

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

When returning a dropshipped and subcontracted product to the supplier
location, the received quantity of the PO line will be incorrect

To reproduce the issue:
1. Create two storable products P_compo, P_Finished
2. Create a BoM:
    - Product: P_finished
    - Type: Subcontracting
    - Subcontractors: a subcontractor S
    - Components: 1 x P_compo
3. Create and confirm a PO:
    - Vendor: S
    - Deliver To: Dropship
    - Drop Ship Address: a partner P
    - Products: 1 x P_finished
4. Validate the receipt
5. Create a return with 1 x P_finished:
    - Update SO/PO quantities: True
    - Return Location: Partner Locations/Vendors
6. Validate the return
7. Go back to the PO

Error: The qty received is 2, it should be 0

There is currently no code to handle the return of a dropshipped product

OPW-3030895

closes odoo/odoo#105185

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

When returning a dropshipped and subcontracted product to an internal
location, the received quantity of the PO line will be incorrect

To reproduce the issue:
1. In Settings, enable "Storage Locations"
2. Create two storable products P_compo, P_Finished
3. Create a BoM:
    - Product: P_finished
    - Type: Subcontracting
    - Subcontractors: a subcontractor S
    - Components: 1 x P_compo
4. In Locations, edit WH/Stock:
    - Return location: True
5. Create and confirm a PO:
    - Vendor: S
    - Deliver To: Dropship
    - Drop Ship Address: a partner P
    - Products: 1 x P_finished
6. Validate the receipt
7. Create a return with 1 x P_finished:
    - Update SO/PO quantities: True
    - Return Location: WH/Stock
8. Validate the return
9. Go back to the PO

Error: The qty received is 2, it should be 1 (it should not be 0 since
the product has been returned to an internal location)

In `/purchase_stock._compute_qty_received`, there is already a code to
anticipate such a situation (i.e., a user who returns a dropshipped
product to his stock location):
https://github.com/odoo/odoo/blob/bf3c398f0644f690c64815b2b6e298aed7bedd70/addons/purchase_stock/models/purchase.py#L300-L305
However, the methods `_is_dropshipped` and `_is_dropshipped_returned` do
not include the feature subcontracting + dropshipping. This is the
reason why, in `_compute_qty_received`, the above condition is not
respected and why we add the return stock move to the received qty.

OPW-3030895

Part-of: odoo/odoo#105185

When creating a record, if a value is related to a monetary field and if
the currency field is a non-stored related one, the value will not be
rounding: when writing the monetary value in the database, we first call
`convert_to_column`. In the parameter, `record` is empty (it is not yet
created) and `values` only contains the stored values (so the currency
value is not present). As a result, `currency` will not be defined and
the value will not be rounded.

OPW-2955202

closes odoo/odoo#104346

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

Steps to reproduce the error:
- Install 'Maintenance'
- Select 'Maintenance' -> 'Request Maintenance'
- Create a maintenance request:
          + TH1: Save > Change stage to Repaired > 'Close date' =
Date.Today()
          + TH2: Don't Save > Change stage to Repaired > Save > 'Close
date' = blank

closes odoo/odoo#100777

Problem: App will show 'Close Date' blank
Expected: App will display 'Close Date' as Date.Today()
Solution: When Click on Save button -> Automatically get current date as end date
Signed-off-by: Arnold Moyaux (arm) <arm@odoo.com>

There are specific accounts that should be used for tax groups for
each version of the CoA

t-3059059

closes odoo/odoo#105648

Signed-off-by: John Laterre (jol) <jol@odoo.com>

Fixes a small but massive typo that prevents snailmail from working on
version 14 to 15

closes odoo/odoo#105707

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

This commit aims at preventing the deactivation of a company currency.
Was the issue on 2852452 support ticket (v14). But it seems appropriate to merge it in 13.0 as it is probably a good idea that a company currency always stays active.

How to reproduce bug:
In 13.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > create new invoice > select eur currency > cannot set usd currency back on invoice

Reconcile JS traceback in 14.0:
Install accounting with demo data > activate multi currency in settings > deactivate usd > go to accounting dashboard > click on reconcile 7 items on Bank journal > click on any “customer/vendor matching” line.

closes odoo/odoo#104819

Task: 2852452
X-original-commit: 1e336810
Signed-off-by: Quentin De Paoli <qdp@odoo.com>

closes odoo/odoo#105638

X-original-commit: 68f29fda
Signed-off-by: Xavier Morel (xmo) <xmo@odoo.com>

closes odoo/odoo#105510

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

Upon updates, the `active` field of `ir.ui.view` behaves differently
depending on whether the view is defined by using the `<template>` tag
or the `<record>` tag.

When using `<record>`, it behaves like any other field and gets updated
with the new value (notice that for qweb view, you should rarely rely
on this as if users customized those views with the website builder,
they are duplicated (COW)... updating the active field without migration
script would then be a source of errors).
When using `<template>`, it is not updated since [1], except for new
records since [2].

This commit adds a comment to the `active` field to help developers find
out about this difference.

See this [discussion].

[1]: https://github.com/odoo/odoo/commit/2d296cb77922d33be2dc45b900191fac34bda429#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR803-R804
[2]: https://github.com/odoo/odoo/commit/f1c70d4cc943ac4eb81a85a9dc005de34cd2060a#diff-175c28787c272a219b9275f79262a48af9aa029e718f45077fd609737559e84eR801-R804
[discussion]: https://github.com/odoo/odoo/pull/104836#discussion_r1013155860



Related to task-2963840

closes odoo/odoo#105524

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