Steps to reproduce:
- Create a new payment term; "days end of month on the 30"
- create an invoice in may
- set the newly created payment term
- create a invoice line
- save

Issue:
the due date (`maturity_date`) is 2024-06-29

Cause:
Use of `relativedelta` with the singular form of `month` -> absolute value

It was set to 2 so it would always give 29 -> year-02-29

and so  `days_next_month = relativedelta(days=min(int(self.days_next_month), (date_end_of_month + relativedelta(month=2)).day))`

would always return 29 since 29 <= (29, 30, 31)

```
>>> import datetime
>>> from dateutil.relativedelta import relativedelta
>>> date_end_of_month
datetime.datetime(2024, 5, 31, 17, 4, 14, 791820)
>>> (date_end_of_month + relativedelta(month=2))
datetime.datetime(2024, 2, 29, 17, 4, 14, 791820)
>>> min(31, 30, (date_end_of_month + relativedelta(month=2)).day)
29
```

Solution:
use the relative form of `relativedelta`; that is, the plural form `months`
```
>>> (date_end_of_month + relativedelta(months=1))
datetime.datetime(2024, 6, 30, 17, 4, 14, 791820)
```
source: https://dateutil.readthedocs.io/en/stable/relativedelta.html

Note:
Had to change the existing test on the overlapping year since
```
>>> december_date
datetime.datetime(2023, 12, 12, 0, 0)
>>> december_date + datetime.timedelta(days=30)
datetime.datetime(2024, 1, 11, 0, 0)
```
and from date the maturity date would be 31st of January

opw-3916451

Forward-Port-Of: odoo/odoo#166560

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

### Current Behavior:

- Go in the project app, click on a project and click on a task
- Change the stage of the task

The duration spent in the previous stage is displayed in the new stage.

Note: if you refresh the page the bug will disappear.

### Cause of the issue:

The `duration_tracking` of the `project.task` model is a non stored computed json field. During the computation of this field, the previous trackings of the object are retrieved from `mail.tracking.value` model: https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/mail/models/mail_tracking_duration_mixin.py#L45-L60 To be sure that these trackings will be correctly retrieved, the model used by the query are even flushed. However, these mail tracking values are only created at the end of the sql transaction because the `_track_finalize` method is part of the precommit hooks of the transaction and is hence only run during the general sql flush: https://github.com/odoo/odoo/blob/784f90d25614e4816ac3ed26f0643b562071edbd/odoo/sql_db.py#L134-L138 https://github.com/odoo/odoo/blob/784f90d25614e4816ac3ed26f0643b562071edbd/odoo/tools/misc.py#L1215-L1221 As such, the mail tracking values generated by the old value of the stage will only be accessible at the end of the transaction and will not be available during the computation duration_tracking run for the project task in its final stage. Leading to an incorrect computation of the field during onchanges:
https://github.com/odoo/odoo/blob/bb0cb2896236ead6b474cd1b3a685ff447716b95/addons/mail/models/mail_tracking_duration_mixin.py#L62-L64

### Fix:

In order for the the mail tracking values generated by the old stage to be present during the final computation of our duration_tracking we trigger the `_track_finalize` precommit hook on the records for which it should be run at the end of the transaction before the execution of our query.

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

Forward-Port-Of: odoo/odoo#161688

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

Previously, the floating icon wasn't an OWL component and has been
refactored into an OWL component. When refactored he lost the auto
move up top logic that came with the css classes 'o_bottom_fixed_element'
and 'o_bottom_fixed_element_move_up'

This commit reintroduce this auto move up behavior by default within the
OWL component by listening to the scroll event of the document and
identifying whenever we reach the end of the document. It is useful
so we ensure the users can click all links potentially present in the
footer. If the icon is dragged and moved elsewhere, we prevent this
smart behavior from happening until next refresh of the state.

Commit introducing the drag & drop feature :
https://github.com/odoo/odoo/commit/d9f07235484

Commit of the OWL refactoring :
https://github.com/odoo/odoo/commit/20c1772d

Steps to reproduce :

- Install LiveChat
- Toggle Mobile display
- Scroll down to the bottom of page
-> The livechat floating icon doesn't go up as it was before

task-3946855

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

Forward-Port-Of: odoo/odoo#169831
Forward-Port-Of: odoo/odoo#169383

Summary
-----
When creating an expense in a currency different from the company's currency, the exchange rate is rounded to 6 decimal places. If the rate and the expense amount are high enough, the rounding error affects the expense amount in the company's currency and later, in the journal entries created after the expense is approved.

Steps to Reproduce
-----
    1. Set a strong currency for the company (e.g., USD)
    2. Add a weak currency in the currencies (e.g., IQD)
    3. Create an expense with a high amount (e.g., 1,000,000 for the IQD/USD pair)
    4. Set the weak currency for the expense
    5. Observe the overly rounded amount in the weak currency

Cause
-----
The error comes from the exchange rate being rounded too much and too early.

Fix
-----
Modify "digits" attribute of the "currency_rate" field to increase precision.

Note
-----
Some inaccuracy remains, but expenses rarely exceed 1000 USD for companies using weak currencies, so the number of issues should be reduced.

opw-3684727

Forward-Port-Of: odoo/odoo#167606