## Issue: 
After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign.

## Steps to reproduce:
1. Get Sign module.
2. Upload any document to sign.
3. Add sign box and go to sign the document.
4. Now change from Auto to Draw.

## Solution: 
We should take into account that it makes sense that everytime we update if our signature is empty, we update the state of the buttons accordingly avoiding this way to be able to sign without an actual sing. The solution address a similar approach at what was already being done with the onChangeName, we move this logic to be handled by a specific function for this buttons 'handleButtonStateChange'.

The fix is part of > [#61981](https://github.com/odoo/enterprise/pull/61981)

opw-3874034

Forward-Port-Of: odoo/odoo#164410

Consider an invoice with a cash rounding method selected. The cash rounding is applied to the total of the invoice but not not the payment terms. Currently unrounded amounts can appear in the following cases
- Multiple payment term lines
- Discount on payment term lines

This is can also cause problems for the reconciliation. The cash rounded payment can not be reconciled with the non-cash-rounded payment term amount (since the amounts do not match exactly).

After this commit the cash rounding is applied to the payment terms:
- The amount of each payment term line is cash rounded
- The discounted amount of each payment term line is cash rounded

Reproduce:
  1. Install module `account` (or `account_accountant`)
  2. Create a payment term with 1 line with 10% discount when paid within 30 days. Ensure "Display terms on invoice" is on. (Invoicing / Accounting -> Configuration (menu) -> Payment Terms)
  3. Enable "Cash Rounding" in the settings
  4. Create a cash rounding with precision 0.05 and rounding method HALF-UP (Invoicing / Accounting -> Configuration (menu) -> Cash Roundings)
  5. Create an invoice
     - Payment term from step 2
     - Cash rounding from step 3 (set in "Other Info" tab) - A line s.t. the total is 868.35 (This value does not need cash rounding)
  6. Confirm the invoice
  7. Print the invoice: On the PDF the value 781.52 is shown for the payment terms. But the value should be 781.50 due to the cash rounding.
  8. Register payment: The amount 781.52 is suggested. But the value should be 781.50 due to the cash rounding. Changing the amount to 781.50 loses the automatic reconciliation.

task-4095505
opw-3985470

Forward-Port-Of: odoo/odoo#178344
Forward-Port-Of: odoo/odoo#176289

### Steps to reproduce:

- Enable multisteps route in the settings
- Create a storable product P and put 10 units in WH/Stock/Shelf
- Create and confirm an SO for 1 unit of P
- Go to the associated delivery and change the Source Location to WH/Stock/Shelf
- Back to the SO, click on the chart icon > view forecast
- Unreserve the 1 unit currently used by your picking

### Issue:

While you have 10 units in WH/Stock/Shelf perfectly suitable to fulfill the demand of the picking, instead of displaying a line allowing you to reserve the 1 unit, you have a line telling you that the qty is "not available" -1 unit associated with the SO.

If you go back to the SO: the chart icon is displayed red and the details displayed in the availability widget shows a: "No future availability".

### Cause of the issue:

The chart icon is red because the JS detects a forecasted issue: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/sale_stock/static/src/widgets/qty_at_date_widget.xml#L8 This issue comes from the fact that the demand is not expected to be fulfilled since the `free_qty_today` of the SOL is smaller than its `qty_to_deliver`:
https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/sale_stock/static/src/widgets/qty_at_date_widget.js#L45 https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/sale_stock/static/src/widgets/qty_at_date_widget.js#L54-L55 The reason for this forecasted issue is that the `free_qty_today` is computed to be -1 rather than 1 here:
https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/sale_stock/models/sale_order_line.py#L80-L82 since the `move.forecast_availability` is itself -1 rather than 1. Note that if the source of the move was still WH/Stock rather than WH/Stock/Shelf both of these value would be set to +1 and the issue would not appear. However, the `forecast_availability` of moves is not correctly computed if the location_id of the move is a strict sublocation of the warehouse. To be more precise, the forecasted availability is set to a negative quantity here:
https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/stock/models/stock_move.py#L470-L472 since the report line computed in the `_get_forecast_availability_outgoing` specifies that 'replenishment_filled' is False and should not be: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/stock/models/stock_move.py#L2228 We are finally at the core of the problem, the replenishement is not filled because in the `_get_report_lines`, the `currents` dict used to compute both the reserved and the on hand quantity only updates the quantity of the warehouse if the location belongs to the warehouse: https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/stock/report/stock_forecasted.py#L327-L330 As such, 0 units are considered to be available in these locations and nothing can be taken from stock for these moves:
https://github.com/odoo/odoo/blob/758ced91f8cb220a003a49b01e047b507f8509d7/addons/stock/report/stock_forecasted.py#L236-L242 which of course result in the impossibility to fulfill the replenishment

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

Forward-Port-Of: odoo/odoo#172106

Before this commit, event listeners set on inputs by the datetime picker
service would be removed in the callback of the `useEffect` hook,
meaning that these listeners could be unregistered before the actual
elements would be removed.

This is an issue in the specific case where the deletion of the element
occurs before the "change" event has been dispatched and after the
removal of the listeners. The thing is: the removal of the element also
triggers the "change" event (if it hasn't been triggered before), and
with the listener gone this means that the value is lost.

This commit deletes the removal of event listeners attached on inputs
by the hook. This has been done since using the datetime picker service
implies that the inputs affected by the feature will never be in an
interactive state without the datetime picker actively listening on
them.

Although a test case setup is easy to reproduce, this behavior is
unfortunately impossible to reproduce programmatically as the "change"
event dispatched by removing an element only works when a trusted
"input" event was triggered to change its value (setting the internal
browser "changed" value of the input).

Task [4104407](https://www.odoo.com/odoo/all-tasks/4104407)

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

Forward-Port-Of: odoo/odoo#178533

Currently, a traceback is occurring when the user tries to download a card 
for a child partner of type `other` having no name.

To reproduce this issue:

1) Install `Contacts`
2) Create a record in `Contact & Addresses` of type as `Other Addresses`
   in an existing contact
3) Now open the above-created contact
4) Download the Vcard for that record

