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>

See commit https://github.com/odoo/odoo/commit/f7800a059a1e8ed52cf7ddfa81ab5df6867b78da


for details about this fix

OPW-2368473

closes odoo/odoo#73378

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

Steps to reproduce the bug:
- Install manufacturing app
- Create a product “A”
- Create a Bill of Materials for product A > add any product > save
- Create another Product “B” > Create a BOM and add the product “A” in quantity “0” > save
- Click on “BOM Structure & Cost” for product “B” > open the sublevel BOM dropdown of the product “A”

Problem:
An error is triggered because the quantity of the product is "None"

opw-2585033

closes odoo/odoo#73233

Signed-off-by: Anh Thao PHAM <kitan191@users.noreply.github.com>

Steps to reproduce:

  - Create a new pricelist;
  - In the Price Computation, select "Formula" then
    change it to "Based on Cost";
  - Change the price computation back to "Percentage (discount);
  - Create a sale and set this new pricelist.

Issue:

  Price discount made on the cost of the product instead to get back
  to sale price as default

Cause:

  When switching `Compute Price` and != 'formula', not setting back
  `Based on` (base) to `Public Price` (list_price).

Solution:

  If compute_price is changed and new value != 'formula'; set
  pricelist `Based on` to `Public Price`.

opw-2587295

closes odoo/odoo#73220

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

before this commit: when deleting or archiving or unarchive all records of last
page in listview user is displayed with NoContentHelper while we still have
other records in previous page, user should be moved to previous page if all
records of last page are deleted.

after this commit: if user deletes or archives or unarchives all records of
last page in list view then user is moved to previous page.

task-2446911

closes odoo/odoo#66523

Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>

Scenario to reproduce the issue on runbot 12.0 Community:
- Go to Settings > Technical > Email > Digest Emails
- Select the Weekly Digest
- Click on Action > Delete
- Click on OK
- Go to Settings > Users & Companies > Users
- Click on Create
- Fill the Name and the Email Address
- Save
- Odoo Server Error - Missing Record

Some users seem to delete this record to stop receiving the digest for
everyone, including for future users.  The problem is that, even if the
digest has been deleted, the config parameters are still referencing it.

This commit prevents the exception by having an empty recordset if the
digest does not exist.

closes odoo/odoo#73077

Signed-off-by: Paul Morelle <madprog@users.noreply.github.com>

When deleting a SO with an event ticket, the number of attendees becomes
incorrect

To reproduce the error:
1. In Settings, enable "Tickets"
2. On website, register an attendee to event E
3. In module Events, open E

Error: The number of attendees (X) is incorrect. If the user clicks on
it, there are X-1 attendees: the one added on step 2 has been deleted
but the number is not updated

When deleting a SO or a SO line, the associated registration is deleted:
https://github.com/odoo/odoo/blob/3fd3fc5f782f1422f578ad38e3fad444130273a8/addons/event_sale/models/event.py#L197-L198
This is the problem: it won't trigger the `compute` methods.

In the case above, this method won't be called:
https://github.com/odoo/odoo/blob/72ce1b867dc81672e6a73a586542b20216388a05/addons/event/models/event.py#L176


So the number of seats won't be updated

This fix suggests deleting the registrations from the ORM in order to
trigger the `compute` methods.

Note: Writing the tests revealed another problem. When deleting the SO,
if a wizard `registration.editor` exists and is linked to the SO, the
deletion will trigger an SQL constraint. This is the reason why the
`ondelete` has been added to the field `sale_order_id`

OPW-2452760

closes odoo/odoo#72253

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

See odoo/odoo#71047

closes odoo/odoo#72221

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

syncing calendar for a single user may take few minutes, which could easily lead
to cron timeout. To avoid starting the syncronization over and over again, we
should commit updates that are already done.

The module already has many commit() calls, but those are not always used and
hence we need to add a new one.

---

opw-2577018

closes odoo/odoo#73054

Signed-off-by: Ivan Yelizariev // IEL <yelizariev@users.noreply.github.com>

This commit is a fixup to the earlier commits that backport CPython's
3.8 classCleanups, due to the fact that the official supported python
version for Odoo V12 is CPython 3.5, where f-strings are not available.

This one slipped through due to the fact that v12 runbot does not
actually run under Python 3.5 but 3.6+

closes odoo/odoo#73074

Signed-off-by: Adrian Torres (adt) <adt@odoo.com>

Sort of but not really, this commit fixes a special case in which
launching a --test-file of a file with at least two SavepointCases would
create a postgresql deadlock and it would be impossible to terminate the
Odoo process without sending a SIGKILL or waiting for the lock to
timeout.

