*: website_crm_partner_assign, website_customer, website_membership,
   website_partner

Commit [1] (alongside commits [2] and [3]) introduced a new context key `can_publish_unsudo_main_object` with the goal of properly computing `can_publish` without sudo... but it missed using it properly. The related test was passing... because it was also not properly written.

This commit fixes the issue by using the context key at the proper places. However, this limits the fix to pages and partners at the moment as the bug is not critical in stable versions.

It however fixes a test while run in no-demo (which becomes the norm in later versions). With that in mind, this also changes the view (by *adding* things to be as stable as possible) to go around the use of the context key and make new databases properly compute `can_publish` for all records type. Old databases will keep the old behavior for some models, which leads to displaying the "Publish" button but not be able to use it (access right warning).

[1]: https://github.com/odoo/odoo/commit/d47d824fc484e1592fc4af8d0d378d5a4a579550
[2]: https://github.com/odoo/odoo/commit/1a83b2508b9383e2b7df192f8641751f71f852da
[3]: https://github.com/odoo/odoo/commit/436a167dedb2ed008bcb88e8a4eccafc8d20812c

Related to runbot-161791

Forward-Port-Of: odoo/odoo#219636
Forward-Port-Of: odoo/odoo#219389

**Issue**:
Importing a vendor bill from XML may lead to two taxes being applied to the same product if:
- The product exists in the database.
- It matches a product reference in the XML.
- The product has a default service tax (e.g. 22% S).

**Steps to reproduce**:
- Create a product with a service tax (22% S).
- Ensure you have a test XML referencing that product (see tests for an example).
- Go to Accounting > Vendors > Bills.
- Upload the XML file.
- Observe that the product line has two taxes: 22% G (from XML) and 22% S (from product).