Error:- 
```
AttributeError: 'bool' object has no attribute 'replace'
```

As you can see name is only required when the type is 'contact'.
When the user creates a partner record without a name and tried to download the Vcard, it led to a traceback.

Because the name was used in the Vcard, which is false in this case. https://github.com/odoo/odoo/blob/6abe8da981e10f56eb50d07e8c53dcf97422f0c4/addons/web/models/res_partner.py#L30

**Note:-** 
Also in the below line, `/web_enterprise/partner/<model("res.partner"):partner>/vcard`
route was never used anywhere in the Odoo except in one test case.

which was also introduced from the same PR through which the above route was added.
Because `Vcard` was initially in `enterprise` and later shifted to `community`.

https://github.com/odoo/odoo/blob/6abe8da981e10f56eb50d07e8c53dcf97422f0c4/addons/web/controllers/vcard.py#L16-L17

This commit will resolve this issue by taking the `complete name` 
when the partner record failed to provide the name.

sentry-5673082917

Forward-Port-Of: odoo/odoo#176166

## Issue: 
After the changes we have made to sign in 17.0 we stop properly handling the state of the buttons for submit our sign after signing, the problem then is that in Draw mode for example, we are able to submit the sign even before drawing anything, which will allow us to send the document "unsigned", since there will not be any sign.

## Steps to reproduce:
1. Get Sign module.
2. Upload any document to sign.
3. Add sign box and go to sign the document.
4. Now change from Auto to Draw.

## Solution: 
We should take into account that it makes sense that everytime we update if our signature is empty, we update the state of the buttons accordingly avoiding this way to be able to sign without an actual sing. The solution address a similar approach at what was already being done with the onChangeName, we move this logic to be handled by a specific function for this buttons 'handleButtonStateChange'.

The fix is part of > [#164410](https://github.com/odoo/odoo/pull/164410)

opw-3874034

Forward-Port-Of: odoo/enterprise#61981

When a user with 'user' access rigths on the project module that is also assigned to a task of an internal project, it will prevent the user from creating a new timesheet from the timesheet grid.

This bug is due to the fact that when a user clicks on the line of the task, some rpc's call are made on the 'project' model. Since the user does not have access rigth to the internal project on which the call are made, an access rigth error is raised.

Step to reproduce:
- create a db with hr_timesheet installed
- have a user with 'user' access rights on project and 'own timesheet' on timesheet
- create an internal project
- create a task inside that internal project and assigned the user on it
- connect with the other user
- open timesheet app
- select the task from the internal project to start a new timesheet timer
- an error access right on 'project' is triggered

Solution:
Add a sudo inside the python method 'check can start timer'. Give the project name to the timerHeaderM2O, to prevent the call to the name_get on the project.

task - 3922511
affected version 16.0 - master

Forward-Port-Of: odoo/enterprise#68933
Forward-Port-Of: odoo/enterprise#63159