On some DB, it is not possible to update some modules that depend on
`account`

To reproduce the issue:
1. Checkout before [1] and install `account_accountant`
2. Checkout after [1]
3. Update `account_accountant`

Error: a server error is displayed

> Field 'code' used in domain of field 'payment_acquirer_id' ([
> ('provider', '=', code)]) must be present in view but is missing."")

Commit [1] contains unstable changes: it adds a domain on the field
`payment_acquirer_id` of `account.payment.method.line` and, to make
it work, it also adds the needed field `code` on the view
`view_account_journal_form`. But, if the view is not updated on an
existing database, the domain can not work, hence the client error.

This explains why the above use case does not work:
The module `account_accountant` has a view that also inherits the
view of account `account.view_account_journal_form`. As a result,
when updating the module (and, therefore, the view of
`account_accountant`), we `:View._validate_view` the whole view, which
will lead to:
https://github.com/odoo/odoo/blob/2cbf9d840b79520854731fd6a23431c69e451775/odoo/addons/base/models/ir_ui_view.py#L2282-L2286

[1] https://github.com/odoo-dev/odoo/commit/88782d3a76fb3941b9ed7d998ec0610aa26ff611

opw-3993709
opw-3993707
sentry-5416409171

Forward-Port-Of: odoo/odoo#170308
Forward-Port-Of: odoo/odoo#169978

The value of the returned product may be different from the one
initially received. In such case, the stock accounting may be broken.

To reproduce the issue:
(Need account_accountant)
1. Create an auto-FIFO product category
2. Create a storable product
3. Confirm a PO with 1 @ 10
4. Receive it
5. Confirm a PO with 4 @ 25
6. Receive 1 with backorder
7. Return it
8. On the backorder, receive 4
9. Bill

Error: Looking at the AML of the stock-in account, some lines are
not reconciled and there is a $15 difference between the totald debit
and the total credit.

Step 7, when returning the product, we actually return the one at
$10. Step 8, we then receive 4 products at $25 (hence the difference
of $15). So, back to step 7, when returning the product, we should
also compensate the stock-in account (with the expense one) in case
of a difference.

Let's look at another case: after step 7, the user "returns the
return". In such case, the value of the new receipt is based on the
returned one (see [1]), i.e.: the value of the newly received
product will be $10. In such case, we also need to (1) compensate
the stock-in account and (2) prevent the pdiff process to generate a
pdiff of $15 (otherwise, we would add a value to the received
product, which would go against the logic of [1]).

This commit does not address the behaviour difference between the
two above use cases (-> depending on how the user receives again the
returned product, its value is not the same). This would probably
need a deeper analysis a change, on master.

Note: a third use case does not work either: (step 1-4), PO 1 @ 25,
receive, bill, return, refund.

[1]
https://github.com/odoo/odoo/blob/07464844c69ac3b667adfede0e4e330831819802/addons/purchase_stock/models/stock_move.py#L32-L40
Initially added by https://github.com/odoo/odoo/commit/200aac56771fd1ef759f73b277a6808d96ee5f31

OWP-3698324

Forward-Port-Of: odoo/odoo#162697
Forward-Port-Of: odoo/odoo#162368

Steps to reproduce:
-------------------

- Install `website_event` module
- Create an event with name `Test Event` and enable `Website Submenu` option
- Click on `Go to Website` stat button
- Edit the `Introduction` page by adding a new block under the event name for example
- Save it and go back to backend
- Create a new event with same name `Test Event` and enable `Website Submenu` option
- Click on `Go to Website` stat button

Issue:
------

The second event will have the edited
`Introduction` page from the first event.

Cause:
------

When creating the menu, since we do not create a
page, the URL retrieved in the process will be
always the same and therefore redirect to the
edited page of the first event (since the last
part of the URL is used to retrieve the right
view).

Solution:
---------

Ensure the URL is unique by using the view key
(who is unique) as last part of the URL.

opw-3945840

Forward-Port-Of: odoo/odoo#170149
Forward-Port-Of: odoo/odoo#169770

Steps to reproduce:
-------------------
1. Create a move with date = 01/01/24, start = 01/06/23, end = 31/05/24.
2. Post the move, the deferred entries are created
3. Set the All User Lock Date to 31/12/23
4. Reset the move to draft

- The deferral moves of 2024 are deleted.
- The deferral moves of 2023 are still linked to the move
- The reversed deferral moves of 2023 are created but not linked to the move and they are dated on the 1st January (first day after the lock date)

5. Post the move again

A traceback is raised because of an assert that verifies that we shouldn't regenerate deferral entries if a move already has them.

Solution:
---------
1. The generated reversal of the deferrals of 2023 should be linked to the move.
2. Now that this is done, we can remove the assert because all deferral entries will cancel out each other (i.e. the aggregation will result in no deferral entries).
3. When reverting, we will now use the accounting date instead of the first day after the lock date (if there is one)

opw-3861179

https://github.com/odoo/enterprise/pull/61928

Forward-Port-Of: odoo/odoo#164316

**Steps to reproduce the bug:**
- Create a consumable product “Kit 1” with the following BoM:
    - component: X1

- Create a repair order to repair one unit of Kit 1:
    - Don’t add any part
    - confirm and Start the repair
    - try to end the repair

**Problem:**
A traceback is triggered:
“raise ValueError("Expected singleton: %s" % self)
Value Error: Expected singleton: stock.location()
“

