We fix 2 related UoM issues:

1. Fix quant inconsistency from changing the UoM of Done
   stock.move.lines

Steps to reproduce:
- Enable "Storage Locations" setting
- Create a new "Storable Product" and create a receipt for 1 unit of it
- Validate the 1 unit receieved
- Open "Detailed Operations" of the move and change the stock.move.line
  UoM to dozen.

Expected result: 13 on hand
Actual result: 1 on hand

To fix this:
- prevent users from editing the UoM after the picking is
  done (i.e. unless adding a new stock.move.line and not saving).
- update the write on done logic so stock.move.line UoM changes are
  considering and will update the quant correctly (in case of RPC or
  direct write).

2. Prevent changing UoM of Done stock.move to prevent inconsistent field
values within stock.move and confusion for users

Steps to reproduce:
- Complete a picking (incoming is easiest to see) with a new product
  (i.e. 0 qty) having 1 unit done.
- Unlock picking and add a new stock.move with 1 unit done and save.
- Edit the just added stock.move's UoM from Units to Dozen.
- Check the quantity on hand / Done qty of stock.move after leaving and
  returning to form.

Expected result: 13 On Hand
Actual Result: 2 On Hand and the "Done" qty in the picking is 0.0083
  (i.e. 1/12 of a dozen)

To fix this:
- prevent users from editing the UoM after the picking is done (unless
  adding a new stock.move and not saving)
- if a Done stock.move UoM is uodated, a UserError occurs because there
  is no straightforward way to ensure the quant is updated correctly
  since is handled within the move.line (i.e. has no visibility to its
  move's uom change => changing only UoM and not qty done will result in
  no quant update)

closes odoo/odoo#75621

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

The `update_db_index` method is called even if the field has no index
(the check on `index` field attribute is here on purpose).

Before 13f02a60 was applied, the call of `sql.drop_index` was taking
care of the index existence if a `IF EXISTS` SQL statement, so even if
the field had no index it wasn't causing any issue.

With 13f02a60 applied, the log 'Keep unexpected index' is spam even if
the field has actually no index at all in the database.

This commit ensures to check the existence of the index before logging.

closes odoo/odoo#75387

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

After 0411dda6
the associated test fail in certain time frame due to the datetime check

closes odoo/odoo#75624

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

This commit fixes a behavior when we send a batch of mailings
with no recipients.
When there is no recipients passed down, each mailing should
use it's own recipients and not the recipients of the first mailing.

closes odoo/odoo#75389

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

closes odoo/odoo#75390

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

A stock move with 0 qty in initial demand is considered as 'ready'. But
those stock moves should be excluded of the picking state computation to
not false the readiness of the picking, especially if the delivery
policy is set to 'direct'.

opw-2611018

closes odoo/odoo#75194

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

This commit backports the mobile OS detection support, and specifically
Android & iOS one to allow more specific targeting of edge cases (i.e.
disabling native date picker in the mobile iOS app only).

opw-2613810

closes odoo/odoo#75455

Related: odoo/enterprise#20402
Signed-off-by: Adrien Dieudonné (adr) <adr@odoo.com>

New optional 'ttl' parameter for the authorize function. It will allow to specify how much time the credits will be reserved.

closes odoo/odoo#69113

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

- Create a sale order that generates picking and confirm it.
- Validate the picking  when the local DATE and the GMT DATE
are different (i.e. GMT-4, between local 20:00:00 and 23:59:59)

Effective Date will be different in the SO and the picking

opw-2559308

closes odoo/odoo#75170

Signed-off-by: agr-odoo <agr-odoo@users.noreply.github.com>

When an index has name 'tablename_fieldname_index', this index is
dropped if the field has index=False.  This lead to dropping a
user-created index or dropping/recreating the index when index=True is
set in a dependent module.  Some info is logged instead.

closes odoo/odoo#66700

closes odoo/odoo#71761

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>

With this commit, it will check if the tax name is given by external method and take that name if any.

