Versions
--------
- 17.0+

Steps
-----
1. Have a coupon program;
2. add a 10% discount on order reward for 1 point;
3. add a 50% discount on order reward for 5 points;
4. generate a coupon with 10 points;
5. use coupon code on a confirmed order;
6. select 10% discount reward;
7. change to a 50% discount reward;
8. check coupon point total.

Issue
-----
Even though the 5 point reward was used, only 4 out of 10 points remain.

Cause
-----
When updating the reward line of a confirmed order, it keeps track of point cost changes before & after a write. Its purpose is to restore back the point difference on the coupon record.

The issue is that while point changes are stored, coupon changes are not. When updating reward lines, `_reset_loyalty` is used, which removes the `coupon_id` from the lines. As a consequence, attempting to restore the point difference on `line.coupon_id` after an update, it writes to an empty record.

Solution
--------
Store both coupons & their used points before write. After write, restore the previous points to the previous coupon, and subtract the current point cost from the current coupon.

This way, any combination of coupon/point changes should have the points updated as expected.

opw-4910922

Forward-Port-Of: odoo/odoo#230907
Forward-Port-Of: odoo/odoo#222054

### Steps to reproduce:

- In the settings enable: "Batch, Wave & Cluster Transfers"
- Create 2 deliveries
- Barcode > operations > Delivery orders > Batches > New
- Add your two deliveries and confirm
- Scan WH-Stock
#### > The scan fails considering you scanned each letter independently.

### Cause of the issue:

When the barcode is scanned a call of the split barcode will be launched to split the barcode in multiple barcodes according to the `barcode_separator_regex` present in the config:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/models/barcode_model.js#L613-L632 The issue lies in the fact that even thought the is `barcode_separator_regex` was conrrectly populated at the onWillStart of the mainComponent:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/components/main.js#L209-L213 https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/controllers/stock_barcode.py#L97 https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/components/main.js#L229 https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/models/barcode_picking_model.js#L36-L38 It was reset by the batch confirmation here:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L123-L135 because this part of the config is not meant to be returned by the private method `_get_barcode_data` but rather by public complete version `get_barcode_data`:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/controllers/stock_barcode.py#L91-L98 Now, since no `barcode_separator_regex` was provided to our new config, each character will be considered to be considered as an independent barcodes and the `WH-Stock` barcode will not match any location.

opw-5062331

Forward-Port-Of: odoo/enterprise#95295
Forward-Port-Of: odoo/enterprise#94056

To reproduce:

1. Manually modify the SO view `view_order_form` notebook SO lines list view to make visible any column before `product_id` For example:
https://github.com/odoo/odoo/blob/18.0/addons/sale/views/sale_order_views.xml#L521 making the field `display_type` visible
2. Run the tests of `sale` module

=> `sale` module tests will fail on test `test_sale_combo_configurator_preconfigure_unconfigurable_ptals`

```
FAILED: [18/22] Tour sale_combo_configurator_preconfigure_unconfigurable_ptals → Step Verify that configurable ptals are now configured (trigger:
        .sale-combo-configurator-dialog
        .combo-item-grid
        .product-card:has(.card-title:contains("Test product"))
    :contains("Attribute B: B")).
Element (
        .sale-combo-configurator-dialog
        .combo-item-grid
        .product-card:has(.card-title:contains("Test product"))
    :contains("Attribute B: B")) has not been found.
TIMEOUT step failed to complete within 10000 ms.
```
see runbot build fail at:
https://runbot.odoo.com/runbot/build/89552334

The issue happen as - for some dark magic JS/XML reason - adding the field before product_id make fail the step to click the checkbox using the span.

Fix was suggested by PIPU to solve/workaround the issue

In practice, this issue was discovered accidentally with a customisation which was willing to add a custom field at the start of the list

opw-5068699

Forward-Port-Of: odoo/odoo#228029

Using standard Odoo, `maintenance.request.close_date` should never be `False` when its `stage_id == 'done'`, but customizations/manual overrides allow users to force it to be `False` and block them from opening equipment views that displayed fields that depended on it.

Steps to reproduce:
- Create new maintenance request for an equipment
- Put maintenance request into a `maintenance.stage` where `done=True` (e.g. "Repaired")
- Force `close_date` to not be `readonly` in form view + set it to `False`
- Try to open the assigned equipment's form view

Expected result:
Form view opens without issue

Actual result:
`unsupported operand type(s) for -: 'bool' and 'datetime.date'`

Issue was due to `mttr` calculation in `_compute_maintenance_request` not expecting `close_date` to be `False`. Since we want the request to still be considered for the rest of the compute, we count its "Time to Repair" as 0 in this case since we cannot use infinity in this case. Additionally, we also gracefully fail in the same way in case `request_date` is also forced to be `False` since it is not a mandatory field and can cause the same issue.

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

