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>

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>