Steps to reproduce:
- Enable Rental pickings
- Create a rental for a product, for 4 quantity
- Process the delivery
- Open the barcode app and open the reception
- Scan the product once and validate

Issue:
The receipt is validated without issues nor warning, despite being incomplete.

This is due to a bad mix of two changes:
- #60801, which always sets the rental receipt as return of the delivery
- #48788, which removes the backorder check for returns in barcode

For regular returns made in barcode, it makes sense to avoid the backorder check, as from here we're processing a full picking return and we'd have the confirmation pop every time.

However, things are different for rental receipts, as despite them being set as returns of the delivery, they're proper receipts that need to handle the partial receipt.

To avoid the issue, rather than removing the backorder check whenever there's a return linked to the picking, now also checks that there isn't a rental order linked to the picking.

opw-5265874

Forward-Port-Of: odoo/enterprise#101387

When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to generate a global invoice for the mexican localization.

Steps to reproduce:
-------------------
* Activate the global discount option in any PoS
* Open PoS and make a sale with a global discount
* Refund the sale without including the discount
* Go to the backend
* Go to the order list and select the 2 orders you made
* Now try to create a global invoice
> Observation: The global invoice is in error because the negative lines
  cannot be distributed correctly.

Why the fix:
------------
To avoid this issue with the global invoice we simply prevent the user to generate a refund with a greater amount than the original order. We only apply this limit to the mexican localization because it's the only module that is affected by this issue. Other localizations can still refund without restrictions even if this work flow does not really make sense.

opw-4899501

Forward-Port-Of: odoo/enterprise#100780
Forward-Port-Of: odoo/enterprise#93101

### Issue:
When changing the "Customer Reference" on an invoice, the name of the payment term line is not updated.

### Steps to reproduce:
- Create an invoice with payment terms, confirm it
- Modify its "Customer Reference" to 'test' for example
- In the page "Journal Items" the name of the terms line has been recomputed to "test - INV/2025/XXXXX"
- Modify again its "Customer Reference" to 'abcdef' for example
- In the page "Journal Items" the name of the terms line was not recomputed

### Cause:
In `_compute_name()` we only write the name if this condition is `True`:
```py
if n_terms > 1 or not line.name or line._origin.name == line._origin.move_id.payment_reference or (
        line._origin.move_id.payment_reference and line._origin.move_id.ref
        and line._origin.name == f'{line._origin.move_id.ref} - {line._origin.move_id.payment_reference}'
    ):
    line.name = name
```
The purpose of this line is to keep the name of the line if it was manually inputted. So the logic is: we only write the computed name if the previous name was computed. To check this, we check if `line._origin.name == f'{line._origin.move_id.ref} - {line._origin.move_id.payment_reference}'`.

