Making a dynamic domain with a  field is a bad idea
when the domain doesn't filter out the most of records. It can create a
performance issue, if the  contains too many ids, then
a lot of data will be exchanged to/from the server for each onchange which
slows down all the form views.

This commit is different from the original commit that we are backporting,
which was already present in the master branch https://github.com/odoo/odoo/commit/6f30f7959e15cf9b9a1fe8dd47e5f8c2c2e443c4
However, the changes made in the original commit would cause issues in
Stable versions due to a Python change that breaks the existing XML view.
Therefore, it's not feasible to apply the changes as they are
and it was decided to keep _compute_allowed_mo_ids.

task-2558097
backport-of: https://github.com/odoo/odoo/pull/71870/commits/6f30f7959e15cf9b9a1fe8dd47e5f8c2c2e443c4



opw-3133757

closes odoo/odoo#113475

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

If there's a l10n_it_edi_transaction id on the move, then the move
has been sent to the SdI and it has received no rejection yet.
So we avoid showing the Reset To Draft button in that case.

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


Task-3191726

closes odoo/odoo#113085

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

If one of the theme was not migrated to the new tx api, still support
the previous notation.
Happened on the design-theme repository

Backport of a8355ba3

closes odoo/odoo#113635

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

closes odoo/odoo#113559

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

KeyError "sequence_code" occurs when creating a stock picking type. This is
because there is not a key "sequence_code" in vals.

This commit added the condition to ensure "sequence_code" key
is available in vals.

sentry-3828105626

closes odoo/odoo#112607

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

Creating a new partner with no company selected should raise the
same VAT partner warning if there is any other partner **in any**
company with the same VAT.

closes odoo/odoo#104367

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

Before this commit: if "Automatic Receipt Printing" is enabled in a PoS
restaurant, and a printer is configured, an error will raise if the user clicks
on "New Order" before the end of the printing process.

To reproduce the issue, I added a sleep at the beginning of the
`_printReceipt` of `AbstractReceiptScreen`, and clicked on "New Order"
immediately after validating the order.

The solution is to keep the `currentOrder` in a variable before printing.

opw-3096677

closes odoo/odoo#111041

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

The `format_float` function is calling `float_repr`, which should not be
used for rounding operation (see its docstring). Instead, we should use
the `float_round` function.

opw-3171987

closes odoo/odoo#113216

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

Courtesy of Marianna (cima)

closes odoo/odoo#113524

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

The line was supposed to mention the remaining surplus,
not the total difference between input and output tax.

closes odoo/odoo#113523

Signed-off-by: Brice Bartoletti (bib) <bib@odoo.com>

Finland is comprised in the EAS list but is not currently supported in
Odoo. This commit makes UBL Bis 3 available for Finnish companies.

opw-3178684

closes odoo/odoo#113410

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

Current behaviour:
When trying the resend a snailmail that had a format error, by
adding a cover we get an error that a record we trying to access is
deleted.

Expected behaviour:
We shouldn't delete the letter that we are trying to resend.

Steps to reproduce:
- Install Invoicing
- Add an IAP account with some credits
- Create a contact with a reallllyyyy long address, to overfill the
  fields.
- Create an invoice for that customer, try to print/send a snailmail
- It should fail without a message, then scroll down to the red
  paperplane, add the cover and update resend, you get an error
  about the missing record.

Reason for the problem:
This legacy code, so maybe in the past it used to work a bit
differently. When trying to resend the letter, we are unlinking it's
attachment (reasons for that are unknown to me), which is linked
with a `Many2One` with letter with a cascading delete, so we end up
deleting the `snailmail_letter` that we are iterating over, then
when trying to write, it throws the error.

Fix:
Remove the link between the attachment and the letter before the deletion
of the `attachment_id`, so the letter is not being deleted.

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

opw-3111774

closes odoo/odoo#113005

Signed-off-by: Piryns Victor (pivi) <pivi@odoo.com>

backport of 46040d11

closes odoo/odoo#112841

Signed-off-by: Rémy Voet <ryv@odoo.com>

Steps to reproduce:
- Create a new journal Bank
- In Sequence, find the 'New Bank Check" and edit it so the sequence can be 10 number digits long
- Create a Vendor Payments with the the New Banck and Check as a method
- Click on Print a check
- Set any number > 2147483647 and validate

Issue:
Traceback

