**Current behavior:**
Sharing an editable link to a project with a portal user creates
an undesirable scenario where they can read a project record and
associated tasks but trying to use the chatter on a task's page
results in a vague access error.

**Expected behavior:**
An editable share link should require the invitee to login prior
to accessing records and the chatter.

**Steps to reproduce:**
1. Make a project shareable with external users, share an
     editable link with a portal user

2. Open the generated link in an incognito window, go to a task
     that has the chatter text area input available

3. Try to leave a comment, observe the vague error
     (access error behind the scenes)

**Cause of the issue:**
The hash which is generated with the share link for the invitee
uses the project record's `_mail_post_token_field` to permit
access on that record. The system which should recognize this
case and also permit access to that project's task records is
not working properly. Eventually, we fail a consteq() check on
the hash in the URL and the token generated by the ORM to
determine accessibility of the record (because it uses the
task's `_mail_post_token_field` value while ours was generated
using the project's).

**Fix:**
Create a method on the `mail.thread` extension in `portal` which
can be overridden in inheriting classes to return a logical
parent's `_sign_token()` result.

When checking for chatter post access, check both values against
the provided hash.

opw-3777597

Forward-Port-Of: odoo/odoo#170492
Forward-Port-Of: odoo/odoo#160170

The COGS registered was wrong when invoicing a product that is a kit
with UOM A and component uses UOM B.

Steps to reproduce:
-------------------
* Create Comp A with UOM Dozens. It's cost should be 12000
* Create Product A with UOM Units.
* Make sure both use the same category, and the category should use
  automcatic inventory valuation.
* Create a kit bom for product A that contains 1 comp A.
* Sell this kit in the PoS and invoice it.
* Close the PoS and go to the order then on the invoice.
* Check the journal items

> Observation: the COGS is 12000 it's wrong. It should be
  1000

Why the fix:
------------
The `_get_pos_anglo_saxon_price_unit` is not taking the product uom into
account. So in this example the price unit will be for a dozen, but the
bom specifies that we are using a unit and not a dozen. So the quantity
needs to be modified from a dozen to unit. That's what the 
`_compute_price` method is doing.


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

Forward-Port-Of: odoo/odoo#170267
Forward-Port-Of: odoo/odoo#166382

[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

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

### 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

When posting a big invoice (>800 lines) for products that are valuated in real_time, the `_post` override in
`purchase_stock` can become a bottleneck for anglo-saxon companies. This method calls `_stock_account_anglo_saxon_reconcile_valuation` which performs reconciliations for all the invoice_lines.

Thanks to odoo/odoo#113680 it's now possible to batch the reconciliation process via the backend method `_reconcile_plan`. This gives various speedups by batching create, reducing the number of flush, etc.

Moving the reconciliation process outside of the loops in `_stock_account_anglo_saxon_reconcile_valuation` and calling `_reconcile_plan` only at the end of the method gives a significant speedup for big invoices.

#### speedup

Customer database with mix of real_time and manual inventory valuation and anglo-saxon accounting.
purchase_stock is installed.
15 000 products, 80 000 stock.moves, 66 000 stock.move.lines,
100 000 account.moves, 289 000 account.move.line.

Time to post an invoice changing the number of lines.

| # Lines |     Before PR            | After PR |
|:-------:|:------------------------:|:--------:|
|    10   |       1.66s              |   1.11s  |
|    50   |       8.53s              |   2.95s  |
|    200  |       1min30s            |   11.51s |
|    889  |       +20min (killed)    |   58.84s |

opw-3901468

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

Forward-Port-Of: odoo/odoo#166482

**[IMP] website: match navbar toggler color to overlay header text color**

Before this commit, the navbar hamburger button didn't have the same
color as the text color defined for the "Over The Content" header, which
led to situations where it wasn't visible.

Steps to reproduce:

- Go to the website edit mode.
- Click on the header and choose "Over The Content" for the "Header
Position" option.
- Use the color picker to set the "Text Color" option to white.
- Drag and drop a "Text-Image" snippet onto the page.
- Apply a dark background color to the "Text-Image" snippet.
- Click on the "Mobile Preview" button.
=> The navbar hamburger button is not visible in the header.

After this commit, the navbar hamburger button in the "Over The Content"
header matches the color of the header's text.

task-3853573

---------------------------------
**[FIX] website: hide the overlay on the mobile menu navbar toggler**

Before this commit, after clicking on the mobile menu navbar toggler in
Website edit mode, the blue overlay was covering the button.

This commit fixes this. Indeed, this element is not editable, so there's
no need for an overlay on it.

task-3853573

Forward-Port-Of: odoo/odoo#163139

Currently when applying a coupon for 10% on the order on the current order, the points awarded are 100% of the points instead of 90%. The loyalty program rewarding x points per $ spent.

The same behavior is also observed in the sale worflow.

Steps to reproduce:
-------------------
* Go to the **Point of Sale** App
* Open shop session
* Select a customer
* Add a product (ex. Office chair 70$)
* Select **Enter Code**
* Enter the code `10pc`
> Observation: The order will grant 700 points instead of 630. The amount paid is 63$ with the code for 10% on the order.

Settings of the **Discount & Loyalties**:
* **Code for 10% on orders**
  * Rule: 
    * `Among` -> no restriction set 
    * `Minimum quantity`: 1 
    * `Minimum Purchase`: 0
  * Reward:
    * `Discount`: 10% `on` order
* **Loyalty Program**
  * `Use points on`: Current & Future orders
  * Rule:
    * `Among` -> no restriction set
    * `Minimum quantity`: 1 
    * `Minimum Purchase`: 0 
    * `Grant` 10 loyalty poins per $ spent

Idea of the fix
---------------
As discussed with DALA, discount should count toward points awarded. Here is how it should apply:
* If program_rule has no domain, all lines should count (except ewallet & gift cards)
* If program_rule has a domain, we should use all the lines where the product matches the domain (except ewallet & gift cards)

This applies for the computation of points based on the money spent.

Why the fix:
------------
https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L917

Sale-wise, we replace `rule_products` with `so_products_per_rule.get(rule, [])`. We also replace `order_lines` by `lines_per_rule`.
* `rule_products` don't include discounts as they are computed on `order_lines` (all lines that are not reward lines). https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L834-L841 https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L889
* `so_products_per_rule` will include the discounts if they match with the program's domain.
https://github.com/odoo/odoo/blob/2f6f8014f79e1db53d6c4c27e0cc60ccd48fd301/addons/sale_loyalty/models/sale_order.py#L844
* We don't need to exclude the free product reward lines from `lines_for_points` as the price is 0 on the SO. Shipping lines and free shipping rewards are not counted.

In pos, the fix is a bit different.

https://github.com/odoo/odoo/blob/4b9dee8fbe9aefde798c8543fef89c661cc85c57/addons/pos_loyalty/static/src/js/Loyalty.js#L908-L914

We first notice that this piece of code is never triggered as the structure of `program.id` is a number and `reward.program_id` is the following thus the last if statement is never true. A `.id` is added.
```
Proxy(Object) {id: 1, name: 'Code for 10% on orders', trigger: 'with_code', applies_on: 'current', program_type: 'promo_code', …}
```

This now means that we only count reward lines if they are from the same program. 

With the following if statement, it means that only the lines that are not reward lines are counted (which excludes discounts).

https://github.com/odoo/odoo/blob/eadfa4ee290a8b62956097aa66989eacff230275/addons/pos_loyalty/static/src/js/Loyalty.js#L921-L924

We conclude that those two ifs must be changed as we want a similar behavior as the workflow in sales.

We remove `orderedProductPaid` out of the if statement since it can be impacted by reward lines. We change the first if to excludes the reward lines only from the current program or from ewallet and giftcards. With this, `orderedProductPaid` now counts the discount lines from other program. (Similar to sales, where `amount_paid` is computed with `lines_per_rule`)

`totalProductQty` still applies only on non reward lines. (Same as sales)

opw-3858286

Forward-Port-Of: odoo/odoo#170142
Forward-Port-Of: odoo/odoo#164723

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:
-------------------

- 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

**Current behavior:**
Having a storage location with a storage category that has a max quantity acting on some productA, and a putaway rule that will move product from an intermediary location to the location with the category:

Creating a move for productA into the intermediary location that won't hit the cap applied on the second location, then creating an additional move (separate picking) with a demand that exceeds the cap will result in the cap not getting respected during the quant move process.

**Expected behavior:**
The second move will not get assigned via putaway rule to the second location, as its quantity is too large.

**Steps to reproduce:**
1. Create a storage category with a capacity: `product: productA` `quantity: 5`

2. Create an internal location: `parent location: WH/STOCK` `storage category: from step 1`

3. Create a putaway rule: `product: productA` `src location: WH/STOCK` `dest location: from step 2` `storage category: from step1`

4. Create a receipt picking with a move for productA that will not exceed the storage categ. cap -> confirm the picking

5. Create another receipt picking with a move for productA that exceeds the storage categ. cap -> confirm -> fill out the quantity -> validate

6. Go to the storage location and view its quants, see it's more than the max capacity

**Cause of the issue:**
During the picking assignment, the current/pending quantity of the proposed location gets calculated. Prior to the 7dda6bb refactor on the `qty_done` field, this current/pending quantity was stored in the method in a local variable, coincidentally also called qty_done. It got changed to quantity in this commit, which is also the name of one of the method arguments that represents the quantity value of the current move line which is being validated.

Thus, the incoming quantity becomes the current quantity in the location which, of course, does not validate the defined cap.

**Fix:**
Rename the local variable.

opw-3926597

Forward-Port-Of: odoo/odoo#169746

Issue -->

With a large number of `account.move.line` and `pos.order.line` records, methods `_get_tax_details`, `_get_gstr1_hsn_json` and `_set_details_pos_lines` do not perform well.

Solution -->

In `_get_tax_details` -->

Replace the journal items recordset with a set of ids to do deletions. Move the fetch to when it is actually needed.

In `_get_gstr_hsn_json` -->

Prefetch the l10n_in_code values on `uom.uom` records that are used in the for loop. This optimization prevents additional hits to the backend.

In `_set_details_pos_lines` -->

Fetch `product.product` records and all the `uom.uom` records before the for loop to prevent additional hits to the backend when trying to fetch `product_id.type`, `product_id.l10n_in_hsn_code` and `product_uom_id.l10n_in_code`

Benchmark -->

For about 110k journal items and 95k pos order lines, the current implementation takes about 2800 seconds to finish computation.

After the fix, the process takes about 300 seconds to finish.

opw-3895401

Forward-Port-Of: odoo/enterprise#62305

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/odoo/pull/164316

Forward-Port-Of: odoo/enterprise#61928

**Steps to reproduce:**
	- Install Rental module
	- Check gantt view in Rental > Schedule

**Current behavior before PR:**
We are just showing the products that has orders. This is happening because in those commit https://github.com/odoo/enterprise/pull/37757/commits/0c2f235d4876467df287f30ab3cb09785603cd7f https://github.com/odoo/enterprise/pull/37757/commits/836909419893b522890776d3ec2f16476ae21108 we introduced the group limit and get_gantt_data and rental_schedule has not get adapted with this new behaviour.

So what is happening is that '_read_group_product_ids'
https://github.com/odoo/enterprise/blob/17.0/sale_renting/report/rental_schedule.py#L20
is not called as there is a limit so https://github.com/odoo/enterprise/blob/17.0/web_gantt/models/models.py#L76 This computes to be False so https://github.com/odoo/odoo/blob/17.0/odoo/models.py#L2745:L2754 '_read_group_fill_results' will not get called to call '_read_group_product_ids'

**Desired behavior after PR is merged:**
After override 'get_gantt_data' we are now checking if all products count is more than the limit we just return the products that already have orders.

**Other solution:**
We might just remove the group_limit https://github.com/odoo/enterprise/blob/17.0/sale_renting/report/rental_schedule_views.xml#L54 and just go with the '_read_group_product_ids'.

opw-3959031

Forward-Port-Of: odoo/enterprise#63720

**Steps to reproduce:**
- Install l10n_es_reports
- Switch to a Spanish company (e.g. ES Company)
- Create some invoices/bills and credit notes using different types of taxes
- Go to "Accounting / Reporting / Statement Reports / Tax Report"
- Select "Generic Tax Report"
- Click on "VAT Record Books (XLSX)" to download the report

**Issues:**
1) Credit notes appear as positive in the report
2) Withholding taxes (having type "Retencion") are not handled.
They should appear in the dedicated column.
3) Intra-European bills have a tax that is reverted. So the tax amount
should be 0, but it is not reverted in the report.
4) If an invoice has 2 lines that use 2 different taxes of type
"Recargo de Equivalencia", one of them will not appear in the report.
5) Advanced combinations of taxes on several invoice lines are not supported.

