Some json files are necessary for some modules but are not included in
packaging.

closes odoo/odoo#66759

Signed-off-by: Christophe Monniez (moc) <moc@odoo.com>

Kits must be consumable products, they might never be in stock.
Setting kits as storable products can create some issues if the user
creates some reordering rules.

Because kits might never be in stock, it's impossible to fullfil the
quantity of a reordering rule: asking a mini/maxi quantity on a kit
makes no sense.

Odoo will continuously propose to order more to reach the quantity
necessary for the kit, but will never reach the asked qty, as it's a
kit, not a manufactured product.

OPW-2448878

closes odoo/odoo#65339

Signed-off-by: Steve Van Essche <svs-odoo@users.noreply.github.com>

- Create SO with deliverable product, confirm
- Change delivery Address on SO and on Transfer
- Inventory > Stock moves (debug mode)
- Group by > Picking and Destination address

The address shows is the original and not the updated one.

opw-2429018

closes odoo/odoo#66031

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

Commit e5ab8cf9 missed a use case.

Steps to reproduce:

- Activiate "Packages" setting in Inventory
- Configure an operation type to "Move Entire Packages"
- Create a "Planned Transfer" picking with that operation type and add a
  package to be moved
- Turn off "Move Entire Packages" and try set the destination
  package of the move line to nothing (False).

Expected result:
Move line has no destination package + package level is deleted as
expected.

Another bug will still exist due to the design of package_level where if
in addition to the above use case, if a different package is used instead
of deleting it and "Move Entire Packages" is reactived => final package
shown in the Detailed Operations will show all move lines as being part
of the same package even though they are not. Data appears to be correct
in the database otherwise and a reasonable fix doesn't seem feasible for
now so we leave this bug as is.

Related to Task: 2418907

closes odoo/odoo#66556

Fixes: odoo/odoo#66542
Fixes: odoo/odoo#66517
Signed-off-by: Arnold Moyaux <amoyaux@users.noreply.github.com>

instead of using ad-hoc weirds

closes odoo/odoo#66581

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

Using `read_group` to gather such a sum is always more performant
than a `search` followed by a `mapped`.

In the case of the studied database,
the computation never ended,
while it ends in a few seconds
using `read_group`.

upg-7528

closes odoo/odoo#66469

Signed-off-by: Denis Ledoux (dle) <dle@odoo.com>

Currently a package level is created and has the newly created package
assigned to it when "Put In Pack" is used. Unfortunately if a move line
has its result_package_id changed after having a package assigned via
the Put In Pack, then the package level's package_id isn't correctly
updated. This leads to incorrect data in the db. This incorrect data
doesn't affect much since result_package_id from an entire package move
cannot be changed in any views, but it does mean that the created
package associated with the package level can never be deleted even if
it's never used.

Steps to reproduce:
1. active (delivery) packages in settings
2. create a picking and create some done values
3. use "Put In Pack" to put done move lines into a package
4. change the newly created Destination Package to another package
5. Go to Packages and try to delete the package created by Put In Pack

Expected result: able to delete the package
Actual result: Server error that package is still required by Stock
Package Level.

This is a short term fix. In the long run it would be better to fix the
package_level logic so it isn't unnecessarily assigned to moves/move
lines and/or updates in a cleaner way.

Task ID: 2418907

closes odoo/odoo#63544

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

Membership tree may include many partners and having excessive field
recomputation (i.e. more than ~n computations) could seriously slows
system down. The excessive recomputations comes from unneeded fields
in api.depends, which looks like a copy paste from compute method for
state field.

STEPS:
* add logs printing
* create a tree of associated members
* create membership invoice
* validate the invoice

Below is printing for the following tree

```
45
 \---- 51
  \
   \--- 50
    \
     \-- 46 -- 49
          \ -- 48
           \-- 47
```

BEFORE

Create invoice:

