Currently an error occurs when auto-vacuum tries to clean up Withhold wizard which is a transient model but fails because it is still linked with Withhold lines wizard.

**Steps to replicate:**
* Install `l10n_ec_edi` and change company to `EC company`
* Create invoice with customer `EC Company` > Set Payment Method (SRI) > Confirm
* Add Withhold > Document number: `001-001-123456789` > Add lines > Create & Post
* Set system time to future date > Run `Base: Auto-vacuum internal data`.

Refer video [1] for replication steps.

**Error:**
`psycopg2.errors.ForeignKeyViolation:update or delete on table 'l10n_ec_wizard_account_withhold' violates foreign key constraint 'l10n_ec_wizard_account_withhold_line_wizard_id_fkey' on table 'l10n_ec_wizard_account_withhold_line'
`
**Root cause:**
* The error happens because Withhold Wizard [2] is a transient model that gets cleaned up by function [3] after reaching its max hours.
* However, since [2] is linked to Withhold Wizard Lines [4], the cleanup fails, causing the error.

**Solution:**
* Unlink the lines first and then unlink the wizard.

[1]:
https://drive.google.com/file/d/1HethT8tpa3Ez0uwueUuKzW4F7KxEKOv_/view?usp=sharing 
[2]:
https://github.com/odoo/enterprise/blob/2275fe560d5db0b5a21ffbc4d4c66264e4e12601/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L20 
[3]:
https://github.com/odoo/odoo/blob/e062c9b5773ed0710503c13627e60f8233fcd0a5/odoo/models.py#L7465-L7497 
[4]:
https://github.com/odoo/enterprise/blob/7ca0635d4c479a956bfae8fb60da8b50362fd99b/l10n_ec_edi/wizard/l10n_ec_wizard_account_withhold.py#L423-L427

sentry-6253783256

Forward-Port-Of: odoo/enterprise#99653

Currently, an error occurs when a portal user opens a shared project and clicks 
the `Unfollow` button in the chatter of a `new(unsaved)` task.

**Steps to produce:**

- Install the `project` module.
- Open the project app and create a new project with at least one task.
- From the project’s `dropdown menu(⋮)`, select `Share Project`.
- Add a `collaborator: Joel Willis`, with `Edit access mode`, copy the `public link`, and click `Share Project`.
- Open the shared link in an incognito window and sign in as a `portal user`.
- Open the project folder > open any task > click `New` > click `Unfollow` button.

**Error**:
`ValueError: Expected singleton: project.task()`

**Root cause:**
The Unfollow button at [1], is displayed even when the task record is 
not yet saved (`props.threadId` is `undefined`). At [2], the method is 
called on an empty recordset, causing an `error`.

**Fix:**
This commit prevents the error by ensuring the `Unfollow` button is hidden 
when the record is `unsaved`.

[1]: https://github.com/odoo/odoo/blob/be138ef2ff1b3a83f77fe300f789d754ed3383fd/addons/project/static/src/project_sharing/chatter/portal_chatter_patch.xml#L7-L14

[2]: https://github.com/odoo/odoo/blob/be138ef2ff1b3a83f77fe300f789d754ed3383fd/addons/project/models/project_task.py#L2022

No task ID

Forward-Port-Of: odoo/odoo#236633

Due to more number of moves during compute it out of memory while getting the country_code per move. So, just pre fetch the country code. So, it won't go for computing that and will be available in memory

records
```
sagu_3267671=> select count(id) from account_move;
  count
---------
 1034179
(1 row)
```

```
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine
return needle(*args)
File "/home/odoo/src/odoo/17.0/addons/l10n_rs_edi/models/account_move.py", line 85, in _compute_l10n_rs_edi_is_eligible
move.l10n_rs_edi_is_eligible = move.country_code == 'RS' and move.is_sale_document() and move.l10n_rs_edi_state in (False, 'sending_failed')
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1219, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine
return needle(records, *args)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6695, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2933, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3984, in _fetch_query
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1135, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
```

upg-3267671
opw-5246681


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

Forward-Port-Of: odoo/odoo#235919