Forward-Port-Of: odoo/odoo#230942
Forward-Port-Of: odoo/odoo#230821

**Issue**
The lunch order merge logic was causing orders to be unexpectedly archived when they shouldn't be. Users would see their orders disappear from the list view after certain operations like clicking "Receive" multiple times or when trying to merge orders with existing ones in immutable states.

**Steps to Reproduce**
1st problem
- Create a lunch order
- From the order list view, select the order and click the "Receive" button
- Select and click the "Receive" button again on the same order
- The order gets archived and disappears from the view

2nd problem
- Create a lunch order
- From the order list view, select the order and click the "Receive" button
- Place another order for the same product as before
- From the order list view, once the second order is set to received, it gets archived and the update quantity logic not triggered

**Root Cause and Solution**
1st problem: When searching for matching orders to merge, the current order being processed could match itself, leading to self-deactivation. Fixed by adding matching_lines = matching_lines - line to exclude the current record from potential merge targets.

2nd problem: The merge logic was trying to combine new orders with existing "sent" and "confirmed" orders, but the update_quantity method correctly excludes these states since they shouldn't be modified once sent/received. This created a mismatch where orders would be archived but quantities wouldn't update. Fixed by excluding "sent" and "confirmed" states from merge target searches entirely.

Task ID: 5123211

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

Forward-Port-Of: odoo/odoo#229084

[FIX] account: set correct links between invoices and payments
The problematic found case was the following:
- Create an invoice and register a payment for it, using the wizard,
with a journal having an outstanding account set
- Use the smart button on the invoice form view to open the payment and
reset it back to draft
- Duplicate the payment, confirm the new one and reconcile it with the
invoice

=> If we go back to the invoice form, the smart button linking payments
is now redirecting to the 1st payment, that's in draft state, instead of
the second confirmed one.

This is because there can be 2 types of links between payments and
invoices:
- When there's no journal entry for payment, the link is done via the
Many2many table 'account_move__account_payment'.
- When there's a journal entry, the link is done via the table
'account.partial.reconcile'.

Before this commit, the button on the invoice form view was based on
account_move__account_payment and wasn't looking at all at
account.partial.reconcile as one would expect.

To solve that, we now look at reconciled_payment_ids that is computed
as the union of account_move__account_payment and
account.partial.reconcile.

Task-4613193
Runbot: https://runbot.odoo.com/runbot/bundle/18-0-outstanding-double-link-roto-354130

Forward-Port-Of: odoo/enterprise#96926
Forward-Port-Of: odoo/enterprise#89089

[FIX] account: set correct links between invoices and payments
The problematic found case was the following:
- Create an invoice and register a payment for it, using the wizard,
with a journal having an outstanding account set
- Use the smart button on the invoice form view to open the payment and
reset it back to draft
- Duplicate the payment, confirm the new one and reconcile it with the
invoice

=> If we go back to the invoice form, the smart button linking payments
is now redirecting to the 1st payment, that's in draft state, instead of
the second confirmed one.

This is because there can be 2 types of links between payments and
invoices:
- When there's no journal entry for payment, the link is done via the
Many2many table 'account_move__account_payment'.
- When there's a journal entry, the link is done via the table
'account.partial.reconcile'.

Before this commit, the button on the invoice form view was based on
account_move__account_payment and wasn't looking at all at
account.partial.reconcile as one would expect.

To solve that, we now look at reconciled_payment_ids that is computed
as the union of account_move__account_payment and
account.partial.reconcile.

Task-4613193
Runbot: https://runbot.odoo.com/runbot/bundle/18-0-outstanding-double-link-roto-354130

Forward-Port-Of: odoo/odoo#231140
Forward-Port-Of: odoo/odoo#202076

**PROBLEM**
When hiding a HtmlField field from a view with pending images in it, there is a traceback.

