Currently when a user with a product manager rights that is not admin tries to look up the product with barcode information is not auto filled.

## Steps to replicate:
- Install stock with demo data
- Barcode Database > Setup barcode lookup credentials
- Users > Marc Demo > Give Marc Demo > Master Data > Products > Create
- Login as `Marc Demo`
- Products > Barcode: `850049670180` > Click anywhere else

## Observed Behaviour:
Information on the product template is not autofilled, as it would be when using a System Admin user(Mitchell Admin).

## Root cause:
This issue occurs because barcode lookup is gated behind a check for System Admin rights. Although users in the Product Manager group have permission to create products, they do not satisfy this condition, so the barcode lookup never executes at [1].
[1]-
https://github.com/odoo/enterprise/blob/c66995fda83e19b28a38312af8efdc1601881cf0/product_barcodelookup/models/product_template.py#L17-L22 
## Why this is an issue:
The original restriction (task [2] and commit [3]) was intended to limit barcode lookup to users who can create products, preventing unnecessary API calls. This was a valid assumption in 17.3-18.0, where creating products in POS required System Admin rights but now after commit [4] this is no longer the case.

In v18, task [5] introduced the Product Manager group, making product creation independent of System Admin rights or module rights. Later, v18.3 exposed these Master Data access rights to non-debug users through commit [6].

As a result, there are users who are legitimately responsible for product creation and maintenance (regardless of POS usage) they can no longer use barcode lookup unless they are also granted full System Admin privileges, which provides broader access than required.

## Solution:
Remove the group-based permission check so that access is determined solely by product edit permissions. This ensures that only users with the ability to modify products can use the API call, preserving the original security intent.
As a result, users no longer need unnecessary administrative privileges toperform barcode lookups.

[2]:
https://www.odoo.com/odoo/project/49/tasks/3911024 
[3]:
https://github.com/odoo/enterprise/commit/444df3e48cb8d479d3b5d4a03a4bfefa48650910 
[4]:
https://github.com/odoo/odoo/commit/821bbc4504fd80a508e2412c7490ee60dd03f7b8 
[5]:
https://github.com/odoo/odoo/commit/d4886faf12ccaf63d5e899c20df2543d1ce046ab 
[6]:
https://github.com/odoo/odoo/commit/e74eaf628498155243db73ea229eaf5e74c24f2a

opw-6290999

Forward-Port-Of: odoo/enterprise#121915

**Steps to reproduce the issue:**

- Install the l10n_mx_edi module.
- Open the Accounting app and go to Customers → Invoices.
- From the invoice line, make the Tax Object field visible.
- Create a new invoice and add a product that has no Unit Price.
- Save the invoice.
- Edit the same invoice, set a Unit Price for the product, and save it again.
- Issue: The Tax Object field is not automatically set after the Unit Price is added.

**Description:**

- In our standard code, there is a condition that skips computing the Tax Object when the Unit Price is [0](https://github.com/odoo/enterprise/blob/615a5f756d708db95e22cdbdd6e7aca72ac769ec/l10n_mx_edi/models/account_move.py#L988). This is the expected behavior.
- However, after setting a Unit Price on the product, the Tax Object is not recomputed, so it remains unset.
- To resolve this issue, I added price_unit to the @api.depends decorator so that the Tax Object is recomputed whenever the Unit Price changes.

**Reference videos:**

Before the fix:
[screen-capture (2).webm](https://github.com/user-attachments/assets/c1162fd9-52b8-4a8c-9ac2-39cf2ca3ad69)


After the fix:
[screen-capture (1).webm](https://github.com/user-attachments/assets/1c05dc34-6778-487a-9bfc-635cf652e670)


OPW -6305080 
UPG - 4268848

Forward-Port-Of: odoo/enterprise#123009

**Step to Reproduce:**

1. Create a database in 18.0 with `l10n_mt` installed.
2. Select the Malta chart template (COA).
3. Upgrade the database to 19.0.
4. Verify the tax grids.

**Issue:**

Tax grids remain unchanged after the upgrade and do not reflect the modifications introduced in [1].

The tax definitions are loaded from CSV data and don't happen during upgrade or module update it did through try_loading". Since the account tags already exist in upgraded databases, the changes are not applied during module loading and the updated grid assignments are not assigned to taxes.

**Fix:**
Apply the grid update directly through SQL during the upgrade or module update. The change is limited to tax grid assignments and does not require a full tax reload using ``try_loading`` or ``load_data``.

**Before fix:**
<img width="1458" height="724" alt="image" src="https://github.com/user-attachments/assets/eaac5e3f-d551-4ec0-b282-bb39a50438f9" />

**After fix:**
<img width="1240" height="583" alt="image" src="https://github.com/user-attachments/assets/74409c53-dce0-45b2-a6b5-e60f5c2d826d" />



Note: why this fix is needed because existing upgrade script do update move line grid but still tax have the old grid which is weird and will cause issue when journal entry will create. 

[1]:  https://github.com/odoo/odoo/pull/254894/changes/8921186850e31c53072d49a5dc760192f3edb902

opw-6325845
upg-4391393

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

Forward-Port-Of: odoo/odoo#272038

On a Purchase Order, if you duplicate the delivery, change its Operation Type and validate it, it will still count towards the received quantity on the po.

Steps to reproduce:
-------------------
* Create a PO and confirm it
* Open the receipt, validate and duplicate it
* Go on the duplicated receipt and change its Operation Type
* Confirm the duplicated receipt. 
-> the Received Qty on the Po counted the duplicated and modified transfer.

Observation:
-------------
When we duplicate a stock.picking, we will call ```copy``` and copy all its ```move_ids``` (stock.move), and in stock.move we will copy the ```purchase_line_id``` : https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/models.py#L5868 https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/models.py#L5881-L5892
https://github.com/odoo/odoo/blob/3e6d93bef49bb2718e8aa1756f95c2a6117c8d55/addons/purchase_stock/models/stock_move.py#L13-L15
the ```purchase_line_id``` will keep the link with the pol.
The fields are copied since they have ```copy=True``` https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/addons/stock/models/stock_picking.py#L614 https://github.com/odoo/odoo/blob/754898c58fded0e3c3c30702f15258f1dadcfa6c/odoo/fields.py#L304

Because new stock moves are linked directly to the Purchase Order Line (POL), the qty_received calculation aggregates all associated move quantities.
https://github.com/odoo/odoo/blob/cfc63060926db4cec773c159b8ecf97dc0b36d1a/addons/purchase_stock/models/purchase_order_line.py#L73-L76
opw-6088239

Forward-Port-Of: odoo/odoo#276250
Forward-Port-Of: odoo/odoo#259570

## Current behavior:
Clicking on the Late activity for Lot/Serial in the notification systray doesn't apply the Late activities filter.

## Expected behavior:
Clicking on the Late activity for Lot/Serial in the notification systray should apply the Late activities filter.

## Steps to reproduce:
1. Install Inventory (stock) module, make sure to enable Lots & Serial Numbers in Inventory > Traceability
2. Create some new Lots / Serial numbers
3. Add some Activities with Due Date before today
4. Observe that the Clock icon on systray will count up, showing the number of activities that are late, for today and for future
5. Click on the Late activities (e.g. 2 Late) should only show the 2 late activities. Instead, no filter is applied, thus showing all the Lots / Serial numbers in the inventory

## Cause of the issue:
Missing filters for Late, Today and Future activities in the stock_lot_views.xml

## Fix:
Added 3 filters for Late, Today and Future activities

opw-6332560

Forward-Port-Of: odoo/odoo#272735