Backport from 12.0 to 11.0 (commit: 3cbdfe88)

- Have two crm teams with the same team leader, and without team members
(team1, team2 as instance).
- Create a new lead, add as Salesperson the team leader, and as Sales
team the second previously created team (team2).
- Save the new lead.

Before this commit, when we save the lead, the sales team will change,
to set the default sales team for the chosen Salesperson, in this case
team1.

opw-2005924

closes odoo/odoo#33898

closes odoo/odoo#34327

Signed-off-by: Simon Goffin (sig) <sig@openerp.com>

[FIX] account: make cash basis taxes work in case several account move lines are reconciled within the same account.move

Such move lines can be created by POS, when closing a session. Because of commit https://github.com/odoo/odoo/commit/d3453f7d152d486cb5df01b4e40dbde57f59b49e

 , the cash basis entries are now created *after* reconciling everything (and not during reconciliation anymore). This causes multiple lines of the move created for the sessions to be reconciled together in case a refund was made (partial or not).

Solves ticket 2008085

closes odoo/odoo#34237

Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>

DROP CONSTRAINT (even with IF EXISTS is specified) acquires an ACCESS
EXCLUSIVE lock on the table, preventing e.g. inserts in an other
transaction, so ir_logging would systematically deadlock if configured
to the same database and a warning would be triggered during install
or update (if that ran ir.logging's init).

1. hand-roll the "IF EXISTS" bit, to avoid taking an ACCESS EXCLUSIVE
lock on the table if the problematic constraint does not exist and
thus doesn't need to be dropped (which by now should be the vast
majority of cases).

Replacing DROP CONSTRAINT with DISABLE TRIGGER does not fix the
issue as *that* acquires SHARE ROW EXCLUSIVE. While that's less
constraitning than ACCESS EXCLUSIVE, it still conflicts with an
insert's ROW_EXCLUSIVE.

2. add a timeout to the logging INSERT anyway, the deadlock is still
an issue if we're updating a database which does have the
problematic constraint, and we want to preclude the possible
eventual introduction of new deadlocks in the future.

closes odoo/odoo#34243

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

As a convention, JPY currency symbol normally shows before the amount.

closes odoo/odoo#34113

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

Stock.locations should be in no-update:
Limit the impact of recompute fields during the upgrade of stock module. (especially method _compute_product_availability)
Limit the impact on migration

Method _compute_product_availability is triggered during an upgrade of module and during migrations.
This may take a lot of time of big databases

closes odoo/odoo#34074

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

In the Discuss app, using Chrome or IE11, try to send the same
attachment to different channels. The first attachment is correctly
detected but not the next ones.

The problem is due to a browser inconsistency, on firefox selecting the
same file in an `<input type=file>` triggers the `change` event. This is
not the case on Chrome/IE, selecting the same file doesn't triggers an
`onchange`.

opw-2006647

closes odoo/odoo#34076

Signed-off-by: Alexandre Kühn (aku) <aku@odoo.com>

Installing test_new_api without demo will fail since demo_user
does not exists. This is a problem if we want to test migration
with all modules installed. This simple fix solve the problem.

closes odoo/odoo#34065

Signed-off-by: Christophe Simonis <chs@odoo.com>

Display extra information on error messages:
- Access error based on ACLs: user, fields (if applies)
- Access error based on record rules: user, ids
- Missing error: model, operation, user, ids

closes odoo/odoo#33942

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>


Co-authored-by: jev-odoo <jev@odoo.com>

1) Add a 1st product to compare from the ecommerce /shop page.
2) Open the compare list pop up at the bottom.
3) Add a 2nd product to compare from the /shop page.
4) Remove the 1st product from the compare list before the rpc of the
2nd product is done.
5) Javascript error `self.product_data[res] is undefined`

The function `add_new_products` and `rm_from_comparelist` are
concurrent, they both modify the internal `comparelist_product_ids`
product list. The first one perform an RPC and delay the update once the
request is done, the second does the update immediately.

The solution has been to use a mutex to exclude the two functions.

opw-1974108

closes odoo/odoo#33302

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

Try to get the report_pricelist with empty data
(Studio Report editor can)

Before this commit, it crashes because we tried to access dict keys directly
in an empty dict

After this commit, it doesn't crash

OPW 2009862

closes odoo/odoo#34118

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

Backport of fa39019e.
If crop_image is called without a default format, it would try the default,
'PNG', to save the result and crash at save when processing non-PNG images.
For example, if a jpeg image was in CMYK colors.

Here it will still crash non-gracefully when failing to save, but the default
should almost always work; if it doesn't it means we failed to detect the format
of the stream, so it is unlikely that we could save the image anyway.

opw 2009029

closes odoo/odoo#34088

Signed-off-by: Nans Lefebvre (len) <len@odoo.com>

On `WebRequest` `__exit__`, when an exception occured,
(in `self.registry.signal_changes` or `self.registry.reset_changes`)
cursor were left unclosed as `self._cr.close` was not called
in such cases.

Having exceptions in the above mentioned method do not happen
often, but when it does it left unclosed and unusable cursors
in the connection pool, and in the extreme case explained below,
it left the connection pool with only unclosed and unusable cursors.
The entire server was then unusable as it no longer had working cursors.

Case:
- Start a multi-thread server with db_maxconn set to 5
- Ensure you do not send any request to the server,
not even with a left open tab on `http://localhost:8069` in your browser
- Send 6 parallel HTTP requests to `/web/login`
thanks to an external thread python script
(See below, at the end of this long commit message)

