### Steps to reproduce:

- Enable subcontracting in the settings
- Create a finished product FP tracked by lot using the buy route
- Create a component product CP tracked by unique serial numbers and using the routes:
	- Buy
	- Resupply Subcontractor on Order
- Create a BOM for FP of type subcontracting and consuming 1 x CP
- Create and confirm a purchase order for 2 x CP, assign serial numbers on the receipt, receive products and validate
- Create and confirm a purchase order for your subcontractor for 2 x FP
- Go to the resupply picking, assign the stock moves related to your components and validate
- Go to receipt

#### Two issues reported by the PO (mgm):

1) The subcontracting button is visible on the move even though no qty was delivered yet.
2) The `fa-list` button on the move redirects to stock move lines of the move rather than to the "action_show_details".

### Cause issue 1:

The `show_subcontracting_details_visible` computed field determine if the button should be visible. Prior to the `quantitypocalypse` this field relied on the `quantity_done` to determine if the button should appear:
https://github.com/odoo/odoo/blob/c68b17e944079f0718a1bef74b941dcb18b841e3/addons/mrp_subcontracting/models/stock_move.py#L30-L37
As this field does not exist in 17.0 anymore, the new condition relies on the `quantity` field:
https://github.com/odoo/odoo/blob/3dc2e25f30a411f49f895568b4689265152f153d/addons/mrp_subcontracting/models/stock_move.py#L30-L36
However, this field only represents the same thing as the quantity_done when the move is `picked`.

### Cause of issue 2:

The `fa-list` button referring to the `action_show_details` in 16.0:
https://github.com/odoo/odoo/blob/d1bdcde5160d1a320396f0703103a50e8636e96f/addons/stock/views/stock_picking_views.xml#L302-L303
(that is overriden in `mrp_subcontracting`) has been replaced in 17.0 on the `stock.picking` form view by the one2Many record stock.move widget:
https://github.com/odoo/odoo/blob/b4ae1ed7382dcb9c91c06ba0055974994dcdf54c/addons/stock/static/src/views/picking_form/stock_move_one2many.xml#L3-L8
see commit 4da8c6e for more details.

opw-3871634
---
I confirm I have signed the CLA and read the PR guidelines at [www.odoo.com/submit-pr](http://www.odoo.com/submit-pr)

Forward-Port-Of: odoo/odoo#165757

**Current behavior:**
In some instances we will try to create a `stock.location`
record from a `complete_name` field  value (one such case is
creating from import). When this happens, the creation will fail
due to the not-null constraint on the `name` field in the table
and display a SQL error in logs.

**Expected behavior:**
Use part of the complete_name as the name.

**Steps to reproduce:**
1. Create an .xlsx document representing a Repair Order to be
     imported, such that the `Location` cell value does not
     already exist in the database

2. Install the test-import-export module, go into the Repair app
     and from the favorites action button select import data

3. Upload the .xlsx file, press 'Test Import', select the
     'Create New' option for offending data points

4. Observe that the new Location can not be created, and in the
     console logs there is the output of the bad SQL query

**Cause of the issue:**
The `_rec_name` field for `stock.location` is `complete_name`,
however the `name` field as also a required field. When we
create the records in this flow, `_rec_name` is used to infer
which fields need to be included in the query. So `name` is
never added to the INSERT query and we end up violating the
not-null constraint on this column of the table (bad query).

**Fix:**
If there is no `name` in the create vals dict for the location
record, use the end segment of `complete_name`.

opw-3796010

Forward-Port-Of: odoo/odoo#166193
Forward-Port-Of: odoo/odoo#163298

This is re-targeting https://github.com/odoo/odoo/pull/162442 to 16.0

Motivation: MemoryError exceptions when a large number of records on the same model have dirty fields. Such often happens during upgrades.

In the current implementation, the cached data is re-arranged in multiple steps using local data structures. The most problematic is `id_vals[record.id][field.name]`, because it creates a dictionary with a potentially long field name (think studio fields) as key for each dirty record. For thousands of records, this quickly accumulates to 10s or even 100s of MiB in RAM.

The idea of this patch is:
1. collect all dirty ids for all dirty fields on the model. This does not cost additional memory, since the ist of ids per field will be pop()'ed from the cache.
2. Walk over fields and ids collecting all fields and values of each id in the same loop, carefully consuming objects, while directly building the `updates` dictionary, without creating the intermediate data structures.

This way, the _flush method only consumes a marginal amount of memory compared to the memory already consumed by the cache.

Careful profiling (using `memray` for memory profiling, the odoo profiler for runtime profiling) of a testcase that flushes 80k records in 8 writes has shown this new version to consume roughly 95% less memory while running slightly faster.

Forward-Port-Of: odoo/odoo#166034
Forward-Port-Of: odoo/odoo#165393

When the team_id of a ticket is set to False in its form view, a traceback occurs. This is an invalid value anyway, but the user should only be notified of that fact when he tries to save his change, not with traceback.

Step to reproduce:
- Open helpdesk
- open the 'all tickets' menu
- open any ticket form
- set the team_id to false
- save changes or click anywhere else to leave the edit field => a traceback occurs

Source of the issue:
When a new team is set on a ticket, a new stage is set on it, as well as new sla_status. The issue is that inside the _compute_sla_deadline method, the calendar of the team is used. But since there are no teams, there are also no calendar. And the ensure_one() fails later on in the stack because of that.

Solution:
Prevent the computation of those values for ticket without team_id. Since this is an invalid value, the changes would be rolled back anyway, or overwrite once the user put a valid value for the team.

version 16.0 - master
task - 3895303

Forward-Port-Of: odoo/enterprise#61563