…ating recurrent tasks

Steps to reproduce:
- Create a new recurring prepaid service product, and Create on Order: Project & Task or Task. 
- Enable "Recurring Tasks" in the setting and grant the current user "Use Recurring Tasks" access in the user configuration. - Create a new sale order, select that recurring product and a "Recurring Plan", confirm the sale order with the current user and check the task. 
- Duplicate the same sale order, confirm the sale order with the customer portal user in the portal view and pay. 

Current behaviour:
The task created by the current user is recurring. However, the other task that the customer created in the portal view is not recurring. Both of them should be recurring since the sale orders are the same. The person who confirms the sale order should not affect the status of the task.

Cause
It is checking if the user has the access right to create recurrent tasks. Where in this case, customers will always be portal users, and they will not have that access right.

Solution
Remove the check, since the recurrent attributes are already defined in the SO and Product.

Steps to reproduce:
- Install Contacts, Accounting and l10n_mx_edi_extended
- Switch to a Mexican company (e.g. ESCUELA KEMPER URGATE)
- Go to company form and configure its address (*)
- Create a US customer (e.g. Foreign Customer) (*)
- In Accounting settings:
  * activate "Customer Addresses"
  * use Mexican Bank for automatic currency rates (*)
- Configure a product for external trade (e.g. Office Chair) (*)
- Create an invoice: (*)
  * Customer: Foreign Customer
  * Delivery Address: [different than customer] (e.g. Deco Addict)
  * Journal in: USD
  * Usage: Without fiscal effects
  * Product: Office Chair
  * Incoterm: EX WORKS
  * External Trade: Definitive
- Confirm the invoice
- Try to generate CFDI via "Send & Print" button (it will probably fail)

(*) https://www.odoo.com/documentation/17.0/applications/finance/fiscal_localizations/mexico.html#external-trade

Issue:
Check the generated CFDI in CFDI tab.
The data for element `<cce20:Destinatario><cce20:Domicilio /></cce20:Destinatario>` are incorrect.
"Calle", "NumeroExterior", "NumeroInterior", "Pais" and "CodigoPostal" are coming from the current company instead of the delivery address.

opw-3715960

Forward-Port-Of: odoo/enterprise#60829

Before this commit when we have a synced event with google and then we toggle the all-day field
changes didn't reflect on google side

This happened because google uses two separate fields for start/end.
1. dateTime (used for normal events)
2. date (used for all-day events)

when one of them is set, the other must be null.
Before this commit when we did a patch update, we set only one, but forget about the other which raises an error.

Task: 3681668

==============================
I couldn't find it in google calendar api documentation supporting my claim. But I based my conclusion on these facts:

1. when sending a get request to google API for all-day events it would look like this, we can observe that for both start/end it doesn't have a `dateTime` but only `date`.
```js
{
    "kind": "calendar#event",
    "etag": "\"3420874125486000\"",
    "id": "11qeiguv96iei6nkd4helg421b",
    "status": "confirmed",
    "htmlLink": "https://www.google.com/calendar/event?eid=MTFxZWlndXY5NmllaTZua2Q0aGVsZzQyMWIgYWxhaEBvZG9vLmNvbQ",
    "created": "2024-03-14T10:39:50.000Z",
    "updated": "2024-03-14T17:24:22.743Z",
    "summary": "all day from google",
    "creator": {
        "email": "alah@odoo.com",
        "self": true
    },
    "organizer": {
        "email": "alah@odoo.com",
        "self": true
    },
    "start": {
        "date": "2024-03-20"
    },
    "end": {
        "date": "2024-03-21"
    },
    "transparency": "transparent",
    "iCalUID": "11qeiguv96iei6nkd4helg421b@google.com",
    "sequence": 2,
    "reminders": {
        "useDefault": false
    },
    "eventType": "default"
}
```