**Cause**:
Two taxes are applied because:
- The tax defined in the product: [Line 875 in `account_move_line.py`](https://github.com/odoo/odoo/blob/767341d4ec6aaa4fbd379827da4baf04e561eb32/addons/account/models/account_move_line.py#L875) which is triggered by [L1285C1-L1288C30 in `account_move.py`](https://github.com/odoo/odoo/blob/e705690d2340245a0d18b7e76347575dde9ea2be/addons/l10n_it_edi/models/account_move.py#L1285C1-L1288C30)
- Then, the XML tax is also added: [L1012C1-L1016C44 in `account_move.py`](https://github.com/odoo/odoo/blob/e705690d2340245a0d18b7e76347575dde9ea2be/addons/l10n_it_edi/models/account_move.py#L1012C1-L1016C44)

An attempt to reset the `tax_ids` after setting the product is already present:
  [Line 1319](https://github.com/odoo/odoo/blob/e705690d2340245a0d18b7e76347575dde9ea2be/addons/l10n_it_edi/models/account_move.py#L1319),
but it is ineffective because the original `tax_ids` are re-applied afterward, dues to side effects.

**Solution**:
There are two possible ways to fix this:
- Make sure `move_line.tax_ids = []` works as intended
- Clean the `move_line.tax_ids` recordset.

Chose the second option as it's simpler and avoids modifying unrelated code

**Additional Notes**:
The tax extracted from the XML does not take into account whether the product is a good or a service. For example, if the tax rate is 22%, the logic return taxes[0] if taxes else taxes will always return 22% G, even if the product should be taxed as 22% S.

To solve this, an extra domain filter is added based on the product type to ensure only applicable taxes are considered.

opw-4844469

In the following scenario, changes to the odoo.conf file could be lost:
1. A long-running process enters a `writable()` block (e.g. git checkout)
2. While it is still running, another process wants to update the conf file but gets blocked waiting for `writable()`. However it has already loaded the entire `odoo.conf` file into memory ready to write it back.
3. The first long running process now makes a change to the `odoo.conf` file. In the case of the checkout process, it is changing the `server_wide_modules` key.
4. The first process finishes and releases the `writable()` lock.
5. The second process now writes to the conf file, however it is using the now-stale version it held in memory from step 2.
6. The original changes to the conf file are lost.

The fundamental issue is that the `update_conf` function is loading the conf file into memory too early. To fix this, we aquire the `writable()` lock first, and then we can load the conf file knowing that it won't change until we are done.

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

Forward-Port-Of: odoo/odoo#219928

When a payment term with early payment discount is used on invoice the discount date is set on the payment term line based on the actual configuration of the payment term. When the invoice is posted, this date must not change anymore as it usually is what is communicated to the partner in order to apply EPD.

However, if the payment term's delay for discount is modified, the discount date from the move line was not taken into account by the payment register wizard or by the reconciliation widget, as it was instead recalculating a discount limit date, based on the configuration of the payment term at the time the payment is registered on Odoo.

Make sure it is the discount date that is stored on payment terms' account move line that is used to define if an early payment discount has to be applied.

OPW-4895365

Description of the issue/feature this PR addresses:

On runbot, create a new payment term with an early payment discount (eg 10% at 15 days, balance at 30 days).
Create a customer invoice with a invoice line (eg 100 USD) for any customer with this payment term and set the date to 10 days before today. Post the invoice, you can see on the payment term line that the discount is valid until 5 days after today.
Modify the payment term to set 10% at 5 days. If you go back to the invoice, you'll notice the discount date is still 5 days after today which is fine since this is what was communicated to the customer

Current behavior before PR:

Register a payment on this invoice and you'll notice the EPD is not applied because it gets the date from the actual configuration of the payment term instead of the date stored on the invoice's payment term line.

Desired behavior after PR is merged:

Register a payment on this invoice must apply the EPD as it is still valid based on the invoice's payment term line.

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

Steps to reproduce:
- Have the main company in USD
- Have 3 different currency rates in date 1, 2 and today
- Create a Vendor Bill in EUR in date 1
- Make Payment (EUR) in date 1, it should not have an associated move
- Create a Bank transaction, at date 2, matching the payment amount in EUR Bank Journal
- Make a batch payment including the created payment
- Open bank reconciliation of EUR Bank journal
- Select the transaction and the batch payment
- Validate

Issue: User Error will raise
```
The move (OTR/2017/00001) is not balanced.
The total of debits equals $ aaa and the total of credits equals $ bbb
You might want to specify a default account on journal "Bank other currency" to automatically balance each move.
```

This occurs because when retrieving the exchange rate values, amounts are converted using the payment values, computed at payment date. Later on, when we aggregate payment amounts, we convert manually the result without specifying a date, creating an issue in case the reconciliation date occurs after a rate change

**Steps to reproduce:**

- Install `sale_subscription`
- Create a recurring product (P1) and a non-recurring product (P2)
- Create a Sale Order (S1) with P1 (quantity > 0) and confirm it
- Create an upsell of S1 (new child order S2)
- In S2, edit the P1 line, and select P2
- Set quantity > 0 for P2
- Confirm S2

**Issue:**

After confirming the upsell order (S2), the quantity of P1 on the
original subscription (S1) is incorrectly increased by the quantity of
P2 from S2. The _compute_parent_line_id method did not reset the
parent_line_id when the product was not a subscription Product,
which caused it to incorrectly update the subscription

This issue is present in all three versions: **16.0, 17.0, and 18.0**.

**Solution:**

Reset parent_line_id to False if the product is not a subscription
product to prevent incorrect subscription updates.

[opw-4638955](https://www.odoo.com/odoo/project.task/project.task/4638955)

Forward-Port-Of: odoo/enterprise#90619
Forward-Port-Of: odoo/enterprise#88282

The system will crash when we receive nothing in `response` and also tryig to retrieve values from response.

**Error:-**
`TypeError: 'NoneType' object is not subscriptable`

**Root Cause:-**
- While we are in `EC Company`.
- When we click `Process Now` on the invoice. It will call `button_process_edi_web_services` method. And while in execution when at [1], `move.company_id._l10n_ec_is_demo_environment()` is `False`, then it calls `_l10n_ec_send_document` method.
- While submitting electronic invoices to SRI, the method `_l10n_ec_get_client_service_response_new()` sometimes returns `None` .
- It may also lack expected keys like 'estado' or 'comprobantes', depending on SRI’s behavior.

[1]
https://github.com/odoo/enterprise/blob/ce9eed675db4de3bcd1b283688c5c44d2e1ecf12/l10n_ec_edi/models/account_edi_format.py#L425-L428

**Solution:-**
- Wrapped the access to response and its keys inside a `try...except` block that catches:- 
   - `TypeError`: for cases where the response is `None`.


**Sentry - 6708486009, 6728767866**