For example,
vals = {'rate': 5.2, 'name': 'Odoo New Tax'}
tax_template = self.env['account.tax'].search(domain, limit=1)
new_tax = tax_template.copy(default=vals)

Current Behavior:
new_tax.name => 'Odoo New Tax (Copy)'

Instead of 'Odoo New tax'

closes odoo/odoo#74722

Signed-off-by: oco-odoo <oco-odoo@users.noreply.github.com>

When creating a new task the name field was not automatically focused.

closes odoo/odoo#75024

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

There's two ways Odoo can get job responses from Gengo: the first is
this callback, initiated by Gengo. The second is a cronjob ran by Odoo
which retrieves translated terms. The callback resulted in a traceback
in the logs, because there was a typo in 'base.gengo.translations' (it
was missing an -s at the end). `json.loads` was also being called with
an unexpected extra parameter ('utf-8'), resulting in another traceback.

This PR fixes both of those and I was able to confirm the callback was
able to update translations in Odoo as a result.

closes odoo/odoo#75230

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

task- 2486484

closes odoo/odoo#74484

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

Steps to reproduce the problem:
- Connect as admin
- Create a new employee, e.g: “Employee1” for company “My Company (San Francisco)”
- Create a new time off request for this employee, and select a time off type linked to the company "San Francisco"
- create a user and do not give him access to the company “San Francisco”, e.g: “user1”
- Log in as “user1”
- Go to time off > Managers > Allocations > remove default filter

Problem:
user1 is able to see the time off allocation of “Employee1”, even though he does not have access to My Company San Francisco.

Solution:
Add multi-company rules  for the “hr.leave_allocation” model to display only the time off allocations to which the current user has access

A rule has already been added for "hr.leave" model:
https://github.com/odoo/odoo/blob/0f3281e3b1dc943b81d79d2a8f82fca7b95b8186/addons/hr_holidays/security/hr_holidays_security.xml#L65-L70



opw-2535709

closes odoo/odoo#74934

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

In 12.0+ when adding an XI (Northern Ireland) VAT number on a vendor and specifying the country as United Kingdom, an error shows the VAT number as not valid. This is because the method to check specifically XI VAT numbers doesn't recognize XI as a country, and thus uses the GB VAT number verification, which doesn't recognize XI VAT numbers as it isn't up to date yet.

A temporary method to check XI VAT number was already added, but is never called because XI is not recognized as a country code.
With this commit, we add a list of known legitimate country codes, that are not considered as such in Odoo.

opw-2534541

closes odoo/odoo#72910

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

closes odoo/odoo#74978

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

Steps to reproduce:

- create a sale order with an event registration,
- on the event, the number of attendees is well computed
- cancel the sale order
- on the event, the number of attendees is still the same as before

Cause of the issue

There was no specific action for canceling a sale order linked
to an event registration

Solution

Add a action_cancel method which cancel also the sale order lines when
canceling the sale order

Also add a test to ensure the flow will not break in the future

opw-2576790

closes odoo/odoo#74481

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

Bug
===
1. Login as "Portal"
2. Go to "/my/opportunity"
3. Create an opportunity
4. Edit this opportunity from the frontend and set the probability empty
=> Save, an error is raised

Technical
=========
The probability is set to "None" and not to "False", therefor the
verification "probability >= 100" in the write method of the lead will
raise an error.

By using False instead of None, this verification will work.

Task-2613208

closes odoo/odoo#74790

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

In new version of chrome (92) or firefox when some fonts (eg. courier)
were used:

- either the page would never finish loading (odoo 13 and below)
- or the text would in this font would not be shown (odoo 14 and over)

This was solved in pdf.js whith this commit:

https://github.com/mozilla/pdf.js/commit/8805614a03



And this PR is backporting that commit in 12.0 version up to master.

