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>

The license is missing in most enterprise manifest so
the decision was taken to make it explicit in all cases.
When not defined, a warning will be triggered starting from
14.0 when falling back on the default LGPL-3.

closes odoo/odoo#74146

Related: odoo/design-themes#39
Related: odoo/enterprise#19803
Signed-off-by: Olivier Dony (odo) <odo@openerp.com>

Steps to reproduce the bug:
- Go to Payroll app > Payslips > To Pay
- Choose any Payslip
- Go to the Accounting Information tab

Problem:
`”Made Payment Order ?”` field is always readonly when it should be clickable when the status is in draft or in verify
according to the rule defined in the python code. It doesn't make sense to always put it in readonly in xml
because it overrides the python rule : https://github.com/odoo/enterprise/blob/faf69b3de1d7fc955e3f6271fd24b901310fe5e4/hr_payroll/models/hr_payslip.py#L58-L59



opw-2608818

closes odoo/odoo#74176

Signed-off-by: Djamel Touati <DjamelTouati@users.noreply.github.com>

Issue:

  When creating a leave there is an error when you use by "employee tag"
  but it works when you use "by employee".

Solution:

  cherry-pick of:
  https://github.com/odoo/odoo/commit/394eedc1e4b6b9871b360d6ab168005c2731d3ff
  https://github.com/odoo/odoo/commit/c89c0e70da1e09c43eee8e76c7094dcc114c451b



opw-2525086

closes odoo/odoo#74170

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

Github codeowner is replaced with a runbot version of codeowners for
multiple reason:

- github codeowners is difficult to maintain, the precedence rule will
sometimes remove teams from some file because of a more specific rule
added by another team.

- github codeowner does not support version specific rules, especially
the "all except master" rule. For this use case teams needs to adapt
the new codeowner when freezing a new version.

- github will trigger codeowner on failed rebase, and add almost all
teams as reviewer. Runbot has specific commit and file limit to avoid
this problem.

- runbot codeowner is centralised and does not need to be managed cross
repo/version

- runbot codeowner works for enterprise

Any mofification on codeowner should be requested to runbot team.

closes odoo/odoo#74094

Signed-off-by: Xavier Dollé (xdo) <xdo@odoo.com>

The #for attribute of the LABEL tag should match the #id of the INPUT
tag, not it's #name.

This regression was introduced in a1716946

closes odoo/odoo#73107

Signed-off-by: Romain Tartière <romain@vittoriaconseil.com>
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>

Steps to reproduce the bug:
1: Invoice List -> Select few Invoices (With and Without Invoice Date filled in)
2: Action Confirm Draft Invoices

Bug: 
`TypeError: '<' not supported between instances of 'datetime.date' and 'bool'`

With this commit, we are using `fields.Date.context_today(self)` as default date if
`date_invoice` is not filled in.

Followup on  https://github.com/odoo/odoo/commit/6f319988ac15a366bcb370af870ec08cde75fb30


Fixes #73188

closes odoo/odoo#73529

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