**Current behavior:**
If a recurring sale order has an associated sale order option and the recurring plan of the order is changed, a trace back occurs.

**Expected behavior:**
The recurring plan can be changed as it ordinarily would.

**Steps to reproduce:**
1. Add a recurring product to a sale order

2. Add an optional recurring product to the order

3. Try to change the recurring plan of the order to encounter the trace back

**Cause of the issue:**
This flow causes some 'phantom' sale order lines to have their price recalculated (phantom because they have no price, qty, currency, nor order_id field values). During this recalculation a currency_id is expected either in the line itself or in the sale order it is a part of. Because there is no value for either of these, it fails the ensure_one() method in the sequence (0 vals, expects 1).

The phantom lines are created in the `sale.order.option` model in the `sale_management` module, in `_compute_price_unit()` and `_compute_discount()`.

**Fix:**
Call `invalidate_recorset(flush=False)` on these cached records at the end of the methods in which they are created.

Test added in https://github.com/odoo/enterprise/pull/58264

opw-3754297

Forward-Port-Of: odoo/odoo#158950
Forward-Port-Of: odoo/odoo#157515

*: account_followup, account_reports, documents, frontdesk, room, sign,
   snailmail_account_followup, web_studio

This commit upgrades Bootstrap library from versison 5.1.3 to 5.3.3.

In a nutshell, the big changes are :
- A lot more CSS custom properties all over the place
- ScrollSpy has been completely rewritten (moving from onscroll listener
  to IntersectionObserver)