_compute_membership_state: res.partner(45,)
_compute_membership_cancel: res.partner(45,)
_compute_membership_stop: res.partner(45,)
_compute_membership_state: res.partner(46, 50, 51)
_compute_membership_cancel: res.partner(45, 46, 50, 51)
_compute_membership_stop: res.partner(45, 46, 50, 51)
_compute_membership_state: res.partner(47, 48, 49)
_compute_membership_cancel: res.partner(45, 46, 50, 51, 47, 48, 49)
_compute_membership_stop: res.partner(45, 46, 50, 51, 47, 48, 49)
_compute_membership_cancel: res.partner(45, 46, 50, 51, 47, 48, 49)
_compute_membership_start: res.partner(45, 46, 50, 51, 47, 48, 49)
_compute_membership_stop: res.partner(45, 46, 50, 51, 47, 48, 49)
_compute_membership_state: res.partner(45,)
_compute_membership_cancel: res.partner(45,)
_compute_membership_stop: res.partner(45,)
_compute_membership_state: res.partner(46, 50, 51)
_compute_membership_cancel: res.partner(45, 46, 50, 51)
_compute_membership_stop: res.partner(45, 46, 50, 51)
_compute_membership_state: res.partner(47, 48, 49)
_compute_membership_cancel: res.partner(45, 46, 50, 51, 47, 48, 49)
_compute_membership_stop: res.partner(45, 46, 50, 51, 47, 48, 49)
_compute_membership_cancel: res.partner(45, 46, 50, 51, 47, 48, 49)
_compute_membership_start: res.partner(45, 46, 50, 51, 47, 48, 49)
_compute_membership_stop: res.partner(45, 46, 50, 51, 47, 48, 49)

Validate invoice:

_compute_membership_state: res.partner(45,)
_compute_membership_state: res.partner(46, 50, 51)
_compute_membership_cancel: res.partner(46, 50, 51, 45)
_compute_membership_stop: res.partner(46, 50, 51, 45)
_compute_membership_state: res.partner(47, 48, 49)
_compute_membership_cancel: res.partner(46, 50, 51, 45, 47, 48, 49)
_compute_membership_stop: res.partner(46, 50, 51, 45, 47, 48, 49)
_compute_membership_cancel: res.partner(46, 50, 51, 45, 47, 48, 49)
_compute_membership_start: res.partner(46, 50, 51, 45, 47, 48, 49)
_compute_membership_stop: res.partner(46, 50, 51, 45, 47, 48, 49)
_compute_membership_state: res.partner(45,)
_compute_membership_cancel: res.partner(45,)
_compute_membership_stop: res.partner(45,)
_compute_membership_state: res.partner(46, 50, 51)
_compute_membership_cancel: res.partner(45, 46, 50, 51)
_compute_membership_stop: res.partner(45, 46, 50, 51)
_compute_membership_state: res.partner(47, 48, 49)
_compute_membership_cancel: res.partner(45, 46, 50, 51, 47, 48, 49)
_compute_membership_stop: res.partner(45, 46, 50, 51, 47, 48, 49)
_compute_membership_cancel: res.partner(45, 46, 50, 51, 47, 48, 49)
_compute_membership_start: res.partner(45, 46, 50, 51, 47, 48, 49)
_compute_membership_stop: res.partner(45, 46, 50, 51, 47, 48, 49)

AFTER

Create invoice:

_compute_membership_cancel: res.partner(45,)
_compute_membership_stop: res.partner(45,)
_compute_membership_start: res.partner(45,)
_compute_membership_state: res.partner(45,)
_compute_membership_state: res.partner(46, 50, 51)
_compute_membership_state: res.partner(47, 48, 49)
_compute_membership_state: res.partner(45,)
_compute_membership_state: res.partner(46, 50, 51)
_compute_membership_state: res.partner(47, 48, 49)

Validate invoice:

_compute_membership_state: res.partner(45,)
_compute_membership_state: res.partner(46, 50, 51)
_compute_membership_state: res.partner(47, 48, 49)
_compute_membership_state: res.partner(45,)
_compute_membership_state: res.partner(46, 50, 51)
_compute_membership_state: res.partner(47, 48, 49)

---

opw-2390394

closes odoo/odoo#65980

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

91937764 added new selector to target other location where product name
could break the interface on short screen or with long unbreakable word
in title.

But there is some use case missing where overflow-wrap doesn't work and
word-wrap doesn't. Also adding overflow-wrap since word-wrap is
deprecated.

opw-2451496