Steps to reproduce
------------------
1. Create a product with a UoM that is non groupable in PoS
2. Make a sale order with that product having a UoM that is based on the
   UoM of the first steps. If the UoM in the first step was Kg for
   intsance, use Gram (g) here.
3. Confirm the order, and settle it in PoS.

Notice that the price of that order in PoS is not correct.

Why it's happening
------------------
When settling the PoS order, we first convert the sale_order's line UoM
(g) to the original product UoM (kg), and we update the quantity
accordingly (in this example by dividing by 1000).
https://github.com/odoo/odoo/blob/fcc5a90d2d5754923676b11031e37f52729402fd/addons/pos_sale/static/src/overrides/models/pos_store.js#L94-L96
So this step updates both the qty and the unit_price.
https://github.com/odoo/odoo/blob/fcc5a90d2d5754923676b11031e37f52729402fd/addons/pos_sale/static/src/overrides/models/pos_store.js#L160-L161

However, when the UoM is not groupable, we split the lines by taking
into consideration the updated qty, but we still use the old price_unit,
which creates an inconsitency and wrong calculations.

The fix
-------
When splitting the lines, we're just supposed to change the qty per line
to max 1, but we're not supposed to change the price per unit for this
qty. We now use the updated `price_unit` to have a correct math.

opw-5232571

Forward-Port-Of: odoo/odoo#237172
Forward-Port-Of: odoo/odoo#236008

## Issue 1:
In this issue, active/inactive filter is not working correctly.

#### To reproduce:
1- Install `Sale`
2- Active `Promotions, Loyalty & Gift Card`
3- In `Discount & Loyalty` create a loyalty program
4- Create a `Loyalty Card` for the program
5- Archive the card
6- In search, click on `inactive` filter

As you see, you can't find the archived card.

### Cause:
This is caused due to setting the filter on `program_id.active` rather than `loyalty_card.active`.

## Issue 2:
In this bug, earned points on archived loyalty can be used to claim rewards.

#### To reproduce:
1- Install `Sale` and `Ecommerce`
2- Active `Promotions, Loyalty & Gift Card`
3- In `Discount & Loyalty` create a loyalty program
4- Add a rule to grant 10 points per order
5- Apply a reward in exchange of 10 points
6- Create a `Loyalty Card` for the admin with 0 points.
7- In Ecommerce, add a product to your cart
8- Remove the product from the cart
9- Archive the loyalty card created for the admin
10- In Ecommerce, add another product to cart
11- As you see, you still can use the loyalty card

### Cause:
When a product is first added to the cart, a `sale.order.coupon.points` record is created to grant points. Even if the cart is later emptied, the created `coupon_point_id` still exists. After the loyalty card is archived, points are still granted to this existing `coupon_point_id`, allowing it to be used to claim rewards.
To prevent this, we can unlink points from draft sale order when the card is archived.

opw-5166696

Forward-Port-Of: odoo/odoo#233645

### Issue:
When sending an invoice and creating CFE, we fail to retrieve the PDFs generated by Uruway.

### Steps to reproduce:
- Install 'l10n_uy_edi' and switch to an Uruguayan company
- In the Settings change 'UCFE Web Services' to 'Testing' and input credentials
- Create a new invoice, confirm and send, click 'Generate CFE'
- The CFE status is accepted but the PDF from Uruware is not on the record