Cause:
The query SQL make a check to verifiy that the number is correct ('025'::integer == '25'::integer but '025'!='25)
But using INTEGER limits the number up to 2147483647 (https://www.postgresql.org/docs/current/datatype-numeric.html

)

Solution:
Use BIGINT whose limit is 9223372036854775807

opw-3140973

closes odoo/odoo#112832

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

To reproduce the issue:

- Website > Edit mode > Click on header
- Change the shadow color of the header to a suggested gray > it only
  works with normal colors but not grays.
- Change the header to "Header full" (it has no shadow by default)
- Add a shadow > It works
- Change the shadow color to a gray > it is reverted to no shadow.

To explain what happens exactly, let's suppose we want to set the gray
color from the custom property "--900":

When this color selected on colorpicker, the `customizeWebsiteVariable`
method will update assets to set a new user value:

`'menu-box-shadow': var(--900) ...`

But when the SCSS is compiled, the property name (here "--900") is
computed as a number which generates a wrong CSS value: `var(900) ...`

The goal of this commit is to prevent this behaviour by protecting
colorpicker variable names so they cannot be used for any further math.

task-3069518

closes odoo/odoo#105916

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

In DB with lot of product.template with this domain [('barcode','!=','truc')] it is possible to get a MemoryError.

closes odoo/odoo#113254

Signed-off-by: Victor Feyens (vfe) <vfe@odoo.com>

There is only one legitimate usage of `_patch_method` (base_automation)
and none of `_revert_method`. The other uses are in tests and they are
all wrong: if the test crashes between the `_patch_method` and the
`_revert_method`, the method will not be reverted.

For the only proper usage of `_patch_method`, move the code to this
place. Correct tests using `_patch_method`/`_revert_method` by calling
the `patch` method of `BaseCase`.

Also, remove the `api.returns` from the `create` method of `BaseModel`
as it is useless and confusing. In fact, we never use it because we
have a special treatment at the RPC level for the `create` method
(see `_call_kw_model_create`).

closes odoo/odoo#110370

closes odoo/odoo#113171

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

- l10n_it_edi_sdicoop: EDI receiving cron error handling fix
If we cannot receive invoices or bills from the IAP proxy we also can't
iterate over them

- l10n_it_edi: Check edi_format before trying to remove signature
The edi_format must be checked before trying to remove the eventual
PKCS#7 signature from the file, otherwise we're uselessly going to try
and remove the signature for every edi_format check (facturX etc.)

- l10n_it_edi: .p7m files can wrongly be missing the signature
In the case that the .p7m extension is put by mistake, try to use the
content of the file as it is before discarding it.

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


Task-3189457

closes odoo/odoo#112845

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

To reproduce the issue:
1. In Settings:
   - Days to Purchase: 10
2. Create two products P01, P02:
   - Storable
   - With the same seller
     - Delivery Lead Time: 1.0
3. On replenishment page, create a new line:
   - Product: P01
   - Min Qty: 1.0
4. Order once
   - a RfQ is created and the order deadline is in ten days
5. Time travel to the next day
6. Repeat steps 3-4 with P02

Error: a second RfQ has been generated. However, as the first one is
still in draft state, the POL of P02 should be added to that first RfQ

When processing the orderpoint of P02, at some point, we try to find
an existing RfQ with its order deadline equal to `today + 10 days`.
Since we are the next day (step 5), the order deadline of the first
RfQ is `today + 9 days`, so we don't find it.

OPW-3047931

closes odoo/odoo#112687

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

In Switzerland, an ISR payment file was to be added to an invoice.

This file has since been replaced with the QR Bill: https://www.pikon.com/en/blog/everything-you-need-to-know-about-the-swiss-qr-bill/



Removed the buttons allowing for the printing of ISR files, while keeping the variables and functions linked to it to follow stable policy.

Those options will be permanently removed from 16.2.

task-3040400

closes odoo/odoo#110660

Signed-off-by: Olivier Colson (oco) <oco@odoo.com>

Before this commit, no check was made on conditional questions to see if their
condition was valid when taking a survey.

With this commit, if the survey is not in "random mode" (in which case,
conditions do not apply), there is a check to see that a conditional question
has a valid condition. If not, it is not used in the survey.

Task-3083488

closes odoo/odoo#110236

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

Steps to reproduce:

- Install mrp_workorder
- Edit product Table > Inventory tab > Tracking: No Tracking
- Manufacturing Orders > Create order for Table > Quantity = 3
- Confirm > Work orders tab > Open Tablet View
- Change the number of units to produce in the top from 3 to 2.
- Pause > Continue

Issue:
The quantity to produce is reset to the original amount.

Solution:
Do not reset the qty_producing when it is already set.

opw-3032052

closes odoo/odoo#113046

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

before this commit, there is a typo in auto_install

after this commit, the typo will be corrected

closes odoo/odoo#113090

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

This commit contains remaining changes which need to added in this
https://github.com/odoo/odoo/pull/112394

.

sentry-3824163568

closes odoo/odoo#112790

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

Current behaviour:
In Field Services, when selecting a task and applying let's say the
ending time of 15:34, when the date picker shows up the minutes were
set to 0, because 34 is not any multiple of the `timePickerIncrement`
(which is 5 by default).

Expected behaviour:
Even if the minutes are not a multiple of the `timePickerIncrement`,
we should round to the closest one.

Steps to reproduce:
- Install Field Services
- Fields Services > Planning > By Project > Day
- Choose a task, and play around with the minutes of either starting
  and ending (you need to save each time to see the effect)
- If the minutes are a multiple of `timePickerIncrement` = 5, then
  there is the correct selection, but for everything else it is 0.

Reason for the problem:
When rendering the date range picker, only if the minute is exactly
a multiple of timePickerIncrement and only then it is selected.
For all other cases nothing is selected, therefor the first item is chosen by default.
Also the date used for computation is the one set on the record when opening the form view,
not the one from the input field on the form.

Fix:
When opening the date range picker, we read the values from the input fields,
and update the view. This will also round the minutes to the closest multiple
of `timePickerIncrement`, and doing a rollover if necessary (X:59 -> X+1:00).

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

opw-3103490

closes odoo/odoo#110399

Signed-off-by: Michaël Mattiello <mcm@odoo.com>

To reproduce
============
- on website add or edit **contact us** form to create a task on a project
- fill the form from Incognito
- on project -> the created task : try to send message on chatter
- you will find the email used when filling the form with possibilty
to check it as receiver
- check the box, a dialog will open to create a Partner for this email
- close the dialog without modifying anything

Problem
=======
the checkbox will remain checked, but when you send a message no email will be sent

Solution
========
as stated in this comment https://github.com/odoo/odoo/blob/de1f701e7bd7ebb6f7ebea5c097d980039c4f904/addons/mail/static/src/components/composer_suggested_recipient/composer_suggested_recipient.js#L128-L130


we will only send the message to partnenrs, so if no partner is
created we must uncheck the checkbox.

opw-3168779

closes odoo/odoo#112214

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

In the EAS list, the United Kingdom code is set to 'UK' while in Odoo,
it should be 'GB'. Because of that, the UBL Bis 3 format doesn't appear
in the journals for GB companies.

opw-3169038

closes odoo/odoo#113013

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

Currently, it is possible to resequence account moves which are hashed.
This should not be the case. Therefore, we are adding the name of the
move into the list of hashed fields.

However, since we are changing the hashing algorithm by including a new
field in its computation, we must add a versioning system to make sure
we don't break the integrity (data inalterability) report.

In practice, this means that prior to this commit, all hashed moves used
the fields of v1, and moves after this commit will use v2 (which adds
the name into the list of hashed fields). Thus, whenever we generate
the integrity report, we will run the v1 algorithm, and if it a
potential corrupted move is found, we will switch to v2 and check again.
If it also fails, this means the hash is indeed corrupted.

task-id 3102481

closes odoo/odoo#112320

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

A DOM observer is initialized at the start of the table of content
(TOC) snippet options but is never disconnected. This could lead to
memory leak. The goal of this commit is to disconnect this observer and
stop intercepting the changes of the DOM at the destroy of the snippet
option.

Related PR: https://github.com/odoo/odoo/pull/110860



closes odoo/odoo#112960

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

product._get_rules_from_location, orderpoint._compute_lead_days
and orderpoint._compute_rules can all be performances
bottleneck. This is mostly because the rules are retrieve
one by one, i.e lots of 'SELECT ... LIMIT 1' queries
are executed.

Refactoring this in stable is difficult because
there are lots of methods involved and the rules have
some type of hierarchy based on the location_src_id field.
So there are recursive calls that are hard to refactor.

Instead of doing that, the idea of this commit is to speed up
these individual 'SELECt ... LIMIT 1' queries by adding
b-tree indexes on some of the stock.rule fields that are
used as conditions of these select queries.

opw-2773988

closes odoo/odoo#90531

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

Steps to reproduce the bug:
- Install FedEx delivery
- Go to the shipping method > FedEx:
    - Select Real cost and margin on rate 10%
- Create a storable Product “P1” and update its qty
- Create a SO:
    - Add the product “P1”
    - Click on add shipping
    - Select FedEx and get the rate
    - Imagine the price is $10 and with margin it's $11

- Confirm the SO and process the delivery

Probelm:
The shipping price will be $12 instead of $11 in the SO

Because the estimated price is calculated the first time with margin
and added in the picking when sending to the shipper:
https://github.com/odoo/odoo/blob/afed7db30042e2ea91cdae292dadb7b6f742e33d/addons/delivery/models/stock_picking.py#L226

Then, the delivery cost is added to the SO, but the margin is applied a
second time:

https://github.com/odoo/odoo/blob/afed7db30042e2ea91cdae292dadb7b6f742e33d/addons/delivery/models/stock_picking.py#L246

https://github.com/odoo/odoo/blob/afed7db30042e2ea91cdae292dadb7b6f742e33d/addons/delivery/models/stock_picking.py#L262

so this commit is useless:
https://github.com/odoo/odoo/commit/632767d83e0f42acc5b486bde02dd1d9c2533911


because the `_add_delivery_cost_to_so` function is called only when
sending to the shipper

opw-3184482

closes odoo/odoo#112910

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

Steps to reproduce the bug:
- Create a storable product “P1”
- Update the qty to 100
- Create a Transfer:
    - product: P1
    - type: Delivery order
    - qty: 1 unit
    - Mark as to do
    - Reserve the Qty

- Create a seconde transfer:
    - product: P1
    - type: Delivery order
    - qty: 5 unit
    - Mark as to do
    - Reserve the Qty
    - qty done: 2 unit

- Create a batch picking with the 2 transfer
- Try to validate the batch

Problem:
A traceback is triggered: “ValueError: min() arg is an empty sequence”:
https://github.com/odoo/odoo/blob/829369d3ca0530f1aad0599fbb1598810a928cc3/addons/mrp_subcontracting/models/stock_picking.py#L73

Because when validating the first picking, the `_action_done` function
is triggered, so moves that do not have qty done will be cancelled

https://github.com/odoo/odoo/blob/3073779762a106b4022bfb0a350758445d28ea15/addons/stock/models/stock_move.py#L1524-L1529

Therefore, the reserved qty will be unreserved, and the
`stock.move.line` will be unlinked

https://github.com/odoo/odoo/blob/3073779762a106b4022bfb0a350758445d28ea15/addons/stock/models/stock_move.py#L1442

https://github.com/odoo/odoo/blob/3073779762a106b4022bfb0a350758445d28ea15/addons/stock/models/stock_move.py#L724



Solution:
We get the `date` from the `stock.move.line` to use it only when we have
subcontracted production, we can therefore add a check before accessing
them

opw-3159876

closes odoo/odoo#112564

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

Steps to reproduce:
- install base_address_city and web_studio modules;
- go to Contacts app;
- click on a contact;
- active Studio;
- click on the "Contacts & Adresses" tab;
- click on "EDIT LIST VIEW".

Issue:
A traceback appears ("modifier "readonly": Unknown field type in domain").

Solution:
Add type field in the view.

opw-3107274

closes odoo/odoo#112519

Signed-off-by: Yannick Tivisse (yti) <yti@odoo.com>

Before this commit: if a different `web.base.url` is set with
`web.base.url.freeze`, during the first synchronization of Google
calendar it will show a mismatch URL error. The problem is that we
send the `redirect_uri` based on the `web.base.url` in the
`_get_authorize_uri` function.

The solution is to use the request root URL instead.

opw-3101741

closes odoo/odoo#111336

Signed-off-by: Arnaud Joset <arj@odoo.com>

When a `we-select` has no elements, it is drawn as a flat line.

This commit puts a "/" in its toggler content. This character is the
same one as the one that is displayed if the selected value is not one
of the available values.

Steps to reproduce:
- Delete all `website.snippet.filter`
- In debug mode, drop a "Dynamic Snippet" in a website page
- Select it
=> The "Filter" option was displayed as a flat line.

opw-3166634

closes odoo/odoo#112117

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

Steps to reproduce:
In Working Times, click on "SWITCH TO 2 WEEKS CALENDAR"
for the default calendar used by the company.

Issue:
A ValidationError appears: 'Attendances can't overlap.'

Cause:
To create a two-week schedule, by default,
we will use attendances provided for the company's default schedule.

When we want to switch from a one-week schedule to a two-week schedule,
we first delete the attendances from the schedule to be modified.
However, if this schedule is the company's default schedule,
it will no longer have the default attendances
that we must use to build the two-week schedule.

So we end up with the two "fictitious" attendances
that are used to delimit the two weeks.

With only these two attendances, the constraint of not having
two overlapping attendances is not respected
(because the two attendances created will be modified
to belong to the same week).

Solution:
Check that the calendar to be modified
is not the default calendar used by the company.

opw-3127337

closes odoo/odoo#111559

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

In case of the user have no access to all account.move, the hash result can be wrong.

Before this PR a user with limited access can print this report.

closes odoo/odoo#111185

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

Currently, the name's fields to send to Authorize when the partner is a company are:

* firstName
* lastName

if we consider following name `Company Duck Inc`:

the code is sending:

* firstName: ''
* lastName: 'Duck'

Only it sends the `lastName` with the second word found in the name,
due to the new validations in Authorize.Net, this kind of transactions
are marked as suspicious and it's not confirming the transactions, leave them
as pending, this commit is sending the full name in `lastName`
instead of only second word to meet with the validation in Authorize.Net

Also, we are sending the fields `firstName` and  `lastName`, with the
maximum length allowed by Authorize.

closes odoo/odoo#112363

Signed-off-by: Morgane Demesmaeker <edm@odoo.com>