closes odoo/odoo#66257

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

Before this commit:

If a next activity is "triggered", the discard button is not visible.

After this commit:

Even if a next activity is "triggered", the discard button will visible.

Task-2459645

closes odoo/odoo#66168

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

The mail signature of an user did not inline the CSS like the body of a
message, so for example icons seemed to work but would not be seen
(unless the mail reader had the same font-awesome system).

With this change we inline the signature too.

On edition there was also an issue since the original icon was saved as
data-class which was stripped: so eg. when editing a mail.message with
working icon, the icons would disappear.

opw-2453912

closes odoo/odoo#66185

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

In some location, a long unbreakable word would cause following columns
to be hidden (depending on size of unbreakable word, font, font size,
...). For example, this happened in the cart summary on payment page.

With this changeset, if not possible otherwise, line break happen inside
the word.

opw-2451496

closes odoo/odoo#66176

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

before this commit: when there is only one page in the notebook tag and
there is a boolean field in form to show/hide that notebook page based on
invisibility attrs, if we toggle boolean field notebook hides, that's OK
but when we toggle boolean field again then notebook page is displayed but
it is not active and due to that content of notebook page is not displayed.

after this commit: when there is only one page in notebook and it has attrs
for invisibilty, when we toggle boolean field to hide/show notebook page
then notebook page as well as content is toggled.

task-2449053

closes odoo/odoo#65318

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

This commit is a backport from bfa73d38
This part of the tour can't work with the new online synchronization
module (account_online_synchronization) due to the fact that we are
using an iframe to display the list of institutions and therefore
those steps won't work within the iframe.

closes odoo/odoo#51988

Related: odoo/enterprise#10803
Signed-off-by: Cedric Snauwaert (csn) <csn@openerp.com>

before this commit: when there is a horizontal scroll in view say for example
kanban view where there are too many columns and user scrolls horizontally and
go to form view by clicking on any record and then come back to kanban view
horizontal scroll is not preserved and user is moved to scroll position 0
this is due to commit: https://github.com/odoo/odoo/commit/19eacf7d23c9413de4430a3422b5ed74b37ef242



after this commit: scrolling horizontally and then go to form view and come
back to previous view will preserve scroll position, we also consider case for
kanban view where there are too many columns and user click on 'Add Column'
user will be scrolled to new column element.

task-2418275

closes odoo/odoo#63933

Related: odoo/enterprise#15511
Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

with this commit, we fixes UI glitch on image widget when image is too small,
when hovering over too small image Edit and Delete icon will ne displayed but
it is displayed with glitch, so to avoid that glitch we added min-width to
icons div.

task-2376452

closes odoo/odoo#64391

Signed-off-by: Aaron Bohy (aab) <aab@odoo.com>

task-2458109

closes odoo/odoo#65970

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

scenario: open customer form by clicking new customer button and select
image and again click on image which will open file explore, now click
cancel button in file explorer which means we do not want to change
image, it will throw traceback.

traceback should not be thrown if image is not selected from file explorer
which will be fixed with this commit.

task-2412485

closes odoo/odoo#62994

Signed-off-by: pimodoo <pimodoo@users.noreply.github.com>

Before this commit, calling do_hide/do_show/do_toggle on a
widget that had been destroyed before being rendered crashed
(because this.$el was undefined).

Obviously, calling those methods in this situation is useless, but
with asynchronous code, it might happen that you call them in an
handler, and they have been destroyed meanwhile.

This commit checks if this.$el is set before accessing it to avoid
the crash.

closes odoo/odoo#65870

Signed-off-by: Géry Debongnie (ged) <ged@openerp.com>

Steps:
- Install studio, website_form
- Go to Settings > Users & Companies > Users
- Click the Studio icon
- On the top bar, click Website
- Click New Form
- In edition mode, click the first label
- Select Customize > Add an Existing Field

Bug:
Traceback here:
https://github.com/odoo/odoo/blob/3ff00944fe6a439bd5d7bddb846206d3d6cac3a0/addons/website_form/models/models.py#L73
KeyError: 'readonly'