According to your registry state (if you have a lot of modules installed or not),
and the native Python Garbage Collecting state,
you might end with
- either warnings telling some unclosed cursor were garbage collected,
and therefore closed (by a kind of luck thanks to the Python garbage collecting),
- either, a server completely blocked not accepting any other request
(you can try for instance `curl http://localhost:8069`
and you end up with a `500 Internal Server Error`

This observed issue looks to appear only in 11.0. Not 10.0 or 12.0.
This is because only 11.0 clear the cache during registry loading:
`https://github.com/odoo/odoo/blob/f1706c848d41c47646dabca771996e9b9f788241/odoo/modules/loading.py#L236`
This cache clearing doesn't happen in 10.0 nor 12.0
(in 12.0, thanks to e181f592)

When sending the 6 parallel requests,
it uses instantly all the 5 available cursors of the connection pool to handle these requests,
and when each request exits, in `__exit__`, it calls `self.registry.signal_changes()`
which tries to open a new cursor because of
- `self.cache_invalidated` which is True, for all the 6 requests, thanks to the call to `clear_caches`
explained above during the registry loading and the fact all requests have been treated in parallel,
- `with closing(self.cursor()) as cr:`, `self.cursor()` attempting to use a new cursor
(the `closing(...)` does not have any incidence on this issue, despite it could look like guilty)

The attempt to use a new cursor fails, as there is no more available (`db_maxconn` is reached),
raising a `PoolError('The Connection Pool Is Full')` exception.

In the request `__exit__` method, because of this exception raised when calling `signal_changes`,
`self._cr.close` is never reached, and the parallel request therefore left only unclosed
cursors in the connection pool,
therefore leaving the server in a state where it only has unusable cursors
and therefore can't do anything more.

This might look like really bad luck to land in such a state,
but we observed multiple actual case on Odoo.sh,
the one referenced in this commit (opw-2008340) was because of an Outlook client
which launched 18 parallel requests to fetch the email images,
and the server wasn't spawned, therefore neither was the registry.
The server registry was therefore just loaded when it received the 18 parallel requests,
and it therefore triggered this extreme use case.
The server was left unusable for several minutes, until a forced restart.

For reference, here is the script that has been used to trigger the 6 parallel requests:
```
import requests
import threading

threads = []
for i in range(6):
threads.append(threading.Thread(target=lambda: requests.get('http://localhost:8069/web/login'))

)
for thread in threads:
thread.start()

```

opw-2008340

closes odoo/odoo#34071

Signed-off-by: Denis Ledoux <beledouxdenis@users.noreply.github.com>

The field is now `quantity`. This wasn't spotted before because the
method is not used anywhere.

opw-2008491

closes odoo/odoo#34067

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Have a multi-company setup, with shared products.
Write the default code of a product; an access error is raised on inventory.line

On inventory.line, the field product_code is defined as related to
'product_id.default_code', and stored.
So when writing on the default_code of a product, we get the inventory lines of
other companies. For obvious reasons their access is protected by the record
rule "Inventory Line multi-company", therefore the access error is raised.

To avoid that situation stored related fields should be in compute_sudo.

Note that similarly this is necessary for product_name.
There is one more subtlety: directly writing on the product.product does trigger
the access error, but writing it on the product.template does not.

opw 2007167

closes odoo/odoo#34019

Signed-off-by: Nans Lefebvre (len) <len@odoo.com>

- Create a product A of type "Service", Invoice based on "Milestones",
Service Tracking "Create a task in a new project".
- Create a new SO with A, confirm.
- Go the to task associated to the SO, go to "Timesheets" tab, add an
entry
- In the SO, edit the delivered quantity
- Create invoice, validate

Back to the SO, delivered quantity is reset to 0.

We make sure to filter out SO lines which have a delivered quantity set
manually.

Introduced by d6ad2222.

opw-1982020

closes odoo/odoo#33991

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

Oversight of previous forward-port.

Before this task, when creating the related field from the studio, it is by
default stored. When we change the field name in 'ir.model.fields' using ORM's
write method, it also renames the column in the table associated with the
field's model.

This is the expected behavior. But when someone tries to change the 'name' of a
non stored field, the column is not available in the associated model, and so
trying to rename the column results into traceback. This issue was probably
there for a while but came into light with the task 1985710. More info can
be found on the chatter of the task.

This commit fixes the issue by adding an extra check before renaming the table
column. The query will be executed only when the field is stored and thus
exists in the table.

closes odoo/odoo#33944

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

Make SQL constraints errors more accurate.

closes odoo/odoo#33934

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

The content of these fields can't be updated, there's no reason to
even show them. Just remove them from the default / auto-generated
view for client actions.

Task 1772242

closes odoo/odoo#29179

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

For each asset depreciation lines we verify that there are not linked
to a move. This verification was done for each line separately.
Moreover, during the creation of the journal entries, we were writing
on the 'line_ids'. In this case, accessing the move of a line
was invalidating the cache. This fix ensure that this operation is
done out of the loop and the cache is then not invalidated at each
step.

See opw-2000305

closes odoo/odoo#33908

Signed-off-by: Nicolas Martinelli (nim) <nim@odoo.com>

closes odoo/odoo#33880

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

Since test_pylint was moved into the test_lint module in commit
b27077bb, this could break Odoo instances where a module has test_pylint in its dependency.

With this commit, the test_pylint module is coming back as an empty
module.

closes odoo/odoo#33871

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