opw-2621405 opw-2613412 opw-2620186 opw-2618225 opw-2616690 opw-2615502
opw-2616249 opw-2615144 opw-2613969 opw-2613793 opw-2618129 opw-2617736
opw-2622506 opw-2614508 opw-2620883 opw-2622105 opw-2620863 opw-2615326
opw-2622842 opw-2620220 opw-2622842 opw-2620220 opw-2615346 opw-2615026
opw-2618389 opw-2619382 opw-2613286 opw-2621730 opw-2613412 opw-2622029
opw-2620625 opw-2622311

closes #75020

Signed-off-by: Nicolas Lempereur (nle) <nle@odoo.com>

Steps to reproduce:

  - Install Inventory and Studio modules
  - Go to Inventory -> Products -> Products
  - Open Studio
  - Click on Reports tab
  - Select `Product Routes Report`

Issue:

  Traceback is raised.

Cause:

  No 'product_id' provided in data while getting report values.

Solution:

  If no `product_id` key or value in data, set `docids` (or an empty
  list if no docids) as product_id and set 'warehouse_ids'
  to an empty list.

opw-2619142

closes odoo/odoo#74860

Signed-off-by: William Henrotin <Whenrow@users.noreply.github.com>

Before this commit:
No "image" metadata was available for products on the ecommerce main page (/shop). As such search engines SEO will be less effective.
In the case of the client, using "Google Search Console" would give the message: `Missing field 'image'` as a "Top Warning"

Note:
This issue was introduced by:
https://github.com/odoo/odoo/pull/30656
and was partially solved by:
https://github.com/odoo/odoo/pull/37870/commits/c66892e65d2ae0ca31a686f65d4b517a9d7ffd0b



OPW-2509546

closes odoo/odoo#74880

Signed-off-by: Jérémy Kersten (jke) <jke@openerp.com>

No need to keep it, it's useless and can confuse translators

closes odoo/odoo#74779

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

With the commit some time ago #d3822883, I removed to take the first,
but you can have multiple transfer accounts in one company.

The best way is to just do a limit=1

closes odoo/odoo#44592

closes odoo/odoo#74072

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

Properly set the transfer account in the company taking account the accounts defined in th company domain.  We found this error because in l10n_ar module we have 3 chart of accounts based on the company AFIP responsability which actually have same transfer_account_code_prefix. For that reason it was setting a transfer account to the company which is not belongs to the current company.

closes odoo/odoo#44506

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

Suppose such a SO line:
- Unit Price: 541.26
- Qty: 38
- Discount: 2%

The line amount is computed thanks to application of the discount on the
price, then the multiplication of the result with the quantity. The
rounding eventually happens after these steps:
https://github.com/odoo/odoo/blob/254b2a0840d3e817cc6062c483b5213c10088af5/addons/sale/models/sale.py#L1013-L1024
https://github.com/odoo/odoo/blob/b76e9ef658bde0178fa1660b6ad27b880e91632a/addons/account/models/account.py#L1138


Therefore, in the above case, we have:
```
Total = round(541.26 * 0.98 * 38)
      = round(530.4348 * 38)
      = round(20156.5224)
      = 20156.5224
```

However, when confirming the SO and setting the delivered quantity, the
Untaxed Amount To Invoice is computed using the unit price with both the
discount and the rounding already applied:
```
Total = round(541.26 * 0.98) * 38
      = round(530.4348) * 38
      = 530.43 * 38
      = 20156.34
```
As a result, the amount is not the same than the first one, this is
incorrect.

OPW-2525975

closes odoo/odoo#74362

Signed-off-by: Adrien Widart <adwid@users.noreply.github.com>

Issue: When making a return for a transfer, the precision_rounding was taken from the UoM of the product given in the transfer, but the quantity was taken in the UoM of the product defined on its form