2. When doing the same for an event that is not marked as all-day. we would get this
```js
{
    "kind": "calendar#event",
    "etag": "\"3420880154840000\"",
    "id": "6ngnlju6nofaa0h478nkqgrhna",
    "status": "confirmed",
    "htmlLink": "https://www.google.com/calendar/event?eid=Nm5nbmxqdTZub2ZhYTBoNDc4bmtxZ3JobmEgYWxhaEBvZG9vLmNvbQ",
    "created": "2024-03-14T18:14:37.000Z",
    "updated": "2024-03-14T18:14:37.420Z",
    "summary": "aaa",
    "creator": {
        "email": "alah@odoo.com",
        "self": true
    },
    "organizer": {
        "email": "alah@odoo.com",
        "self": true
    },
    "start": {
        "dateTime": "2024-03-14T15:00:00+02:00",
        "timeZone": "Africa/Cairo"
    },
    "end": {
        "dateTime": "2024-03-14T16:00:00+02:00",
        "timeZone": "Africa/Cairo"
    },
    "iCalUID": "6ngnlju6nofaa0h478nkqgrhna@google.com",
    "sequence": 0,
    "reminders": {
        "useDefault": true
    },
    "eventType": "default"
}
```

so on google side, it's either `date` or `dateTime` but not both. Hence when doing a patch update for either `date` or `dateTime` we should unset the other.

### Steps to reproduce:
- Install **E-commerce** app
- Go to **Website** > **Shop**, and open a product
- Click on **edit** on the upper right corner.
- Double click the product image to change it. A popup is shown.
- In the popup, click on Add URL and place this URL [1]
- Click **Save**. The image disappears!

### Investigation:
- The issue was introduced here [2]
- As URL now starts with `/web/image/` which will be later used here [3]
- The condition to enter this line is `url_object.path.startswith('/web/image')`
- `item[field]` is used which equals to `attachment[datas]`
- But actually `datas` is empty as the image upload fails because of **CORS**
- `add_url` is called [4] saving attachment without `datas` but with type URL

### Fix
- The commit solves the issue by fetching the remote data from the server if the url is a remote redirection, which still happens when the image data cannot be fetched by the client browser at upload time.

[1]: https://lowendbox.com/wp-content/uploads/2022/09/odoo_logo_1200.png
[2]: https://github.com/odoo/odoo/commit/943944dd249c15de870d6800d89e48d54a422e5a#diff-0897c80484208197b0aff67f2b06509e864c3976de1589e3cebad2788eef008fR49
[3]: https://github.com/odoo/odoo/blob/f72968561acec164697a7a9ee0965ec304854dd5/addons/web_editor/models/ir_qweb_fields.py#L473
[4]: https://github.com/odoo/odoo/blob/f72968561acec164697a7a9ee0965ec304854dd5/addons/web_editor/controllers/main.py#L268

opw-3746245

Video to reproduce on runbot odoo:
https://github.com/odoo/odoo/assets/56789189/3e63fb2c-11b6-40f5-99e9-9c4f98f9ba60



STEP TO REPRODUCE:
-Create some expenses, create sheet for them and approve and then post journal entry.
-Go to journal dashboard to view the expense summary info and see only the number of the expense is display without the amount on it

REASON: since [1] the amount of the method
'_count_results_and_sum_amounts' will take the total_amount base on 'amount_total_company' if we have same currency else it takes the 'amount_total' to sum. Because at 'hr.expense.sheet' doesn't have amount_residual_signed like account.move has so we will use only 'amount_residual' to consider it as 'amount_total_company'

1: d8627c4e38ce9310197979dfbd5307810edf8201

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Currently, when you refund an order that was paid with bank, thus not rounded, the refund is rounded wich result in a difference between the original order and the refund. This also happens when the original order was paid with multiple payments and one of them was not rounded and the other was. The refund will be rounded as one single payment. This also results in a difference between the original order and the refund.

Steps to reproduce:
-------------------
* Setup a rounding method with a precision of 5.0
* Create a product with a price of 138.0
* Open the POS and add the product to the order
* Pay the order with 2 payments, one bank of 55 and one cash that will be rounded to 80.
* Validate the order
* Go in the backend and refund the order
* The refund will be rounded to 135.0