Explanation:
Dynamic selection fields don't declare a 'readonly' attribute:
https://github.com/odoo/odoo/blob/3ff00944fe6a439bd5d7bddb846206d3d6cac3a0/odoo/addons/base/models/res_users.py#L1275-L1282



opw:2449356

closes odoo/odoo#65784

Signed-off-by: backspac <backspac@users.noreply.github.com>

Steps to reproduce the bug:

- Install manufacturing app
- Create a product A
- Create a Bill of Materials for product A
- Archive Product A (Only the final product not any of the components)
- Print BOM or Print BOM Structure & Cost

Bug:

A traceback was raised

opw:2447514

closes odoo/odoo#65815

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

- Install Accounting, Purchases and Inventory;
- Configure cash basis accounting;
- Configure purchases taxes as 'Based on Payment' with 16% of amount;
- Create a new product and configure it as a Storable Product.
- Configure the product category with costing method of the to FIFO and
    the Inventory Valuation to Automated;
- Create a Purchase Order for a stock product with quantity 1,262.84 and
    price unit of 10.37;
- Confirm the Purchase Order;
- Receive product for 1,262.835 (0.005 less than ordered);
- Create the vendor bill from the purchase order for the original
    quantity (1,262.84) and price unit of 10.37;
- Validate the vendor bill and pay it.

Before this commit, the cash basis journal entry was created with an
incorrect amount of 0.05 of Base Tax Received Account.

Now, the cash basis journal entry is created with the amount paid of
13095.65 of Base Tax Received Account

fine-tuning of e25f857e

opw-2411516

closes odoo/odoo#63738

Signed-off-by: Jorge Pinna Puissant (jpp) <jpp@odoo.com>
Co-authored-by: Andrea Grazioso <agr@odoo.com>

Before this commit, only whitelisted fields would be updated on cow views
during a module update.
A field would be whitelisted if he had the same value than the original view,
see it as a heuristic to not write on modified fields.

But `inherit_id` is not that simple, even if the cow view has a different value
than its original view, it doesn't mean it was modified by the user, it is just
because of the cow mechanism that assigned a copied view as inherit_id, which
is just a copy ofthe original one.

We can thus consider `inherit_id` as unchanged and whitelist it if the `key` is
the same.

In practice, it means that cow'd views did not receive the `inherit_id` updates
as in commit https://github.com/odoo/odoo/commit/c8577568a1e39f6692889b3e21652fa3b8df06b2#diff-823e5db841dca1798ff1300e243059a4e1c93343598d2be5a1d1dcd1d2d0c273R537
where `portal.my_account_link` had its `inherit_id` changed from
`portal.frontend_layout` to `portal.user_dropdow`, see https://github.com/odoo/upgrade/pull/2059

:

Considering a module update changing `inherit_id` of D from A to B, the
following use cases are expected. Without this fix, D' never move:

CASE 1
  A    A'   B                      A    A'   B
  |    |                 =>                 / \
  D    D'                                  D   D'

CASE 2
  A    A'   B    B'               A    A'   B   B'
  |    |                 =>                 |   |
  D    D'                                   D   D'

CASE 3
    A    B                        A    B
   / \                   =>           / \
  D   D'                             D   D'

CASE 4
    A    B    B'                  A    B   B'
   / \                   =>            |   |
  D   D'                               D   D'

closes odoo/odoo#64446

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

closes odoo/odoo#65781

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

Loop inner calls should use mailing not self.

Task ID-2455433

closes odoo/odoo#65724

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

- Install account_accountant, stock_account, purchase & sale_management
- Create a Product (i.e. Product X)
- Edit Product Category:
  * Costing Method: Average Cost (AVCO)
  * Inventory Valuation: Automated
- Create a PO with Product X for 5 quantities at $5
- Receive the Products
- In Inventory > Report > Inventory Valuation, for Product X, we have (qty: 5, value: $25)
- Create a SO with Product X for 10 quantities
- Deliver Products
- Valuation for Product X = (qty: -5, value: $-25) => Correct
- In Inventory > Operations > Inventory Adjustments, create an adjustment for Product X to 0
- In Product X form, update cost to 0 (You may need to remove Vendors from Purchase tab to be able to do it)
- There is no more valuation for Product X => Correct
- Edit Product Category by setting "Costing Method" to "First In First Out (FIFO)"
- /!\ Do not recompute Inventory Valuation via Inventory > Report > Inventory Valuation
- Create a PO with Product X for 10 quantities at $7
- Valuation for Product X = (qty: 10, value: $70) => Correct
- Create a SO with Product X for 7 quantities
- Deliver Products
At this point, Inventory Valuation for Product X is incorrect. The Quantity is 3, which is correct,
but the value is $31, instead of $21 (3 * $7).