### Cause:
This [commit](https://github.com/odoo/enterprise/commit/726ebfe7c6266b7e54d8b2716983e62eb3142a81) changed how `l10n_latam_document_number` is computed: it's no longer related to `move_id.l10n_latam_document_number` but computed when `move_id` is set.

In our case `move_id.l10n_latam_document_number` is [set in `_l10n_uy_edi_send()`](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/account_move.py#L837-L839) but as `move_id` is not changed, the compute is not triggered and the field of the document is not the same.

Later in `_get_pdf()` we use `self.l10n_latam_document_number` to retrieve the PDF from Uruware ([see](https://github.com/odoo/enterprise/blob/f8ac53cb6e6578a43780e07b6133fa09bdee8dbb/l10n_uy_edi/models/l10n_uy_edi_document.py#L240)).

### Solution:
We need to keep the fields coherent with either `move_id` or `picking_id`. To do this we add the fields of the linked redord in `depends`.

opw-5272776

Forward-Port-Of: odoo/enterprise#100128

**Problem:**
when selling a product valued by lot
and chosing a lot with a value of 0
the average value of the product
is used instead of 0.

**Steps to reproduce:**
- make sure your warehouse is in single step receipt and delivery
- create a product tracked by lot and valued by lot
- set the category as avco
- create a PO for a quantity of 10 and a unit price of 10
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot A" in the lot column and save
- validate
- create a PO for a quantity of 10 and a unit price of 0
- confirm and open the receipt
- open the stock move widget on the stock move
- write "lot B" in the lot column and save
- validate
- create a quotation for 1 quantity of your product
- confirm
- open the delivery
- open the stock move widget on the stock move
- in the 'pick from' column enter lot B and save
- validate
- open the valuation smart button

**Current behavior:**
the value of the stock valuation layer is -5

**Expected behavior:**
it should be 0

**Cause of the issue:**
Inside _prepare_out_svl_vals
lot.standard_price is 0 so the if condition
is false and we don't use the price of the lot
https://github.com/odoo/odoo/blob/cd2a241182cf56fc36d03df9f0afdcea30f682d2/addons/stock_account/models/product.py#L277

**fix:**
    deleting the lot.standard_price condition
    is not possible because when the lot is created
    at delivery it has no standard_price and in this
    case we want to use the standard_price of the
    product.
    (see test https://github.com/odoo/odoo/blob/d3835668349d466ed4ba27c9eacdbd3339f2ac37/addons/stock_account/tests/test_lot_valuation.py#L58)

opw-5077671

Forward-Port-Of: odoo/odoo#234764

Before this commit:
-------------------------
- On the Purchase Dashboard, the 'Not Acknowledged' and 'Late Receipt' counters
  also included purchase orders whose receipts had already been done.
- For Not Acknowledged:
  - Such POs should be implicitly considered acknowledged once their receipts
    are done, but they were still shown at the counter.
  - Additionally, unacknowledged POs that were locked were incorrectly excluded
    from the counter.
- For Late Receipt:
  - POs with received products were incorrectly counted as late, even
    though their receipts were already done.
  - Locked POs with late receipts were also excluded from the counter, which was
    an incorrect behavior.

Steps to reproduce:
-------------------------
1. Install the 'purchase_stock' module.
2. Open Purchase module.
3. On the Purchase Dashboard, click on the 'Not Acknowledged' or 'Late
   Receipt' card.
4. Notice that POs whose receipts are already completed still appear in the
   counters and some locked POs that are unacknowledged or have late receipts
   are missing from the counters

Cause of the issue
-------------------------
- The domains for both Not Acknowledged and Late Receipt counters only relied on
  the purchase order state without checking whether the receipts were done.
- As a result, POs with done receipts were still included in the counters, while
  some locked POs were incorrectly excluded.

After this commit:
-----------------------
- Updated the search domains for both counters to properly exclude POs whose
  receipts are done.
- The action_done method now triggers action_acknowledged, ensuring that any
  unacknowledged POs with completed receipts are automatically marked as
  acknowledged and excluded from the Not Acknowledged counter. Locked POs that
  remain unacknowledged will still correctly appear in the counter.
- Now the POs with received products are no longer shown as late once their
  receipts are completed and Locked POs with late receipts will now correctly
  continue to appear in the counter.
- This ensures that the dashboard accurately reflects only pending
  acknowledgments and genuinely late receipts, helping users track POs in
  the correct state.

Task ID: 4874116

Forward-Port-Of: odoo/odoo#224180

It may occur that when using 'Set Account' to reconcile a bank statement the reconciliation fail due to error "The operation cannot be completed: A reconciliation model already bears this name"

Steps to reproduce:

1. Create a current liability, reconciliable account "455010 My Account"
2. Create 2+ with a common labels (TEST RECONCILIATION)
3. Use "Set Account" button to reconcile the first transaction with account 455010.
4. Repeat 2-3 with a shorter label
5. Open Reconciliation models for the Journal and delete the one named "455010 My Account"
6. Repeat 2-3 with an even shorted label

Issue:

Reconciliation will be blocked by error during automatic creation of reconciliation model

Analysis:

It occurs because we don't take into account that old reconciliation models may have been deleted, so even if we count a singe record it may have already been labeled "<account_name> (1)"
Improved the naming by looking at the existing models and increasing the counter if necessary

opw-5184696

## Issue:
When multiple languages are enabled on the website (English + another),
sharing a public Knowledge article may block portal users from accessing it
For example, if the website’s default language is Spanish and the user opens the link,
they are redirected to the home page and the article does not appear in the sidebar

## Cause:
When accessing `/knowledge/article/...`, the `_match` route handler automatically
rewrites the URL to `/en/knowledge/article/...`
However, the website only recognizes `/es/knowledge/article/...`, so the rewritten URL is not valid
As a result, the user falls back to `/knowledge/article/new`, which triggers a redirection to the home page

## Steps to reproduce:
- Install Knowledge and Knowledge Website
- Set Spanish and English (US) as available website languages
- Set Spanish as default website language
- Create an article in knowledge
- Click Share and activate "Share to web"
- Copy the link and open it in a private window (The article should be visible)
- Log in as a Portal user
- Open the link
- The user is redirected to the home page and the article is missing from the sidebar

opw-4916118

Forward-Port-Of: odoo/enterprise#96505

Issue
-----
In 3step manufacturing, changing the pre-prod -> prod rule to MTSO doesn't have the expected behaviour. That is, if there is an insufficient quantity of component present in pre-prod, updating the producing qty doesn't update the replenishment quantity.

Steps to reproduce
-----
- Enable warehouses and multi-step routes
- Set warehouse manufacturing to 3 step
- Edit the 3 step production route
	- Change the pre-prod -> prod rule to mts else mto
- Create a product "Comp"
	- Set a quantity of 5 in location pre-prod
- Create a product "Prod"
	- Add a BoM with "Comp" as component
- Create a MO for 10 of Prod
- Confirm MO
> There is a transfer stock -> pre-prod for 5 of Comp
- Open the production quantity wizard, update value to 12 and confirm
> The transfer still shows 5 of Comp instead of the needed 7

Cause
-----
Changing the production quantity updates the raw moves of the MO. This triggers a write on the move with the new `product_uom_qty` so we do a `run_procurement`

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L481-L485

Before actually running any procurement we do

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L492

Since the procurement group's method is `mts_else_mto`, when we go through

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2329-L2332

we go into the `else` part and set the move's `procure_method` to mts.

This means that, in the `run_procurement` method

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/mrp/models/stock_move.py#L504

is not true, so we don't add any procurement to run.

Solution
-----
In `_adjust_procure_method` we update the move's rule to the MTSO one we found

https://github.com/odoo/odoo/blob/322c6d0468bf79e9d29e1375c49aa13d4a7b7a67/addons/stock/models/stock_move.py#L2328

This means that we can update the check in `run_procurement` to also add a procurement to run if the move's rule is MTSO.

-----
Ticket:
opw-5008871

Forward-Port-Of: odoo/odoo#235125

**Description:**
Deprecated accounts (active=False) with historical transactions were not appearing in the General Ledger report.


**Steps to Reproduce**:
- Go to Accounting > Reporting > General Ledger
- Choose an account code from the report (e.g 121000)
- Go to Configuration > Chart of Accounts
- Click on the account code 121000 and set the active field to False
- Go back to the General Ledger report and notice the account cod no longer exist in the report 
even though it historical transactions

**Root Cause:**
In Odoo 18.3, the `deprecated` field  was replaced with the `active` field.

- `deprecated` field: Manual filtering only (where explicitly coded)
- `active` field: Automatic ORM filtering (implicit in ALL searches)

When the account search in `_query_values()` executes, Odoo's ORM automatically adds `AND active = TRUE` to filter out inactive records. This means deprecated accounts are silently excluded from reports.

**Fix:**
Added `with_context(active_test=False)` to the account search which disables automatic filtering for this specific query, restoring the original behavior where deprecated accounts appear in historical reports while remaining hidden in form dropdowns.

opw-5092275