Why the fix:
------------
The new behavior after this fix:
* When refunding the entire original order, the amount to refund should be equal to what the customer paid on the original order (thus taking into account the rounding).
* When doing a partial refund, the amount that should be refunded correspond to the base price of the article(s) selected.

The issue was about the fact that refunds differed in prices compared to the original order. With this fix, there could still be a difference in the prices if a customer comes multiple times to do a partial refund and end up refunding the total order. This difference exists only if the original order was paid with rounding and will be maximum the rounding defined.

Since this is a rare event, we consider this difference to be acceptable.

Post-fixup:
-----------
The function `_get_rounded_amount()` was modified as we are not computing cash rounding when refunding anymore.

opw-3701574

Forward-Port-Of: odoo/odoo#162280
Forward-Port-Of: odoo/odoo#161564

### Steps to reproduce the issue:

1. Create a Storable Product and give it a UOM
2. Create an On Hand stock in a certain location
3. Go to Barcode and create a new Internal Transfer
4. Add the Product and with any quantity and click on Confirm (not Validate)
5. Edit the line of the Product (pencil icon), change the quantity and the UOM and click on Confirm
6. Validate the Transfer
7. Go back to the Product and click on the "On Hand" or the "Update Quantity" button
8. The reserved quantity is not null

### Explanation:

When you change `stock.move.line.product_uom_id`, `stock.quant.reserved_quantity` (using `product.product.uom_id`) is not changed to reflect the new `uom.uom.factor`. You then have two routes:

- In `stock_barcode`, `stock.move.line.product_uom_id` changes first, `stock.move.line.quantity` change is triggered through `stock.move.line._inverse_qty_done` afterwards.
https://github.com/odoo/enterprise/blob/d04b69ba03877a9b4aae82fb061dca23b1bfc4bc/stock_barcode/models/stock_move_line.py#L58-L61
When calling `stock.move.line._synchronize_quant`, `stock.move.line.quantity_product_uom` will use the new `stock.move.line.product_uom_id` while `stock.quant.reserved_quantity` still reflects the old `uom.uom.factor`.
https://github.com/odoo/odoo/blob/1b0dbb3645ad8b52c5260f1cbbc4f6bdee48461e/addons/stock/models/stock_move_line.py#L421-L422

(e.g.: going from `1 Dozens` to `2 Units` would give you `1.09 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`)

- There is a similar issue in _Inventory > Transfers > Internal_, where `stock.move.line.product_uom_id` changes at the same time instead. In that case, the whole operation will be done using the previous `stock.move.line.product_uom_id`, and changing `stock.move.line.product_uom_id` before changing `stock.move.line.quantity` would cause the same issue as in `stock_barcode`.

(e.g.: going from `1 Dozens` to `2 Units` would give you `2 Dozens` in `stock.quant.reserved_quantity` instead of `0.17`)

### Suggested fix:

The fix is made to be as simple as possible, the two conditions will be reduced to simple assignations:

- The first one will be `product_uom_id`, with which `uom.uom._compute_quantity` will be called.
- The second condition will be `quantity`, which will be set in a `vals.get` in the `qty` parameter of the compute.

To make everything uniform, there will be no exception where `stock.move.line.quantity_product_uom` is used.

opw-3798046

Forward-Port-Of: odoo/odoo#162169
Forward-Port-Of: odoo/odoo#160656

**Current behavior:**
Adding an attachment to a mail template record associated with
the survey invite wizard will not cause the attachment to
populate the relevant field when actually sending a new survey
invite email.

**Expected behavior:**
The attachments linked in the email template which is used by
the survey invite wizard will appear in the form when sending a
survey invite.

**Steps to reproduce:**
1. In settings, go to the email templates management page

2. Select the Survey: Invite template and upload some
     attachment

3. Go to the Survey application and click on one of the surveys
     listed, observe the lack of attachments despite having the
     email template with the attachment selected

**Cause of the issue:**
The survey invite wizard never uses its template's attachments
to modify/update its own attachment_ids field.

**Fix:**
Make the attachment_ids field a stored computed field.

opw-3709830

Forward-Port-Of: odoo/odoo#162273
Forward-Port-Of: odoo/odoo#152728