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>

Json request was not availalble since it's not a json rpc request from Odoo
but a request from Stripe

opw:2449738

closes odoo/odoo#73975

Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>

closes odoo/odoo#73861

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

Steps to reproduce:

  - Install "Sales" module (for test purpose)
  - Active `External Email Servers` email feature and set an alias
  - Go to any Sale Team, and set an Email Alias
  - Send an email (from outside Odoo) to the sale team email alias
    - Write the body text in hebrew
    - !must ensure that the mail is encoded in iso-8859-8-i.
  - Go to Settings -> Technical -> Messages and open the receveid mail

Issue:

  Hebrew character are replaced by `�`.

Cause:

  Python does not have -e and -i codecs.
  More info here: https://bugs.python.org/issue18624



Solution:

  Create an alias for iso-8859-8-i == iso-8859-8.

opw-2482579

closes odoo/odoo#73893

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

closes odoo/odoo#67917

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

Description of the issue/feature this PR addresses:
When trying to create a journal item from a new entry in analytic accounts -> cost & revenues, a traceback was issued because there is no account.move linked to it.

Desired behavior after PR is merged:
The user is no longer able to create Journal Items from the form view in Analytic Accounts -> Cost & Revenues.

OPW: 2517311

--
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

closes odoo/odoo#72846

Signed-off-by: Quentin De Paoli (qdp) <qdp@openerp.com>

When we create a contract information on a vehicle, there is an activation cost
automatically created. Before this fix, if we delete the activation cost line, it
deletes automatically the associated contract. We should prevent this and add a
warning message instead.

To make it easier for the user, we should also show the contract information on
the list and form views of the vehicule cost.

When deleting the vehicle contract, we should also automatically delete the
activation cost line associated.

closes odoo/odoo#72269

Signed-off-by: Alex Tuyls <alt-odoo@users.noreply.github.com>

When creating a vehicle contract, we are creating automatically a cost line
corresponding to the activation costs. The contract was not correctly set
on that line before this commit.

When creating the recurring costs through the cron task, we should set the date
accordingly with the specified recurrence instead of setting it to today.

When using the Add button on the calendar view introduced with
odoo/odoo#64948 the event would not be linked with the applicant.

After further investigation the method used to get the applicant id in
default_get was not flexible enough, the one from crm calendar has been
'copied'

Task ID: 2578165

closes odoo/odoo#72731

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

When setting the request_date_from and request_date_to when creating a
leave that will be used to show the range of days of the leaves, we are
using the current user timezone to determine it.

eg. in UTC+2 if the leave begins at midnight on the 6th, we will see 6
and not 5 which is the day in UTC.

When creating a leave in a mode different than employee, when it is
confirmed and a leave is created for each employee, we would use the UTC
day instead which is a little unexpected.

Without the fix, the added test fails with:

    AssertionError: datetime.date(2019, 5, 5) !=
    datetime.date(2019, 5, 6) : Timezone should be kept between company
    and employee leave

opw-2573730

closes odoo/odoo#73073

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

To replicate:
- Enable a payment acquirer that uses a token
- Create an invoice, fill payment reference and confirm it
- Generate a payment link, using the action available at the invoice
- Use the generated link and pay the invoice

Before this commit, even though the transaction is processed, its not
associated to the invoice being paid. This also causes the invoice to
remain as not paid.

After this commit, the transaction is associated to the invoice and
it's paid.

closes odoo/odoo#73511

Signed-off-by: Antoine Vandevenne (anv) <AntoineVDV@users.noreply.github.com>

The naive implementation of read_progress_bar() does not deal properly
with groupings like `date:week`.  The values in the groups are returned
under the wrong key ('date' instead of 'date:week').

closes odoo/odoo#73477

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

closes odoo/odoo#73481

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

This commit fixes the performance issue in getting statistics for
``activity_state`` (colored clock icon for overdue/today/planned) in
CRM.  The query has been tested for several years on a large database
(Odoo's own production database).

Performance test on 29 K crm.lead records (activity_state):

With a filter for 10 records:

```
| measurement        | before | after |
|--------------------+--------+-------|
| number of queries  |     25 |     5 |
| query time, ms     |     12 |    95 | (*)
| remaining time, ms |     32 |     7 |
```

All records:

```
| measurement        | before | after |
|--------------------+--------+-------|
| number of queries  |   1326 |     5 |
| query time, ms     |   1739 |   129 |
| remaining time, ms |  47934 |    17 |
```

As we can see in the last results, the time went from almost 50 seconds
(not responsive at all) to 150 milliseconds (responsive).  The time
increase in (*) may be caused by imperfect measurements, which are raw
and not averaged measures.

---

opw-2346901
task-1915411

closes odoo/odoo#67004

Signed-off-by: Raphael Collet (rco) <rco@openerp.com>
Co-authored-by: Nicolas Seinlet <nse@odoo.com>

The method is used to get progress per column in kanban view
(green-yellow-red-red lines in Project, CRM etc).  There are two main
usages:

1. get statistics for ``kanban_state`` (red/green circles)
2. get statistics for ``activity_state`` (colored clock icon for overdue/today/planned)

Before this commit all cases were handled by calling search_read and then
counting records per group in a python script.  This is very inefficient,
especially for ``activity_state``.

This new implementation relies on ``read_group`` when possible, i.e.,
when both grouping fields (kanban column and progressbar field) are
stored (case 1).  It then falls back on a naive implementation inside
``_read_progress_bar``.  Cases like 2 above can be addressed by
overriding ``_read_progress_bar``.

We also added some minimal test to ensure that we don't break anything.

1. Performance test on 60 K project.task records (kanban_state):

With a filter for 6 records:

```
| measurement        | before | after |
|--------------------+--------+-------|
| number of queries  |      8 |     5 |
| query time, ms     |     11 |     7 |
| remaining time, ms |     21 |     9 |
```

All records:
```
| measurement        | before | after |
|--------------------+--------+-------|
| number of queries  |     67 |     5 |
| query time, ms     |    300 |    55 |
| remaining time, ms |   1780 |    12 |
```

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

---

opw-2346901
task-1915411

Suppose the option "Lock Confirmed Sales" enabled and a product with the
invoicing policy set to "Delivered quantities". When cancelling the
delivery of such a product, the invoice status of the associated SO
should be 'Nothing to Invoice'

To reproduce the error:
1. In Settings, enable "Lock Confirmed Sales"
2. Create a product P:
    - Type: Consumable
    - Invoicing policy: Delivered quantities
3. Create a SO with one P
4. Confirm the SO
5. Cancel the SO's delivery
6. Check the invoice status (`invoice_status`)
    - 12.0: Either by modifying the view, or by adding the field with
studio or directly via PSQL
    - 13.0+: The field can be enabled thanks to the options of the tree
view

Error: The invoice status is "Fully Invoiced" but the product hasn't be
delivered and no invoice has been created

OPW-2464343

closes odoo/odoo#73310

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