Steps to reproduce :
 1) Create a UoM "Hundreds", rounding precision 1 (has to be different than "Dozen"), Bigger than the reference Unit of Measure, ratio 100
 2) Create a test product with "Dozen" as UoM
 3) Inventory > Operations > Transfers > Create
 4) Add test product, Demand=2, Unit of Measure=Hundreds
 5) Validate
 6) Create a Return for that transfer
 7) Quantity is set to 17 Dozen instead of 16.67

 Why is that a bug:
 The quantity to return is `quantity = stock_move.product_qty` (in UoM of the product form) but the rounding is made with rounding precision `stock_move.product_uom.rounding` (in UoM of the line of the transfer) which can be different in case of manual transfer creation for example

opw-2543304

closes odoo/odoo#74435

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

closes odoo/odoo#72646

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

Manual backport of odoo/odoo@4504c9d8069082c9542226fbafdbf309089cf7a9 done in 13

Steps to reproduce :

  - Install `CRM` and `Sales` modules
  - Go to Settings, activate "External Email Servers" and
    set an alias.
  - Edit 'Sales Team Europe' : add an alias
    (ensure alias end with the "External Email Servers" alias)
  - Send a mail to the europe sale team alias email with a
    base64 image in the html body
    ex: <img alt="" src="data:image/png;base64,ABCDE123....789">

Issue :

  - Traceback is raised.
  ("ValueError: Wrong value for ir.attachment.type: 'opportunity'.")

Cause :

  Both `crm.lead` and `ir.attachment` have a `type` field.

  When creating the thread, in this case of crm.lead model,
  it will add the 'default_type' and 'default_team_id' to the
  context.

  The context will be inhrited and used on the creation of the
  ir.attachment (in this case its the base64 encoded image
  inside the body).

  Since no `type` was provided while creating the ir.attachment,
  it will set the type from `default_type` in context since
  available.

Solution :

- Clean the context (in this case, it will remove `default_X` values)
  when creating the ir.attachment .

opw-2551461

closes odoo/odoo#74374

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

Purpose of this commit is to highlight an issue that may happens easily with
`crm` that is made generic here within `test_mail`.

`crm` alters the context when creating a new record adding in this case
`default_type` to it][1]. The returned record contains that altered context.
his results in other records created from it trying to assign that same default
value for `type`. This is a very common name for fields, and happens to exist
in `ir.attachment` too.

If you create an alias for incoming leads in your DB with default values
`{"type": "lead"}` (something very common) and then an email comes to that
alias that contains an inlined base64 image, the attachment creation process
would simply fail.

Obtained error is ``ValueError: Wrong value for ir.attachment.type: 'lead'`` .

[1]: https://github.com/odoo/odoo/blob/272602193f5647f7f2270ed6ec68777625a139dd/addons/crm/models/crm_lead.py#L310-L311



Co-Authored-By: Thibault Delavallee <tde@odoo.com>

Step to reproduce:

- go to sale app
- select several SO
- action menu > delete
- got a traceback

Change the unlink definition to get multiple elements with mapped.
This fix an issue introduced on PR 72253

opw-2605699

closes odoo/odoo#73942

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

Usecase:
- Product A 10 units in stock
- Do a planned transfer of 7 units to customer
- Reserve
- Do an rpc or execute code to call copy on the stock.move.line

It will result with 2 sml that have 14 units reserve and 7 units
reserved on stock.quant

It's the same result if you create twice the stock.move.line without
updating the stock.quant at the same time. However in stable we
try to only use _update_reserved_quantity on stock.move or some
override in create/write method for 'done' stock.move.line in unlock
cases.

So we never use the copy in stable and define the basic behavior as
'we don't copy the reservation' could prevent some usecase where
the update on the stock.quant is forgotten after.

closes odoo/odoo#73870

Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

On Chrome, the browser displayed an horizontal scrollbar because the
sr-only item inside the 'next' arrow was positioned absolutely, outside
of the arrow, and thus outside of the window. This happened for the
website carousel snippet when added in pages for instance.

opw-2585526

closes odoo/odoo#73641

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

Backport of b6ced2e13e328539b086067a836d1e0fba3990b7

opw-2517635

closes odoo/odoo#73320

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