This was introduced at #39368 and happens because of the way that
unittests unwraps suites, to keep it short, when it unwraps the custom
OdooSuite class internally, it ends up with a vanilla TestSuite with
which to run the different test cases, and since #39368 depends on the
overrides added to OdooSuite to function, the class cleanups are not
triggered at the end of a test class (rollback, cache cleanups, env
reset, registry reset, etc.).

The fix is to manually unwrap the suite of tests to keep OdooSuite as
the suite with which to call the tests, which was already done for
--test-enable (although for different reasons, --test-tags?) which is
why --test-enable didn't have any problems.

This commit also fixes a typo I found on the backport, which meant
classCleanups were not being executed if the setUpClass failed, but it
had no effect on classCleanups during tearDownClass.

Task-ID 2160398
Depends on #43135

closes odoo/odoo#73044

Signed-off-by: Adrian Torres (adt) <adt@odoo.com>

This commit takes advantages of the features added in the parent commit
to have better/cleaner tests.

This commit partially backports bpo-24412, which allows the definition of
class cleanups (addClassCleanup) and module cleanups (omitted),
similar to instance cleanups (addCleanup).

This is useful for tests that override unittest's setUpClass and
could crash during its execution: If this happens, it is possible that a
bunch of crap is left in the database or even worse, the cursor becomes
completely fucked; Thanks to the addClassCleanup, we can undo the damage
done by the setUpClass.

Another benefit is that it is called unconditionally after tearDownClass
is called, so it can also be called as a replacement and/or safer
tearDownClass.

PURPOSE

The week dates computed by our datepicker do not meet the ISO 8601 standard:

The ISO 8601 definition for week 01 is the week with the first Thursday of the
Gregorian year (i.e. of January) in it.
The following definitions based on properties of this week are mutually
equivalent, since the ISO week starts with Monday:
- It is the first week with a majority (4 or more) of its days in January.
- Its first day is the Monday nearest to 1 January.
- It has 4 January in it. Hence the earliest possible first week extends from
Monday 29 December (previous Gregorian year) to Sunday 4 January, the latest
possible first week extends from Monday 4 January to Sunday 10 January.
- It has the year's first working day in it, if Saturdays, Sundays and 1
January are not working days.

If 1 January is on a Monday, Tuesday, Wednesday or Thursday, it is in W01. If
it is on a Friday, it is part of W53 of the previous year. If it is on a
Saturday, it is part of the last week of the previous year which is numbered
W52 in a common year and W53 in a leap year. If it is on a Sunday, it is part
of W52 of the previous year.
https://en.wikipedia.org/wiki/ISO_week_date#First_week



Since Jan 1st 2021 falls on a Friday, according to the ISO 8601 standard above,
the first week of 2021 is the one starting on Jan 4th.
Nevertheless, it looks like our datepicker simply assumes that the first week
of the year is simply the one including Jan 1st.

SPECIFICATION

Fix the week dates of our datepicker to meet the ISO 8601 standard.

Task - 2458112

closes odoo/odoo#70473

Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>
Co-authored-by: Mohammed Shekha <msh@odoo.com>

- Create a Storable Product tracked by Lot (i.e. Product X)
- Update its quantity and set a lot (i.e. Lot001)
- Create SO with Product X and deliver it
- Create an Internal User with the following rights:
  * Inventory: User
  * Sales: User: Own Documents Only
- Connect with created user
- Go to Inventory > Master Data > Lot/Serial Numbers
- Open Lot001 of Product X
An Access Error is triggered because SO cannot be computed on the lot.
There is no issue if no right is given for Sales.

opw-2486758

closes odoo/odoo#70595

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

Move the odoo server parameters into the odoo.conf file
instead of being placed as the service command line argument

closes odoo/odoo#72904

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

Description of the issue/feature this PR addresses:
When trying to crop pictograms, a traceback was issued because they are icons, not images.

Current behavior before PR:
The user was able to invoke the cropping action on pictograms and received an internal error.

Desired behavior after PR is merged:
The user now receives an error message stating that pictograms cannot be cropped and no traceback.

OPW: 2497084

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

closes odoo/odoo#70142

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

Before this commit, you can provide arbitrary url for redirect.
Now, we always return a relative url, since this method should be only called
from a page on your current website, their are no reason to let redirect to
another domain.

closes odoo/odoo#72848

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

Before this commit: when we hovering badge of many2many field, the cursor is
pointer while clicking on badge does nothing so cursor should be default.