**Solution:**
This fix changes the way of generating the Libros Registro de IVA report.
Before this fix, the report was generated based on the tax lines.
One line of the report was corresponding to a regular tax line, which didn't
support advanced combinations of taxes on several invoice lines.
This fix analyzes the taxes repartition on the invoice lines and tries to respect it when generating the report.
A line of the report corresponds to a combination of taxes of different type:
(IVA + surcharge tax + withholding tax)

**Limitation:**
Having 2 taxes of the same type on the same invoice line is not supported.
The total and the tax amount will be correct but not the tax rate because
a report line has only one column to display each type of tax.

opw-3844967

Forward-Port-Of: odoo/enterprise#64681

To reproduce:
- Create an asset linear yearly.
- Reevaluate it next month, while decreasing the residual amount. 

=> The amounts don't make sense, the decrease move has been deleted.
     Idem for the move before the reeval.

The issue is that we delete all the moves that are draft. 
But if a move (like the decrease move) is created after the current day, 
it is in auto-post, and so, in draft.

To correct that, we prevent their deletion and give the correct residual amount 
(it is a computed non-stored field, so it has been given as an argument to the method).Another issue was found, related to already depreciated assets.
Create an asset with 10000 as original value, 4000 as Import amount
and 6000 as salvage value.
Confirm it (no moves should be created)
Sell or dispose it.

=> It creates a move before disposal while there shouldn't be any

The issue was that reevaluation didn't work with already depreciated assets and with no moves before the reevaluation.

opw-3945341

task-3444716

Forward-Port-Of: odoo/enterprise#65031
Forward-Port-Of: odoo/enterprise#62982