**STEP TO REPRODUCE**
1. Using studio, create a HtmlField on the view of your choice.
2. Add a checkbox next to it, and link the HtmlField visibility to the button.
3. Add a image to the HtmlField (don't save the record !)
4. Hide the HtmlField using the checkbox, there should be a traceback. (if not, try with a bigger image).

**CAUSE**
commitChanges() will try to retrieve the field value to commit by looking at the related element in the DOM. Before retrieving this value, we call savePendingImages() to save the new images added to the HtmlField. https://github.com/odoo/odoo/blob/1416aad902a97ce56aaecc2aadc4dd9f7814ee53/addons/html_editor/static/src/fields/html_field.js#L159-L162 This introduces a delay, during which the DOM element could be destroyed.

**FIX**
We don't call commitChanges() in OnBlur(). Instead, we cache the new value in a property of HtmlField called `newValue` when `OnChanges()` is called. Inside OnBlur(), we save the pending images by directly calling `savePendingImages()` and we commit the new value by calling `updateValue(this.newValue)`

opw-5061820

Forward-Port-Of: odoo/odoo#227482

Problem: When there is an obligation type code with id greater than 9, and it is selected in the dropdown of the website sale address form for obligation type, the screen keeps loading forever and there is an “expected singleton” traceback in the logs. This is because in the method `_parse_form_data` in `l10n_co_website_sale`, the obligation type field on `form_data` is set to be a  list of “type ids” which leads to an error when `convert_to_cache` is called as the browse function in this attempts to convert the list to a tuple of single characters. For example, if the list is ["10"], it gets converted to ("1","0") hence leading to the expected singleton traceback.

Purpose: Instead of passing a form list to form_data,we pass the record set which will correctly set the values in the address, much like how `default_obligations_ids` is also currently set. After this correction, the website address screen will save the address properly and redirect to the delivery screen for further actions.

Steps to Reproduce on Runbot:
1. Create a Colombian company, make sure l10n_co is installed
2. Set the company on the website to this company
3. Ensure that there is a record in the table `l10n_co_edi_obligation_type_ids` with id > 9. Create one if it does not exist.
4. Open the /shop page in incognito mode as a public user.
5. Add a product, go to the checkout page, proceed to the address page.
6. Enter all the information including the Identification Number (e.g. 623.456.789-1). Choose “NIT” in identification type and select the type code from step 3 in the dropdown for obligation type. Choose country “Colombia” along with a state and city 
7. Click on "Continue checkout". The page gets stuck in a loading state
 forever.

opw-4776301

Forward-Port-Of: odoo/enterprise#90862

Recently pull request https://github.com/odoo/enterprise/pull/86084 introduced an ondelete method on `ir.model` that retrieves some worksheet templates to delete them.  However, this method breaks when uninstalling module `worksheet`:
```
ir.model.data._module_data_uninstall():
    ... records are deleted ...
    ir.model.fields.unlink():
        drop column of corresponding fields
        delete ir.model.field records
    ir.model.unlink():
        drop table of corresponding models
        ir.model._unlink_if_uninstalling():
            self.env['worksheet.template'].search([('model_id', ...)]).unlink()
        delete ir.model records
```
The call to `ir.model.unlink()` crashes when searching for worksheet templates, since column `model_id` has been dropped already.  This makes the transaction fail, and it is rolled back to a savepoint just before the call to `ir.model.unlink()`.  In other words, the uninstallation manages to drop most of the columns that must go, but fails to drop all the tables that must go.  And the uninstallation proceeds anyway...

Now consider uninstalling module `resource`.  That module defines model `resource.calendar` with required field `name`, and also defines a record in that model (a default calendar).  When the module is uninstalled, module `worksheet` is also uninstalled (because it depends on `resource`), and so the situation above happens.  Consequently, most of the columns of table `resource_calendar` are dropped, but the table is not.  If we reinstall module `resource` after that, the ORM re-creates column `name` (which is `NULL` on the default calendar at least), but fails to add the `NOT NULL` constraint on that column.

The fix consists in avoiding the `search()` above in the ondelete method if the column `model_id` does not exist anymore.

Forward-Port-Of: odoo/enterprise#96845

Improvements introduced by https://github.com/odoo/odoo/pull/197702 streamlined the auto formating of iterables to lists when passed as an argument to translatable strings in Odoo.

While doing so, strings were ignored (to prevent formating them as a list of the individual characters), but they failed to account for the fact that **byte strings** might also be passed as arguments in certain parts of the code.

An example can be found here:
https://github.com/odoo/odoo/blob/f037c39ad4d33384f81a418cb63fcdd6a5085d56/odoo/addons/base/models/ir_mail_server.py#L265-L278

`repl` in this context will be a byte string object returned by the SMTP connection.

## BUG:

Before the fix, if you would pass a byte string as an argument to a translatable string using keyword templating, the output would be the raw representation of the bytes as a list instead of the human readable content.

For example if we use in a french localisation:
`raise UserError(_('The server refused the test connection with error %(repl)s', repl=b'TEST byte string'))`

Before the fix we could get:
`Le serveur a refusé la connexion de test avec l'erreur 84, 69, 83, 84, 32, 98, 121, 116, 101, 32, 115, 116, 114, 105, 110 et 103`

And after the fix:
`Le serveur a refusé la connexion de test avec l'erreur b'TEST byte string'`

## Proposed fix:
In the same way that we ignore `str` arguments before auto applying the `format_list` method, we will also ignore them if the type is `bytes`

OPW-5107313

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

Forward-Port-Of: odoo/odoo#231179