The issue comes from the use of `_origin` in a compute. `_origin` refers to the record before we make any change. But it is meant to be used for `onchange` methods, in these the values are not yet written so `_origin` refers to the record before saving.
Here, when saving, `line._origin` is the same as `line`, so 
- `line._origin.move_id.ref` is the new ref.
- `line._origin.name` uses the old ref (it's currently being recomputed).

### Solution:
Unfortunately, in the compute, there are no trace left of what were the previous values as the write already occurred.

The initial complaint justifying to keep custom line names was that on bills, the line name is empty. So when inputting a custom line name, it was removed by the compute method. The previous fix wanted to be more general by always keeping custom line names.

Considering this, this commit removes part of the previous fix: Now we only keep the custom line name when the compute method wants to remove it. So we keep the previous fix for bills.

### Note
There was a test verifying exactly that when manually deleting the line name, in the end
the line does not have a name. This will no longer be the case but a decision must be made between:
1. updating the line name when changing the ref
2. not recomputing line name when it has been changed manually
3. removing the line name when it's manually deleted

We can have 2 and 3 but not with 1 afaik.

opw-5246917

Forward-Port-Of: odoo/odoo#237710

When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to generate a global invoice for the mexican localization.

Steps to reproduce:
-------------------
* Activate the global discount option in any PoS
* Open PoS and make a sale with a global discount
* Refund the sale without including the discount
* Go to the backend
* Go to the order list and select the 2 orders you made
* Now try to create a global invoice
> Observation: The global invoice is in error because the negative lines
  cannot be distributed correctly.

Why the fix:
------------
To avoid this issue with the global invoice we simply prevent the user to generate a refund with a greater amount than the original order. We only apply this limit to the mexican localization because it's the only module that is affected by this issue. Other localizations can still refund without restrictions even if this work flow does not really make sense.

opw-4899501

Forward-Port-Of: odoo/enterprise#100780
Forward-Port-Of: odoo/enterprise#93101

Description
-----------
Following odoo/odoo@238a41e35280256382f6509182b9e900fb4f7aba, the domain for `sale.order.line` in `_get_sale_order_items_query` was modified to search based on the relevant `order_id` `id` or `project_id`. `project_id` is not indexed, leading to a heavy non-selective scan on the primary key for databases with many `sale. order` records. There is poor selectivity with the filter on `sale. order.line` resulting in a heavy join between `sale.order` and `sale.order.line`.

This commit adds the missing index, allowing for `Bitmap Heap Scan` on both indexes and leveraging the selectivity of the project being currently opened.

Benchmark
---------
On a database with 3.5M `sale.order`, 12M `sale.order.line`, opening the "Settings" page of a project with a few sale lines associated with it took:

|              | Before | After |
|--------------|--------|-------|
| Timing (hot) | 9.1s   | 5ms   |

Reference
---------
opw-5280364

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

Forward-Port-Of: odoo/odoo#238995

Steps to reproduce:
- Enable Rental pickings
- Create a rental for a product, for 4 quantity
- Process the delivery
- Open the barcode app and open the reception
- Scan the product once and validate

Issue:
The receipt is validated without issues nor warning, despite being incomplete.

This is due to a bad mix of two changes:
- #60801, which always sets the rental receipt as return of the delivery
- #48788, which removes the backorder check for returns in barcode

For regular returns made in barcode, it makes sense to avoid the backorder check, as from here we're processing a full picking return and we'd have the confirmation pop every time.

However, things are different for rental receipts, as despite them being set as returns of the delivery, they're proper receipts that need to handle the partial receipt.

To avoid the issue, rather than removing the backorder check whenever there's a return linked to the picking, now also checks that there isn't a rental order linked to the picking.

opw-5265874

Forward-Port-Of: odoo/enterprise#101387

Step to reproduce:
- Install l10n_in_hr_payroll.
- Create 3-4 employee with labour welfare fund, all in different departments.
- Open the LWF report wizard and do not select any department.
- Download report , all employee will come in report.
- Now select any department and download report again.
- All employee(It is fetching previous data) + employee from selected
  department will come in report.

Cause:
- In '_compute_line_ids()' wizard computed field 'line_ids' doesn't properly
   reset previous lines as a result previous data remains in lines.
- When the department is changed, the wizard id remain same,
  so previously lines added to wizard are coming with new lines.
- Using `Command.link()` for new lines is invalid because it requires an
  existing database record ID, but wizard lines are creating inside a compute
  method so their IDs are only saved after the flush.

Fix:
- Since this is a stable version, clear the previously existing lines using
  'Command.clear()' before creating new ones.

Task - 5366498

#### [FIX] snailmail_account_followup: fix address, cover page and layout

Currently there is the following potential problem when sending
the followup report via snailmail.
1. The address generation is not adjusted for snailmail. That can
   lead to problems with the service we use to send the actual letter.
   They validate the address rather strictly.
2. The cover page option does not work; it does not add a cover page.
   So we can not work around problems with the address generation
   by adding a cover page.
3. The layout / dimensions / margins of the generated document / PDF may not work
   with our current snailmail provider (Pingen). But there is no error
   message about it. (Although we do have something in the usual
   snailmail flow)
4. In case the address is invalid we do not try to "print" / send the letter,
   so the user does not receive any feedback.
   This could be an issue in case multiple follow-up reports are sent
   at the same time.

This commit fixes these issues. (See below for details.)

(1)
The logic for this already exists but it is only activated when
a context key is set. This is not the case currently.
After this commit we do set the key.

(2) & (3)
The issue is that we generate the PDF attachment before creating the
'snailmail.letter' record.
In the usual snailmail flow the PDF attachment generation is handled during the sending and
printing (in function `_fetch_attachment` on model 'snailmail.letter').
There is some special logic to
- add a cover page to the report PDF (if the option is selected)
- make sure the page dimensions of the PDF are okay
- overwrite the margins of the PDF with white to make sure the PDF is
  not rejected by Pingen because of this

But all this only happens if we do not have an attachment already.
(So it does not happen currently with the followup report)
For this a function called `_generate_report_pdf` was extracted from `_fetch_attachment`
in the related community commit to generate the report PDF (and its
filename). The function is extended here to be able to generate the
followup report.

(4)
We try to print / send the letter even if the address is invalid

Reproduce (i.e. for the cover page issue; but it explains how to get
the PDF that will be sent in general)

1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Set the "Add a Cover Page" option
   (Settings -> Accounting -> section "Customer Invoices")
   - enabled to test for the cover page
   - disabled to test that the address generation is adjusted
4. Send a follow-up report:
   - On 17.0: Accounting -> menu: "Customers" /  "Follow-up Reports"
     -> click on a line / partner -> button "Follow up"
   - On 18.0+: partner form view -> tab "Accounting"
     -> section "invoice follow-ups" -> button "Send"
5. Go to the snailmail letter:
   In debug mode: Settings -> menu: "Technical" -> section: "Email" -> "Snailmail Letters"
   (or just search for "snailmail" in the main screen)
   And select the letter
6. Download the PDF document

#### [FIX] snailmail_account_followup: forbid regenerating failed letters

The wizard to resend failed letters which allows to change the
cover page option is broken: The follow-up report can not be regenerated
correctly because it requires special follow-up specific `options` that are
lost after the initial pdf generation for the letter.

Currently it can happen that the follow-up PDF is regenerated but
without (actual) content (table listing the overdue amounts).

After this commit we cancel the snailmail letters and show an
error notification indicating that the followup needs to be done again to
create a new letter.

Reproduce
(needs credit on IAP or locally edit this function https://github.com/odoo/odoo/blob/3ffd51f1cb18e3f4fb0367c4a498d7438e0c0357/addons/snailmail/static/src/core_ui/message_patch.js#L11
to open the resend wizard `this.openFormatLetterAction()` for `sn_credit` error or always)

1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Ensure the address of the partner causes issues with Pingen
4. Ensure the cover page option is disabled:
   Settings -> Accounting -> section "Customer Invoices"
5. Send a follow-up report:
   - On 17.0: Accounting -> menu: "Customers" /  "Follow-up Reports"
     -> click on a line / partner -> button "Follow up"
   - On 18.0+: partner form view -> tab "Accounting"
     -> section "invoice follow-ups" -> button "Send"
6. Make some modifications like editing the follow-up message or a custom attachment
7. Download the snailmail letter PDF (see previous commit for details)
8. In the chatter go to the message saying "Letter sent by post with Snailmai"
9. Click on the red symbol (paper plane) next to the name
10. A "Format Error" wizard should show up
11. Select "Add a Cover Page"
12. Click the button "Update Config and Re-Send"
13. Download the snailmail letter PDF (see previous commit for details)
14. Compare PDFs from 7 and 13; they are different (not just the cover page)

#### references

opw-5160121
opw-5209504
opw-5226366

Forward-Port-Of: odoo/enterprise#101498
Forward-Port-Of: odoo/enterprise#99491

### Steps to reproduce:

- In the settings enable By-Products an Multi-step routes
- Put your warehouse in manufacturing in 3 steps
- Create two storable products:
    - Final Product (FP) with an empty bom
    - By Product (BP)
- Go to the barcode app > Operations > Manufacturing > New
- Scan FP > Register By-Products
- Scan BP
#### > The line is created with pre-prod as location and prod as destination

### Cause of the issue:

Since no existing line refers to the by product, a new line is created and its `location_id` and `location_dest_id` are provided by the `_getNewLineDefaultValues`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode/static/src/models/barcode_model.js#L562-L566 However, at this point nothing had set the `params.newByProduct` in the `processBarcode`:
https://github.com/odoo/enterprise/blob/17fd46b04d87585b7ed46c00d9559414daa17384/stock_barcode_mrp/static/src/models/barcode_mrp_model.js#L375-L383 In fact, the only thing indicating that we are creating a by prodcut line at this point is the `displayByProduct`.

### Note:

The issue is no longer reproducible in 18.0+ as this change has already been applied in 2d5dbb93e6b33c2be786f9b2361c993f715d1a7f

opw-5350222

Forward-Port-Of: odoo/enterprise#101135
Forward-Port-Of: odoo/enterprise#101087

Steps to reproduce:
- Enable Rental pickings
- Create a rental for a product, for 4 quantity
- Process the delivery
- Open the barcode app and open the reception
- Scan the product once and validate

Issue:
The receipt is validated without issues nor warning, despite being incomplete.

This is due to a bad mix of two changes:
- #60801, which always sets the rental receipt as return of the delivery
- #48788, which removes the backorder check for returns in barcode

For regular returns made in barcode, it makes sense to avoid the backorder check, as from here we're processing a full picking return and we'd have the confirmation pop every time.

However, things are different for rental receipts, as despite them being set as returns of the delivery, they're proper receipts that need to handle the partial receipt.

To avoid the issue, rather than removing the backorder check whenever there's a return linked to the picking, now also checks that there isn't a rental order linked to the picking.

opw-5265874

Forward-Port-Of: odoo/enterprise#101387

BEFORE THIS CHANGE
==================

When website_appointment was installed, and when the appointment
type was configured with date_first=False, is_auto_assign=False,
then the appointment main route rendered a different page content
in order for the booker to select first the user / resource, each
having a large card with picture (or placeholder) and name (as well
as function and website_description for users).

It had a dedicated chevron in the progressbar and was referred
to as the operator selection step. There was an option to 'skip
user / resource selection' and see the full availability.

AFTER THIS CHANGE
=================

In order to ease the user experience, we now inline the user and
resource selection on the date & time selection step. It takes the
form of a grid of smaller cards, that can be selected when the same
conditions are met. They are rendered above the calendar. Their
content is the same. The user can click on the card and the calendar
will update accordingly. They can change and see updated availability
directly, which was not possible before, as the page was different.

In order to reproduce the 'skip user/resource selection' feature, a
dedicated card 'No preference' is used and put at the end of the grid of
cards. This will in turn compute full availability using all available
resources / users.

As before, when coming back from an error or using the chevrons
hyperlinks, the selection is remembered and the default selection
(user / resource / no preference) is kept and the availability computed
accordingly when landing on the page (unless having skipped selection).

The whole behavior is now available directly in appointment (no need
for website) and replaces the dropdown used previously. Corner cases
(no availabilty screens, manage capacity or not) are handled as well.

A test is modified to reflect these changes.

USER DEFAULT / SELECTED SIMPLIFICATION
======================================

A simplification of a rather hard-to-maintained flow ramification
was done as well, as the meaning of 'selected' has evolved.

Before, for manual selection starting with user / resource, having
staff_user_id or resource_selected_id set meant selection was done and
only that user / resource was to be considered. Now, this is not the
case anymore, as one can change the user / resource on the date and
time selection page.

This means we only use that 'selected' value for an initial selection:
if the user / resource has availability, then we use it. Otherwise, we
use the first available one (see `_get_slots_values`). Therefore we move
mostly the logic on x_default and `get_slots_values`.

The resource_selected_id and staff_user_id are now used when coming back
from an error or using the chevrons to navigate between steps.

AUTO ASSIGN SIMPLIFICATION
==========================

While simplifying, the x_default and x_selected were simply removed
from the controller logic when is_auto_assign is True. There was a
case of having a single staff user that lead to seeing its information
on the side bar. This has been removed as this was not consistent, nor
with resource behavior, nor with the 'auto assign' philosophy.

We now never show the user / resource in date and time, details
steps. We also do not propagate resource_selected_id to the
registration page.

TO SUMMARIZE
============

There are three flows depending on the appointment configuration:
(e.g. here for resources)

1. auto assign: no use of resource_selected_id. no display of the
selected resource / user even if there is only one, in the right
column.

2. time then resource: no use of resource_selected_id since we
need to compute for each slot all available resources.

3. resource then time: resource_selected_id, set for instance using
a chevron, is used to initialize the selection. If not available,
we still initialize to the first available resource. The value is
propagated in the url.

LINKS
=====

UPG PR: https://github.com/odoo/upgrade/pull/8724

Task-5187767

On odoo.com, we noticed that Knowledge can be slow when there are a lot of articles: For 4365 articles, it takes between 1.5 and 2.3 seconds to load the list view listing all the articles the user has access to. This PR will try to optimize the performance and the scalability of the Knowledge module by reworking the methods used to compute the permissions of a user on an article and the methods used to search the articles the user has access to or the articles the user can edit.

Those methods are computationally expensive and are used extensively in Knowledge. They are the main hot spots of the module: The search method is for instance used in the `domain_force` of the ACL rules for some group of users (see: `user_has_access` and `user_has_write_access`). They are hence used each time the user opens an article. It is therefore important to optimize those functions to make Knowledge blazing fast and responsive.

# Benchmark

To assess the performance of the new query and indexes, we wrote custom scripts that will perform a server call with the same configuration as the main list view and form view of Knowledge. This should ensure that we optimize the response time of the views we frequently use.

For 10k articles, we got the following results:

## List view

Before:

|  User |       Avg |    Std |
|-------|-----------|--------|
| Admin |   58.21ms |   8.53 |
|  Demo | 1139.65ms | 179.37 |

After:

|  User |       Avg |    Std |
|-------|-----------|--------|
| Admin |   85.95ms |   7.48 |
|  Demo |  174.17ms |   4.98 |


## Form view

Before:

|  User |       Avg |    Std |
|-------|-----------|--------|
| Admin |   56.66ms |   8.03 |
|  Demo |  469.51ms |  15.48 |

After:

|  User |       Avg |    Std |
|-------|-----------|--------|
| Admin |   35.81ms |   4.74 |
|  Demo |   64.45ms |  17.41 |


task-3771333

**Steps to reproduce:**
- Install `Accounting` module without demo data.
- Go to Accounting > Configuration > Settings > Set fiscal localization as `United States`.
- Go to `Apps > Accounting > uninstall`.
- Now try to uninstall `Invoicing` module.

[`l10n_us_account`](https://github.com/odoo/odoo/blob/e1dd3852b118eacc8d77e9e3d8c7769195c6edb1/addons/l10n_us_account/data/template/account.asset-us.csv#L2-L8) defines data for the  `account.asset` model.
When removing `account_accountant`,`account_asset` module and model are removed, but their data is still in `ir.model.data`.
As a result, when trying to uninstall the `Account` module, it attempts to delete records of a model that no longer exists, leading to a traceback.

`KeyError: 'account.asset'`

Since this issue occurs in multiple modules, we need to ensure that all related `account.asset` records are unlinked from `ir.model.data`. We added an `uninstall_hook` in the `account_asset` module to remove these records during uninstallation.

Other modules are: `l10n_be,l10n_eg,l10n_pk,l10n_uk,...`

**sentry-6938852090**

Use case:
- prerequisite: enable "vies" validation on the company

- a customer create from an account from the website
- from /my/account he edit his information, filling in:
  * the company name
  * the vat number

The VIES validation succeed and for future orders/invoices the B2B fiscal position will be correctly applied.

- then later, a backend user go the user's contact form and click on the `create company` button.

Here when creating the new "company" partner and then linking the contact to it, we will trigger the recomputation of the `vies_valid` field on the new "company" partner.

At that time, if the new VIES validation performed fail because of an network error or because the service is overloaded (`MS_MAX_CONCURRENT_REQ`) the `vies_valid` will be reset to `False`; and on future orders/invoices a wrong fiscal position (B2C) will be applied.

This commit ensure we keep the previously performed VIES validation when creating the company of a contact.

opw-5365258

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

pos_online_payment* = pos_online_payment_self_order_preparation_display
Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268)

---

Previously, when an online payment was made, the user was supposed to be redirected to a payment confirmation page which, once the transaction succeeded, sent the related order to the kitchen (PDIS).
However, in some cases, the user never reaches this page.
For example, the user may see the payment succeed in their banking app and close the tab before the redirection happens.

For POS self-orders, we must send the order to the kitchen as soon as the payment is confirmed to avoid confusion between the customer, the cashier, and the kitchen staff.
Relying solely on the confirmation page was therefore unreliable.

---

To fix this, we now leverage the cron that post-processes payment transactions:
we gather all transactions made in self-order or kiosk mode that are not yet post-processed, and send their corresponding orders to the kitchen.
This ensures that orders reach the PDIS even when the user never lands on the confirmation page.

Forward-Port-Of: odoo/enterprise#99249

..., pos_online_payment_self_order
Task: [#5217268](https://www.odoo.com/odoo/project/1737/tasks/5217268)

---

Previously, when an online payment was made, the user was supposed to be redirected to a payment confirmation page, which triggered the payment transaction post-processing.
However, in some cases, the user never reaches this page.
For example: the user sees that the payment succeeded in their banking app and closes the tab before being redirected to the confirmation page.

To still process the orders, a cron runs every 10 minutes to post-process transactions that were not processed yet.
However, for POS self-orders this is not ideal: we need the order to be processed as soon as possible since we are in direct contact with the user.
A situation where the customer insists their payment went through but the cashier sees no updated order creates unnecessary confusion.

---

To fix this, we now trigger the cron directly after receiving the callback from the payment provider.
This ensures that the transaction (and therefore the order) is always post-processed immediately and kept up-to-date, even if the user never reaches the confirmation page.

Forward-Port-Of: odoo/odoo#238407
Forward-Port-Of: odoo/odoo#235254

Problem:
When the user selects a link to color and the selection falls on a `feff` character, a traceback occurs.

Cause:
After commit 927f4b973932d14961c148e13473017651a60dc0, we preserve the selection at:
https://github.com/odoo/odoo/blob/bee7fc1f955c52a88b527ad9a2ddf0021529bbc7/addons/html_editor/static/src/main/font/color_plugin.js#L247-L247
and then call `getFonts()`, which internally uses
`this.dependencies.split.splitAroundUntil()`.

If the selection is on a `feff` node, `splitAroundUntil()` can clear those nodes because `splitElement()` inside it dispatches to `clean_handlers` with the selected element containing the `feff`. Since the preserved cursor offset refers to the node before the `feff` was removed, restoring it throws:
`The offset x is larger than the node's length (y).`

Solution:
After `splitAroundUntil()`, adjust the preserved cursor offsets if the nodes were mutated to ensure they remain valid.

Steps to reproduce:
It is difficult to reproduce manually, but the issue occurs when coloring a link with the selection on a `feff`.
A test case replicating the situation can be based on the original failing template in the customer’s database.

opw-4953943

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

Forward-Port-Of: odoo/odoo#238922
Forward-Port-Of: odoo/odoo#234328

Steps to reproduce:
- Enable Rental pickings
- Create a rental for a product, for 4 quantity
- Process the delivery
- Open the barcode app and open the reception
- Scan the product once and validate

Issue:
The receipt is validated without issues nor warning, despite being incomplete.

This is due to a bad mix of two changes:
- #60801, which always sets the rental receipt as return of the delivery
- #48788, which removes the backorder check for returns in barcode

For regular returns made in barcode, it makes sense to avoid the backorder check, as from here we're processing a full picking return and we'd have the confirmation pop every time.

However, things are different for rental receipts, as despite them being set as returns of the delivery, they're proper receipts that need to handle the partial receipt.

To avoid the issue, rather than removing the backorder check whenever there's a return linked to the picking, now also checks that there isn't a rental order linked to the picking.

opw-5265874

Forward-Port-Of: odoo/enterprise#101387

### Issue:
When changing the "Customer Reference" on an invoice, the name of the payment term line is not updated.

### Steps to reproduce:
- Create an invoice with payment terms, confirm it
- Modify its "Customer Reference" to 'test' for example
- In the page "Journal Items" the name of the terms line has been recomputed to "test - INV/2025/XXXXX"
- Modify again its "Customer Reference" to 'abcdef' for example
- In the page "Journal Items" the name of the terms line was not recomputed

### Cause:
In `_compute_name()` we only write the name if this condition is `True`:
```py
if n_terms > 1 or not line.name or line._origin.name == line._origin.move_id.payment_reference or (
        line._origin.move_id.payment_reference and line._origin.move_id.ref
        and line._origin.name == f'{line._origin.move_id.ref} - {line._origin.move_id.payment_reference}'
    ):
    line.name = name
```
The purpose of this line is to keep the name of the line if it was manually inputted. So the logic is: we only write the computed name if the previous name was computed. To check this, we check if `line._origin.name == f'{line._origin.move_id.ref} - {line._origin.move_id.payment_reference}'`.

The issue comes from the use of `_origin` in a compute. `_origin` refers to the record before we make any change. But it is meant to be used for `onchange` methods, in these the values are not yet written so `_origin` refers to the record before saving.
Here, when saving, `line._origin` is the same as `line`, so 
- `line._origin.move_id.ref` is the new ref.
- `line._origin.name` uses the old ref (it's currently being recomputed).

### Solution:
Unfortunately, in the compute, there are no trace left of what were the previous values as the write already occurred.

The initial complaint justifying to keep custom line names was that on bills, the line name is empty. So when inputting a custom line name, it was removed by the compute method. The previous fix wanted to be more general by always keeping custom line names.

Considering this, this commit removes part of the previous fix: Now we only keep the custom line name when the compute method wants to remove it. So we keep the previous fix for bills.

### Note
There was a test verifying exactly that when manually deleting the line name, in the end
the line does not have a name. This will no longer be the case but a decision must be made between:
1. updating the line name when changing the ref
2. not recomputing line name when it has been changed manually
3. removing the line name when it's manually deleted

We can have 2 and 3 but not with 1 afaik.

opw-5246917

Forward-Port-Of: odoo/odoo#237710

### Issue:
In this issue, when specification is set to accordion style, single value attributes is still displayed, making single value attributes duplicated.

#### To reproduce:
1- Create a product with a multi-value and a single-value attribute.
2- Using editor on product website page, from style tab, change style of specification to `in accordion`.
3- As you see, single value-attribute is displayed twice. Once in accordion, and one in single-value attributes section.

### Cause:
When `specification` is set to other than `None`, IMHO we need to not display `product_accordion` as single values are already displayed:
https://github.com/odoo/odoo/blob/ea01165d9486572269c44597a1db49b31bf8aba3/addons/website_sale_comparison/views/website_sale_comparison_template.xml#L196-L209

When `specification` is set to `Bottom of Page`, this is already the case using xpath replace:
https://github.com/odoo/odoo/blob/ea01165d9486572269c44597a1db49b31bf8aba3/addons/website_sale_comparison/views/website_sale_comparison_template.xml#L91-L94

However, we cannot do the same in `accordion_specs_item` as it is not inheriting `website_sale.product`.

We can instead fix this using scss style, which also won't require updating views.

opw-5365375

Due to the dependencies between mo state, components_availability_state, reservation state and wo state, we had to make sure that the state is always computed before the reservation_state.
This is the purpose of (1) merged in 17.0

A non-related mrp_account fix (2) has been merged in 18.0 with the side-effect of firing a reservation_state compute with no state, invalidating the previous fix.

As _post_inventory occurs under button_mark_done which changes at least the mo's state and may fire the computes on another mos, we have to make sure reservation_state and state are computed in one go, the correct order being handled by (1).

Please note that of workorder revamp (3) has been merged in 18.3, solving the dependencies.

(1) https://github.com/odoo/odoo/pull/185092
(2) https://github.com/odoo/odoo/pull/201764
(3) https://github.com/odoo/odoo/pull/194841

task: 5247116

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

### Issue

Large financial reports are slow to compute due to repeated re-aggregation of account_move_line balances for each formula, even when most formulas share the same base domain (usually filtered by account_id fields).

### Analysis

Each report line formula independently aggregates balances from account_move_line, even when their domains only differ on account_id-related fields such as account_id.account_type or account_id.non_trade.
This leads to redundant scanning and aggregation of the same dataset multiple times within a single report execution.

### Solution

Introduce a lightweight in-memory caching layer for aggregated balances by account_id, stored in self.env.cr.cache.

For each (options, date_scope) pair:
The report engine now computes once the mapping
{account_id: {'amt': total_balance, 'count_aml_lines': count}}.
This mapping is stored in the cursor cache and reused across all formulas whose domains filter exclusively on account_id fields.
A small domain transformation step allows AML domains based on account_id.* fields to be evaluated directly against the cached account aggregates.
This approach avoids redundant SQL aggregation, remains fully read-only (no database writes), and is safe for execution on read replicas.

### Benchmarks

Profiling get_report_information_readonly on different reports. Database has ~11.6 million account_move_lines, 305 account_accounts, and 16 account_types

| Report Name | Before | After | % Speed Up |
| --- |---|---|---|
| Balance Sheet | 35s | 6.2s | ~550% |
| Profit and Loss | 7.2 | 2.1 | ~300% |
| Executive Summary | 24s | 6.3 | ~400% |

### References

opw-5130725

Versions
--------
- 18.0+

Steps
-----
1. Create a loyalty program;
2. Create a reward;
3. Add a Product domain to the reward containing the `not ilike` operator;
4. Load the POS;
5. Try to trigger the Loyalty program;
6. The Reward is not applied when the domain is satisfied

Issue
-----
Loyalty Program rewards containing `not ilike`-based product domains are not applied when they should.

Cause
-----
The `_replace_ilike_with_in` function in loyalty_reward.py converts the `ilike` and `not ilike` operators by first fetching the records that very the domain with the operator used, and then by replacing the domain by `in` or `not in` with the returned records ids. This is problematic as in the case of `not ilike`, it leads to a double negation.

Example
-----
For `ilike`: `['categ_id', 'ilike', 'service']`
-> Search for all categories that contain "service": `_search([('display_name', 'ilike', 'service')])` 
-> Return new domain `['categ_id', 'in', matching_ids]`
Which is correct.

For `not ilike`: `['categ_id', 'not ilike', 'service']`
-> Search for all categories that **do not contain** "service": `_search([('display_name', 'not ilike', 'service')])`
-> Return new domain `['categ_id', 'not in', matching_ids]`
Which is incorrect, as the matching_ids are already the ids that are not like "service". (i.e., *categ_id not in the categories that do not contain "service"* <=> *categ_id in the categories that contain "service"*, opposite of what is expected.)

Solution
--------
1. Perform the initial search with `ilike` for both operators

opw-5182818

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

Description of the issue/feature this PR addresses:
- The POS receipt shows CGST, SGST, and IGST together, even when IGST is applicable.
- This is incorrect because only CGST+SGST or IGST should be displayed, not all three.

Current behavior before PR:
- The receipt always displays CGST, SGST, and IGST columns at the same time.
<img width="250" height="400" alt="image" src="https://github.com/user-attachments/assets/5c8487c7-c497-4c82-ad80-8cf0e98fbf38" />

Desired behavior after PR is merged:
- The receipt shows only the correct tax columns based on the transaction:
  - Shows CGST and SGST when GST applies.
  - Shows IGST when IGST applies.
<img width="250" height="400" alt="image" src="https://github.com/user-attachments/assets/68d2fb58-9e15-4861-a71f-ccb2d978e544" />

Changes implemented in this commit:
- Added `t-if="l10n_in_hsn_summary.has_gst"` to CGST and SGST headers.
- Added the same condition to CGST and SGST values in the item rows.


task-5268935

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

**Steps to reproduce:**
- Install Accounting

- Create an invoice with an invoice line
- Save the invoice

- Change the unit price => The totals should change
- Change the product => The unit price and the totals should change
- Change the unit price again

**Issue:**
After this point, the totals don't change anymore, even if the unit price is changed several times.
Only saving the form will adapt the totals correctly.

**Cause:**
When changing the unit price the first time, a "price_unit "key is added in the onchange values.
When changing the product, a "product_id" key is added after the price key.
Changing the product triggers an onchange of the price with the price of the new product.
However, when the price is changed again, as the "price_unit" key already exists, it's reused and its position is still before "product_id" key even if it should be computed after.
This order results in the use of the price of the second product instead of the one entered manually when computing the "tax_totals".

**Solution:**
If "product_id" and "price_unit" are the values of the onchange method, the list of values is reordered to make sure that "product_id" is computed first.

opw-5012125




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

Forward-Port-Of: odoo/odoo#232684

Currently, an error is raised when trying to fetch the shipping rate if the partner does not have the required geolocation fields (country, state, and city).

**Steps to Reproduce:**
1. Install and configure the **Envia Shipping** module.
2. Create a partner without an address (only name + phone).
3. Create quotation for that partner with a deliverable product (e.g; Conference Chair).
4. Click "**Add Shipping**", choose _Envia Shipping_ Method, and then click "**Get Rate**".

**Error:**
`TypeError - quote_from_bytes() expected bytes`

**Cause:**
At [1], the system tries to compute Envia shipping rates based on the partner’s country, state, and city. If any of these fields are not set, an error is raised.

**Fix:**
This commit adds a check for the required fields (country, state, and city). If any are missing, `_geolocate_zip` returns False, leading to a proper validation error instead of a traceback. - [2]

[1] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L591-L593
[2] - https://github.com/odoo/enterprise/blob/f1a02626a1fbe76add104832e151c647307f3ae7/delivery_envia/models/envia_request.py#L617-L624

sentry-7063870478

Bug
===
Facebook deprecated some of the endpoints related to statistics
https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics

We fixed all metric except the audience trend, because we needed a
fix rapidly, and we wasn't sure about unfollow.

And indeed, `page_daily_follows` only count for positive value, unlike
the old `page_fan_adds` / `page_fan_removes`, and there's no equivalent
of `page_fan_removes`...

Example of data for a month:
```
page_follows       4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0

page_follows       1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
```

So we now use `page_follows`, so the total value at a given time, and
we look for the newest and oldest value (note that if we could do the
same for `page_post_engagements`, then we could just make 2 APIs calls
for the year stat).

Task-5353390

Forward-Port-Of: odoo/enterprise#100275

Bug
===
Facebook deprecated some of the endpoints related to statistics
https://developers.facebook.com/docs/platforminsights/page/deprecated-metrics

We fixed all metric except the audience trend, because we needed a
fix rapidly, and we wasn't sure about unfollow.

And indeed, `page_daily_follows` only count for positive value, unlike
the old `page_fan_adds` / `page_fan_removes`, and there's no equivalent
of `page_fan_removes`...

Example of data for a month:
```
page_follows       4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 4 5 5 5
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 0 0

page_follows       1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 0 0 0
page_daily_follows 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
```

So we now use `page_follows`, so the total value at a given time, and
we look for the newest and oldest value (note that if we could do the
same for `page_post_engagements`, then we could just make 2 APIs calls
for the year stat).

Task-5353390

Forward-Port-Of: odoo/enterprise#100275