When the "action_repair_end" is called, a move is created with the kit
product, and then we attempt to confirm it:
https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L80

Since the product is a kit, it is exploded into two moves with products
“X1” and “X2”. We then try to assign them a “repair” picking_type_id:

https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L74

So, the write method is used and since the “picking_type_id” is in the
vals, and the product in the move (X1) is not the same as the one in the
repair order, we consider this product a “Part” of the repair.
Therefore, we try to use its location_id and location_dest_id, which we
fetch based on the “repair_line_type” that will be False because it is
not a part of the repair but rather the product to be repaired:

https://github.com/odoo/odoo/blob/eaa6e1a08c3d2cdcb558689523e5bd332978f5e4/addons/repair/models/stock_move.py#L93-L94

The first error is triggered during the “should_by_pass” check because
there is no location set in the move:
https://github.com/odoo/odoo/blob/c7b947364d34cc6ccfb1eb7a2c16b6bba226d8e7/addons/stock/models/stock_move.py#L1051-L1052

If we fix this error, we will still encounter an error because both
moves will be confirmed. However, we will return to the first loop to
continue calling the “_trigger_scheduler” function for the first move
with the “Kit” product, which will be already deleted because it was
exploded, resulting in a user error:

“odoo.exceptions.MissingError: Record does not exist or has been deleted.
(Record: stock.move(253,), User: 1)
“

opw-[3942297](https://www.odoo.com/web#id=3942297&view_type=form&model=project.task)

Forward-Port-Of: odoo/odoo#168227

### Steps to reproduce:
- Enable multi-step routes in the settings
- Go to Invertory > Configuration > Warehouse Management > Routes
- Unarchive MTO
- Create a product: - Routes: MTO + Buy route - Variants: Color > Black, White
- In the purchase tab of the product create two lines with: - Vendor 1 sells the Black variant - Vendor 2 sells the White variant
- Create and confirm a sale order with 2 lines: - 1 x Black variant - 1 x White variant

### Expected behavior:

Two purchase order should be created:

- 1 x Black variant sold by Vendor 1
- 1 x White variant sold by Vendor 2

### Current behavior:

Only one purchase order is created so that Vendor 1 as the seller of both procurements even thought vendor 2 is the only real potential seller of the white variant.

### Cause of the issue:

Running the procurements of both lines of the Sale order will trigger the `_run_buy` method which will determine the seller by "default": https://github.com/odoo/odoo/blob/3383d5bd68bfc13b7881f72e5adbb7c27a6df30e/addons/purchase_stock/models/stock_rule.py#L70-L72 using the `_prepare_sellers` method. However, it relies solely on the `seller_ids` field of the `product.template` model https://github.com/odoo/odoo/blob/3383d5bd68bfc13b7881f72e5adbb7c27a6df30e/addons/product/models/product_product.py#L633-L634 Since both variants have the same template they will therefore both be associated with the same default seller.

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

Forward-Port-Of: odoo/odoo#166970

There are some small issues when transforming a normal column into a grid item:

1) When borders are set on columns, these columns do not look good when they become grid items:

- In edit mode, drop the "Text-Image" snippet.
- Set the columns "Border" option to a rather big number (e.g. 50px).
- Toggle the grid mode. => The layout does not look good: the grid items are too small and not placed like how they were in normal mode (toggling the grid mode is supposed to place the items as close as possible as before the toggle).
- Drop the "Steps" snippet and set a border on a column.
- Drag the column and drop it in the "Text-Image" grid dropzone. => The content of the column overflows the grid area which does not look good.

This issue happens because when computing the grid areas, the border was not taken into account, resulting in grid items being too small (-> the width/height without the borders) and not having the right position (-> the starting position of the element "inside" the borders).

2) When a column becomes a grid item, its grid area is sometimes a bit too small to contain its content, making it overflow a bit:

- Drop the "Text-Image" snippet.
- In the first column, drop the "Rating" snippet and delete all the other content.
- Toggle the grid mode. => The "Rating" snippet overflows a bit the grid item (it is easier to see when using the browser inspector).

This overflow happens because when computing the grid areas, the grid padding was not taken into account, resulting in the content overflowing if it was barely fitting or if the grid padding was really big (e.g. when dropping a normal column in a grid mode "Big Boxes" snippet).

This commit fixes these issues by taking the borders and the grid padding into account in the grid areas computation when toggling the grid mode and when converting a normal column to a grid item when drag and dropping it.

task-3970022

Forward-Port-Of: odoo/odoo#169988
Forward-Port-Of: odoo/odoo#169090

[FIX] project,hr_timesheet: create projects with company-specific customer

Problem
---
When creating projects with a customer whose company field is set,
`_check_company` raises an Error because of a mismatch with
the analytic account's company (False).

Steps
---
(from fresh db, with demo data)
1. install `project` and `sale_management` (so that projects can be
   billable)
2. in the settings, create a second company,
   (so that contacts' 'Company' field can be set)
3. on a contact, set the 'Company' field (under: Sales & Purchase > Misc)
   to the current company ('YourCompany')
4. In Setting > Project: enable 'Timesheets'
5. Try to create a new billable project with 'Timesheets' enabled
   and the customer from step 3

Fix
---
Never set the partner on the analytic account when creating a new
project.
Note that we have to modify the corresponding test.
This is acceptable because in some flows (create project with
no partner, **then** set the partner) this is what
already happens and seems to not be a problem.

opw-3865150

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

Forward-Port-Of: odoo/odoo#162961