After this commit: when we hovering badge of many2many field(without color
field), the cursor is default.

closes odoo/odoo#69905

Task: 2515190
Signed-off-by: Simon Genin (ges@odoo) <ges@odoo.com>

This code can't be reached, the condition can't be true anymore, as
`partner_shipping_id` is a required field.

closes odoo/odoo#65629

Signed-off-by: Romain Derie <rdeodoo@users.noreply.github.com>

Backport odoo/odoo#35878, adding an explicit mapped
because Relational.__get__ introduced in 13.0.

closes odoo/odoo#72469

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

closes odoo/odoo#72281

Signed-off-by: Lucas Perais (lpe) <lpe@odoo.com>

This could save some time when `_compute_quantity` is used thousands times in
request and there are thousands UOMs in the system

* if qty is zero, then result is zero
* if to_unit is the same, then result is `round((qty / factor) * factor) = round(qty)`

---

opw-2549026

closes odoo/odoo#72433

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

Steps to reproduce the bug:

- Go to settings > create a new company :
	- Choose the country : `Mexico`
	- fill in the VAT field : ESA2005273X1
	- save
- Validation error is triggered

Problem:

The Mexican VAT can be on the format: "MXESA2005273X1" or "ESA2005273X1".
But only the "MX .." format is accepted for the moment,
and it fails in the case of "ES.." because the function checks if it is a valid Espganol VAT number.

In the case of failure, we use the `partner.commercial_partner_id.country_id` to get the country code.
The problem is when creating the res.company, we also create a res.partner
with a few fields within `VAT` except `country_id` field
while we use it in the `check_vat` function : https://github.com/odoo/odoo/blob/7a7aacedde81998ec0f1a7f3283337236e56de42/addons/base_vat/models/res_partner.py#L167



Opw-2573557

closes odoo/odoo#72451

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

    In order to ensure consistent results of all error conditions returned
    by the LDAP server, the _authenticate() method should return `False`
    for every kind of exception, not just for INVALID_CREDENTIALS.

    This is not actually relevant in 12.0 as the result is exactly the
    same, due to the way the `entry` variable is being initialized, but it
    will make the code path "visibly consistent" across all supported
    versions

closes odoo/odoo#72348

Signed-off-by: Olivier Dony (odo) <odo@openerp.com>

When buying a product on website shop, after the payment with SIPS, the
page is redirected to an Error message: "We are not able to find your
payment, but don't worry. You should receive an email confirming your
payment in a few minutes. If the payment hasn't been confirmed you can
contact us."

To reproduce the error:
1. In Payment Acquirers, enable Sips
2. Go on website shop
3. Add a product to the cart, Checkout
4. Pay with Sips
    - Visa card number: 4100000000000000
5. Back to Web-shop, if the payment has been successfully processed,
repeat steps 2 -> 4

Error: The message "Your payment has been successfully processed. Thank
you!" is not displayed. Instead, the message "We are not able [...] you
can contact us." is displayed.

This message is displayed when:
https://github.com/odoo/odoo/blob/5945806c151b13d9d4cc13aa0a6c96a6b1bbad5f/addons/payment/controllers/portal.py#L65-L69
i.e., when the transactions list is empty. Here is how to get the list:
https://github.com/odoo/odoo/blob/5945806c151b13d9d4cc13aa0a6c96a6b1bbad5f/addons/payment/controllers/portal.py#L38-L42
It uses the session of the request. The cookie `session_id` is used to
identify the current session. However, after the payment on SIPS, the
page is redirected to `/payment/sips/dpn` with a POST request. Since the
session cookie has the attribute `SameSite=Lax` and the HTTP request is
a POST, the cookie will be filtered out:
https://drive.google.com/file/d/1xfx3YWkfonO3nK-8Rew45uSoR4lkpjpY/view?usp=sharing


(Browser information: This cookie didn't specify a "SameSite" attribute
when it was stored and was defaulted to "SameSite=Lax," and was blocked
because the request was made from a different site and was not initiated
by a top-level navigation. The cookie had to have been set with
"SameSite=None" to enable cross-site usage)
As a result, the server creates a new one. This is the reason why the
transactions list is empty: the list is based on a new session.

Adding the attribute `save_session = False` to the route will prevent
the server from creating a new session cookie and add it in the POST
response.

OPW-2518377

closes odoo/odoo#72267

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

Stripe is not sending JSONRPC but plain JSON;
 kwargs is empty, we need to use request.jsonrequest instead.

 Bug was introduced by a1ff4dc25534467e138cdb26f5b52df7dd33b79c

closes odoo/odoo#72332

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