With FIFO Costing Method, the valuation of the last SO should be (7 units at $7) = $49.
But here, we have (5 units at $5 + 2 units at $7) = $39.
When the Inventory Adjustment has been made to set Product X to 0, a move of (qty:5, value: $25)
has been made to balance the previous Valuation of (qty: -5, value: $-25).
Values from this move are used during the last SO, but it shouldn't.

It happens because the "remaining_qty" field of the move created for the adjustment
has a value of 5 (the original move qty), instead of 0 (the real remaining qty).
Therefore the quantities from this move are used when running "_run_fifo" method,
although they should have been used to cancel the negative "remaining_qty" (-5) from
the move generated by the first SO.

To prevent this, moves with negative "remaining_qty" should be fixed when an in move is validated.

PS: The issue is also reproducible with FIFO Costing Method from the start,
as long as no Inventory Valuation recomputation is performed once the
inventory adjustment has been made.

opw-2425909

closes odoo/odoo#65250

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

This commit makes it so when the bom structure report (Structure & Cost
smartbutton) is opened the product quantity defaults to the BoM's
`product_qty` amount rather than 1.

Steps to reproduce:
- Create/open a BoM
- Set `product_qty` to any value greater than 1
- Click on "Structure & Cost" button.

Expected result: product quantities scaled to the `product_qty`
Actual result: product quantities scaled to Quantity = 1

closes odoo/odoo#64839

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

Up to v11 it was possible to search by purchase vendor reference when
we're using the auto-complete function in a vendor bill. With the
refactor of this functionality, this useful feature was lost.

closes odoo/odoo#65265

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

The function `_get_possible_combinations` generates possibles combinations
 for the product template attribute values (ptav) of each product template
 attribute line (ptal) of a given product template. It used to iterate over
 them using a cartesian product. A combination can be invalid if it
 contains two incompatibles ptav. The problem is that it used to filter out
 invalid combinations after generating them. It's a problem because there
 can be a lot of invalid combinations to filter out before finding a valid
 combination. Even before the first valid combination if the first ptav of
 the two first ptal are incompatible.

The solution brought by this commit is to reject the invalid combinations
 while building them rather than after. It does so by using a cartesian
 product implementation with early rejection. The algorithm tests each
 ptav when incorporating it in a partial combination and if it's
 incompatible, it goes to the next partial combination and thus skips all
 combinations starting with the invalid partial combination.