- Support for color modes (aka. light/dark modes ; but currently
  disabled as we don't take advantage of it yet).

Note: even though the new color modes have a lot of potential, as we
don't take advantage of it yet, the built-in dark mode is currently
disabled. It should be enabled once actually implemented.

This commit also removes the `.bg-text-*` helpers backported from
Bootstrap 5.2 (and now built-in) and an override of the
`Tooltip.prototype.setElementContent()` function as the Tooltip
component now delegates the its content assignation to the
`TemplateFactory` class.

References:
- https://getbootstrap.com/docs/5.3/migration

task-3600468

Related PR: https://github.com/odoo/odoo/pull/158560

Goals:

- Have a more accurate scheduler

Previously, the push notification system used a cron job that was executed once every hour. For the event module, having such delay can be really problematic as an event can start at any time. If an event starts right after the execution of the cron job, the users will be notified one hour after the begining of the event. The users could hence miss the event which is pretty unfortunate.

Now, the posts will be posted via a cron job that will be executed at a specific point in time. With the new cron jobs, the moment when the posts is actually posted will be much closer than the moment specified by the end-user. This is mainly due to the fact that the daemon process that executes the cron jobs will do a lookup once every minute.

- Improve the reliability of the scheduler

Thanks to the cron job, the system will also be more resilient: If the cron job crashes while sending the posts, the cron job will be
restarted and the system will be able to process the posts that have not been marked as processed (i.e: "posted" or "failed").

The system will guarantee an "at-least-once delivery" of the live posts meaning that there could be some potential duplicates in case of failures: If the server crashes after having sent the request to the external services and before marking the "live posts" as processed, the cron job will be restarted. It will then re-select the live posts that has not been marked as "processed" and will send another request to the external  services. As those services are not idempotent, the services will produce another post.

LINKS

Task id: 2336219

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#61088
Forward-Port-Of: odoo/enterprise#60829

# Introduction:

`JSON.stringify` was used to serialize the properties for the `/article`
command instead of the classical `encodeDataBehaviorProps` which also uses
`encodeURIComponent` above the `JSON.stringify`, to avoid having some special
characters as an attribute value.

# The issue:

`html_field.js:getEditingValue` is recovering the current value in the DOM using
`innerHTML` which converts some characters from tag attributes to HTML entities,
i.e.: `"` for `"`.

`mail.py:html_normalize` is using `lxml.html.tostring` is receiving such a
string with HTML entities, and is returning a string without HTML entities.

The database value (without HTML entities) is later given to the `html_field` as
a prop and is used as a comparison reference (`updateValue`) with the current
value in edition (that is still being converted to have HTML entities). Since
both values are different, the field is considered as dirty and in need of being
saved, which will trigger a write, even though the normalized value is the
same.

# Fix:

Using `encodeDataBehaviorProps` to serialize props as the Behavior anchor
attribute (like for any other Behavior) will prevent the use of characters that
are being converted to HTML entities.

In order to update existing `/article` blocks, the behavior will overwrite its
`data-behavior-props` attribute when it is mounted in edit mode.

task-3853291

Forward-Port-Of: odoo/enterprise#60985
Forward-Port-Of: odoo/enterprise#60177

# FIX] knowledge: remove useless popover

This commit fixes an issue where the popover would open inside the comments
panel when replying to a comment with a small enough window, even though in
this situation it's not useful at all.

Now when the panel is open and we have a small window, the popover will not
open when replying to a comment.

# [FIX] knowledge: show panel's comments in small windows

This commit fixes an issue with the comments panel when using it with a small
window.

Before, when you opened the panel when in a small enough window, the comments
aren't properly displayed meaning that you only have empty boxes inside the
panel. This was caused by a styling issue inside of the template that applied
a wrong style to the comment boxes inside panel, which is not necessary inside
it.

Now, we modified the inline style in the template so that it is not applied
inside the panel, showing back those comments in all circumstances.

task-3786282

Forward-Port-Of: odoo/enterprise#58045

Previously, it was easy to bypass the maximum_amount field on payment.provider by going to a subscription and clicking "Set Payment Method". The subscription would then be charged with the token, regardless of the maximum_amount set on the payment.provider.

This filters out ineligible acquirers through
_get_compatible_providers() so it's not possible to use them for new payment methods. The existing override wasn't working because sale_order_id was a string and sale.order('1').exists() always returns False. Casting sale_order_id to a string was added in a small /my/payment_method route override.

Filtering out already existing payment methods is harder because the sale order isn't available in _get_available_tokens(). Instead we raise a UserError when a user assigns an ineligible payment method. This is handled well in the frontend.

This focuses only on customer-facing flows. The maximum_amount field isn't checked either on e.g. account.payment but that's only accessible to internal users. Other customer-facing flows aren't affected because typically _get_available_tokens() is called with eligible payment providers as its first parameter.

Attempted alternative approaches:
- odoo/odoo#161021, odoo/enterprise#60294
- odoo/enterprise#60382

opw-3858340

Forward-Port-Of: odoo/enterprise#60482

Currently, receipts are not accounted for in the model 347 report (issue 1). The same happens for invoices for which a payment has been registered (issue 2).

### Setup

* install `l10n_es_reports`
* switch to a Spanish company

### Steps to reproduce issue 1

* with a new partner, create and confirm a customer receipt for more than €3005.06 (threshold for appearing in the report)
* open the model 347 tax report

We would expect the new partner to be listed in the report, but they aren't.

### Steps to reproduce issue 2

* with a new partner, create and confirm an invoice for more than €3005.06
* if you open the model 347 report, you will see the new partner listed there
* go back to that invoice and register a payment for it.
* open the model 347 report again

We expect the new partner to still be listed, but they are not.

### Cause

issue 1: receipts are missing in the corresponding domains.
issue 2: all account moves are used to calculate the threshold. This means that, for example, invoices and payments can cancel each other out in the calculation.

opw-3816370

Forward-Port-Of: odoo/enterprise#60432
Forward-Port-Of: odoo/enterprise#59343

Version:
-----------
saas-16.3

Steps to produce:
-------------------------
1. Open Sales or any other app.
2. Schedule an activity for Request Signature
3. Once the activity is scheduled, click on the Request Signature field
4. In the New signature Request pop-up click on cancel button ->Traceback occurs

Issue:
--------
A traceback occurs when we click on Request Signature after creating any Request Signature activity and click on cancel button.

Cause:
---------
The error occurs because when the cancel button is clicked, the onUpdate component is triggered to load and update the ID. However, a special parameter is passed incorrectly, leading to an error.

Fix:
-----
The issue can be resolved by changing the props from onUpdate to reloadParentView, the component correctly reload the parent view upon cancelation, This prevents the traceback error by ensuring that the activity is updated appropriately.

task-3768008

Forward-Port-Of: odoo/enterprise#60243
Forward-Port-Of: odoo/enterprise#58729

Currently, when trying to settle due accounts though the PoS session, the due balance doesn't change on the customer form.

Steps to reproduce:
-------------------
* Install **Point of Sale** and **Accounting**
* Go to the **Point of Sale** App
* Open a shop session
* Navigate to a customer with a due ammount and select **Details**
* Select **Settle due accounts**
* Select any payment method
* Validate
* Close session
* Under **Orders** select **Customers**
* Select the customer for which you just settled the due accounts
> Observation:  The due amount hasn't changed.

Why the fix:
------------
The following commit introduced a new relational system to be able to access data within the PoS frontend in the same way as it is done within the ORM in python: https://github.com/odoo/enterprise/commit/bb06fdead097bdec1582e3cdecb99fa63c2ff799

This commit modified the definition of `paylaterPaymentMethod`. Before the commit, it was defined as: https://github.com/odoo/enterprise/blob/4a5bb11bd59dd76f2df957225bf25d38ad5beb0c/pos_settle_due/static/src/overrides/components/payment_screen/payment_screen.js#L23-L26 and would return `{id: 3, name: 'Customer Account', is_cash_count: false, use_payment_terminal: false, split_transactions: true, …}`

Now it is defined as
https://github.com/odoo/enterprise/blob/daf09109a209f87e4f2fbb3275f55095e48d8b4d/pos_settle_due/static/src/overrides/components/payment_screen/payment_screen.js#L23-L26 and returns `undefined`.

We also notice a change in the value of `this.pos.config.payment_method_ids`. Where it previously returned
```js
Proxy(Array) {0: 1, 1: 2, 2: 3}
  [[Handler]]: Object
  [[Target]]: Array(3)
    0: 1
    1: 2
    2: 3
    length: 3
  [[Prototype]]: Array(0)
  [[IsRevoked]]: false
```

It now returns
```js
Proxy(Array) {0: Base, 1: Base, 2: Base}
  [[Handler]]: Object
  [[Target]]: Array(3)
    0:  Base {models: {…}, records: Proxy(Object), model: {…}, _raw: {…}, id: 1, …}
    1: Base {models: {…}, records: Proxy(Object), model: {…}, _raw: {…}, id: 2, …}
    2: Base {models: {…}, records: Proxy(Object), model: {…}, _raw: {…}, id: 3, …}
    length: 3
  [[Prototype]]: Array(0)
  [[IsRevoked]]: false
```

Thus we need to use `.some()` to retreive the id.

opw-3802560

Forward-Port-Of: odoo/enterprise#60655
Forward-Port-Of: odoo/enterprise#59626

**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)
  * Product: Office Chair
  * Incoterm: EX WORKS
  * External Trade: Definitive
- Confirm the invoice
- Generate CFDI via "Send & Print" button

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

**Issue:**
A traceback is raised because an inexisting method (i.e. `_get_customer_cfdi_values`) is called.

**Cause:**
The missing method has been renamed from "_l10n_mx_edi_get_customer_cfdi_values" to "_get_customer_cfdi_values" during a refactoring, but the original method has been deleted without implementing the new one.

**Solution:**
"_l10n_mx_edi_get_customer_cfdi_values" method was used to generate the data for the delivery address without altering the existing CFDI values.
These data were used to populate the external trade data of the CFDI.
"_add_customer_cfdi_values" method is similar to removed "_l10n_mx_edi_get_customer_cfdi_values" method, except that it also updates "receptor" in the CFDI.
It is used with a copy of the cfdi values to compute the values for the delivery address.

opw-3849153

Forward-Port-Of: odoo/enterprise#60758

…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