The client that reported the issue has a product template with about 25
 ptal with an average of 9 ptav. The ptav of the first ptal was
 incompatible with the first ptav of second ptal. It had to build and
 filter out 5.76*10^15 ptav before finding the first valid ptav. If we
 generate 10^6 ptav by second (it's much less) user would get first ptav
 after 182 years. Now it's instantaneous.

opw-2335936

closes odoo/odoo#65089

Signed-off-by: Sébastien Theys (seb) <seb@odoo.com>

Because of context:

{'search_default_account_id': [active_id]}

refreshing on the tax audit action could cause an error because in normal
use case we have active_id that is never an account.account id (but for
example an account.tax.report.line).

There doesn't seem to be any use case where that context is useful since
it was introduced in 2017 (81089042), this action is always used with an
overriden context. So this commit is removing it.

opw-2388448

closes odoo/odoo#65698

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

such fields have store=True, but they don't exist in table.

---

https://github.com/odoo/odoo/pull/65232#issuecomment-773298323
https://github.com/odoo/odoo/commit/02417290191c22c9c99e6dc96a572c21f38e64f1



closes odoo/odoo#65535

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

The Lesotho Loti has the symbol M and not L
Example of use:
http://lestimes.com/businessman-xie-in-m27-million-scandal/
http://lra.org.ls/sites/default/files/2020-10/LRA%20Integrated%20Annual%20Report%202019.pdf



Fixes odoo/odoo#62807

closes odoo/odoo#65633

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

Previously, the many2one widget from the web_editor used jQuery's
'.html()' method when inserting a record name into the page. The record
name was not HTML-escaped before this, which may have unexpect result
and break the layout.

This commit fixes that by using the '.text()' method instead.

This bug only affects pages containing a many2one (contact excluded)
at the time of selection and not after the selection.
e.g. on the /event page, changing the category of an existing event
via the website editor

closes odoo/odoo#65610

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

closes odoo/odoo#65590

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

- Install stock
- Go to Inventory > Configuration > Settings and enable "Lots" and "Storage Locations"
- Create a Product tracked By Lots (i.e. Product X)
- Go to Inventory > Operations > Inventory Adjustments
- Create an Inventory Adjustment for Product X:

     Product   |   Location   |   Lot/SN   |   Real Quantity
 -------------------------------------------------------------
    Product X  |   WH/Stock   |   LOT 01   |       20
    Product X  |   WH/Stock   |            |       10

- Validate Inventory
- Go to Inventory > Operations > Transfers and create one:
  * Source Location: WH/Stock
  * Destination Location: WH/Stock/Shelf1
  * Operation Type: Internal Transfers
  * Operations:
    [Product: Product X, Initial Demand: 25]
- Save Transfer, Mark As Todo and Check availability
- Click on list icon of Operation line for Product X to display Detailed Operations
- 20 units of LOT 01 and 5 units without lot have been reserved
- Set LOT 01 for the 5 reserved units without lot and confirm
- Open Detailed Operations again
- There are now 20 units of LOT 01 and 5 units of LOT 01
- Remove the row with 5 units and confirm
- Check availability and open Detailed Operation
- There is now only a row with 25 reserved units of LOT 01
- Unreserve
The following errror is raised:
"It is not possible to unreserve more products of P than you have in stock."

It happens because the system is not able to manage quants with lots and
wihtout lots at the same time. When modifying the move line to 25
reserved units. It's composed of 20 quants with lot and 5 quants without
lot. And when unreserving it will check if there is a quants with 25
units with the lot and if it's not found 25 units without lot. But never
25 units of quants with lots and without lots.

opw-2419444

Close #64497

closes odoo/odoo#65057

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

Follow-up of https://github.com/odoo/odoo/pull/65357



closes odoo/odoo#65470

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

Steps:
- Install mrp, stock
- Go to Inventory > Configuration > Operation Types
- Edit Delivery Orders:
  - Show Detailed Operations: Checked
- Go to Master Data > Products
- Create two products (1) (2)
- Click (1)
- Click the "Bill of Material" smart button
- Create a BoM:
  - BoM Type: Kit
  - Component: (2)
- Go to Overview
- Click Delivery Orders
- Create a Delivery Order:
  - Add (1) with an initial demand of 1
- Mark as ToDo
- Click Edit:
  - Detailed Operations tab:
    - Add (1) with a done quantity of 1
- Validate and create a Backorder

Bug:
Record does not exist or has been deleted.
(Record: stock.move(60,), User: 2)

Explanation:
When confirming a `stock.picking` with `mrp` installed, the action goes
through `action_explode()`.
https://github.com/odoo/odoo/blob/d9ea1d5f054f05197581acf67c8a9c1e6acb8d02/addons/mrp/models/stock_move.py#L154
This action splits the components of the product with a Kit (`phantom`)
BoM instead of manufacturing it. When everything is split, the
`stock.move` unlinks itself because it has been replaced with its
components. `action_explode()` then returns the new components. Trying
to call a method on the unlinked move will result in an error.

This commit replaces the move with the newly generated component moves.

This is safe to do in `stock` because the non-overridden
`_action_confirm()` returns the move it was called on as seen here:
https://github.com/odoo/odoo/blob/d9ea1d5f054f05197581acf67c8a9c1e6acb8d02/addons/stock/models/stock_move.py#L790



opw:2450016

closes odoo/odoo#65462

Signed-off-by: backspac <backspac@users.noreply.github.com>