Currently, an error occurs when validating an online payment if the network is slow.

**Steps to Reproduce:**
1) Install POS (with demo data) and the Demo Payment module. 
2) Go to Payment Methods and create a new online payment method for any shop (e.g., a clothing shop). Set the Payment Provider to `Demo`.
3) Open a POS session for the clothing shop, select any product, and proceed to payment.
4) Open Inspect → Network tab, create a custom slow network profile(e.g., `set both download and upload speed to 1 KB/s`), and switch to that network.
5) Select the online payment method you just created and continuously click on Validate.

Error:
ValueError: Expected singleton: pos.order('p', 'o', 's', '.', 'o', 'r', 'd', 'e', 'r', '_', '4')

**Root Cause:**
When an online payment is validated, the `_isOrderValid` and `addNewPaymentLine` methods are called.
- With a slow network, the order ID is still temporary(e.g., e74a3369-7dcd-4234-b35e-04daa149ffe6) as the order is not synced completely, when the code at [1] is executed.
- Due to multiple clicks, `_isOrderValid` forces a call to `update_online_payments_data_with_server` at [2] before order is synced.
- This eventually passes the temporary ID to `get_and_set_online_payments_data` at [3], causing the issue.

**Fix:**
Prevent multiple clicks on Validate until the order is successfully synced.

[1]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L11-L17

[2]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L87

[3]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/models/pos_store.js#L18-L26

**sentry-6849786792**

Forward-Port-Of: odoo/odoo#227967
Forward-Port-Of: odoo/odoo#225371

**Issue:**

Users with "All Timesheets" rights can't see other users’ timesheets on tasks they followed within private projects, even though they had access to the task itself.

**Cause:**

The security rules for approvers (`timesheet_line_rule_approver` and `timesheet_analysis_report_approver`) only check project-level follower access and ignore task-level access.
https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L66-L76

https://github.com/odoo/odoo/blob/48cfd650053c794a838c130605c4280351b4f5d9/addons/hr_timesheet/security/hr_timesheet_security.xml#L108-L117

**Steps to reproduce:**

1. Create a private project (`privacy_visibility == 'followers'`)
2. Give another user (e.g., Marc Demo) "All Timesheets" rights and only "User" project access
3. Add Marc Demo as a follower of a task in that private project
4. Have another user log time on that task
5. Log in as Marc Demo

Marc cannot see the other user's timesheets, neither on the task form nor in reporting.

opw-5022877

Forward-Port-Of: odoo/odoo#226948
Forward-Port-Of: odoo/odoo#224025

Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.

Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
	- Sale price: 1000 INR
	- Weight: 100g
	- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
	- Payment Method: COD
	- Set some "Shiprocket Channel"
	- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
	- Name: 50% off
	- Program Type: Coupons
	- Change the existing reward to 50% discount on order
	- Generate some coupon
	- Copy the code of the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
	- Shiprocket COD
	- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log

--> total_discount is 0

Cause
-----
The problem comes from

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301

There are 2 issues here.

The first and most important one is how we find the discount lines.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320

Discounts from coupons don't use the `sale_discount_product_id`. We can use the `_can_be_invoiced_alone` function to find both regular and loyalty discounts

https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale/models/sale_order_line.py#L1033-L1041
 
    def _can_be_invoiced_alone(self):
        """ Whether a given line is meaningful to invoice alone.

        It is generally meaningless/confusing or even wrong to invoice some specific SOlines
        (delivery, discounts, rewards, ...) without others, unless they are the only left to invoice
        in the SO.
        """
        self.ensure_one()
        return self.product_id.id != self.company_id.sale_discount_product_id.id

https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/sale_loyalty/models/sale_order_line.py#L50-L51

    def _can_be_invoiced_alone(self):
        return super()._can_be_invoiced_alone() and not self.is_reward_line

We just have to be careful not to accidentally include delivery fees because of

https://github.com/odoo/odoo/blob/ee63fe7863dfa0083674dc927c1aa67c9e36c481/addons/delivery/models/sale_order_line.py#L18-L19

    def _can_be_invoiced_alone(self):
        return super()._can_be_invoiced_alone() and not self.is_delivery

The second issue is that we use the untaxed discount amount.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321

This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).

-----
Community PR:
https://github.com/odoo/odoo/pull/223517
Ticket:
opw-4755357

Forward-Port-Of: odoo/enterprise#95435
Forward-Port-Of: odoo/enterprise#92310

Normalize getStrNotes() to handle multiple note formats (JSON array string, array, plain string) and avoid crashes when printing preparation tickets to multiple printers.

Steps to reproduce:
-------------------
* Configure two preparation printers for a pos_restaurant with food categorie.
* Create an order with a note in that restaurant.
* Send the order to the kitchen.
> Observation:
The second printer fails to print the ticket with an (uncaught) JSON parse error (Unexpected token), while the first prints correctly.

Why the fix:
------------
`getStrNotes()` assumed notes were always JSON strings like [{"text":"...","colorIndex":0}]. In practice, notes can be plain strings or already-parsed arrays depending on the update path and last printed changes.
The function now:
- returns joined texts for arrays,
- tries to parse JSON strings and joins texts if it’s an array,
- falls back to the raw string if parsing fails. This makes note rendering stable across printers and prevents the error, ensuring tickets are printed consistently.

opw-5029870

Forward-Port-Of: odoo/odoo#227430

#### Issue:
Quantity, average price, margin and inventory value are wrong in Invoice analysis for invoice lines using packagings.

#### Step to reproduce:
- Choose a product
- Make sure it has a cost, and it differs from sales price
- In the sales sheet, add a packaging
- Create a sale order
- Add the product using the package
- Confirm
- Go to delivery, validate
- Back to sale order create an invoice and confirm it
- Go to "Invoice Analysis"
- Go to Pivot View
- In "Measures" select:
	- Average Price,
	- Inventory Value,
	- Margin,
	- Product Quantity
- In "Total" select:
	- Product

#### Current behavior:
- Those fields display wrong values as they were miscalculated:
	- Average Price		line_balance / number_of_packages * number_of_unit_in_package
	- Inventory Values	account_currency_table.rate * number_of_packages / number_of_unit_in_package
	- Margin			margin_on_one_unit * number_of_packages / number_of_unit_in_package
	- Product Quantity 	number_of_packages / number_of_unit_in_package

#### Expected behavior:
- These fields should be right:
	- Average Price		line_balance / number_of_packages / number_of_unit_in_package
	- Inventory Values	account_currency_table.rate * number_of_packages * number_of_unit_in_package
	- Margin			margin_on_one_unit * number_of_packages * number_of_unit_in_package
	- Product Quantity	number_of_packages * number_of_unit_in_package

#### Cause of the issue:
- As per the refactor of the UoM and packaging, the uom factor field is now the mathematical inverse of the previous uom factor field. This model wasn't updated and used wrong formulas.

opw-5031495

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

Forward-Port-Of: odoo/odoo#227489

Context:
`\ufeff` characters are used in the editor to handle how the cursor behaves when
using arrow keys. In the case of knowledge comments, we want to have 2 cursor
positions at each comment boundary. I.e.: at the first beacon, we want a cursor
position before the anchor (outside of the comment), and one after (inside of
the comment).

Issue:
Since this [commit], empty links receive 2 `zwnbsp` nodes to allow the user to
type inside, instead of 1 previously.

However knowledge comments beacons are not editable and only need one `zwnbsp`,
since we never want to type inside. Furthermore, having 2 and nothing in between
them would cause an issue when their content is normalized, which may lead to a
traceback:

- `link_plugin` executes `selection.anchorNode.parentNode.normalize();` which
  merges 2 FEFF together. However the function `isZwnbsp` does return true for
  one text node with 2 FEFF characters. This means that during the next "add
  feffs" phase, new text nodes with one `FEFF` characters will be added,
  creating a growing loop generating new `FEFF` at every normalization phase.
- Furthermore, merging the nodes in one text node may not result in a new step
  in some cases, which prevent the `history_plugin` from registering the new
  node in time in its `nodeMap`, which may lead to a serialization traceback.

Resolution:
This commit stops using the deprecated `padLinkWithZwnbsp` method to ensure that
there are 3 `zwnbsp` characters for each beacon: 2 around it, and one inside.

[commit]: https://github.com/odoo/odoo/commit/f0eaeb6

task-5046068

Forward-Port-Of: odoo/enterprise#95550

Issue
-----
When using Shiprocket with the "Cash On Delivery", the request sent to the Shiprocket API doesn't contain the amounts discounted by coupons.

Steps to reproduce
-----
- Set an Indian company up (with valid address and some dummy mail & phone)
- Create a customer "IN Cust" (with valid address and some dummy mail & phone)
- Create a product "IN Prod"
	- Sale price: 1000 INR
	- Weight: 100g
	- Set some reference, eg "INPROD"
- Create a Shiprocket delivery method
	- Payment Method: COD
	- Set some "Shiprocket Channel"
	- Enable Debug requests
- In settings, enable "Promotions, Loyalty & Gift Card"
- Go to Sales > Products > Discount & Loyalty
- Create a new program
	- Name: 50% off
	- Program Type: Coupons
	- Change the existing reward to 50% discount on order
	- Generate some coupon
	- Copy the code to the generated coupon
- Create a SO our product and customer
- Use the coupon code & apply the 50% discount
- Add shipping
	- Shiprocket COD
	- Get rate
- Confirm the SO
- Go to the picking & validate it
- Open logs (Settings/Technical/Database Structure/Logging)
- Open the "shiprocket_request_external/shipments/create/forward-shipment" log

--> total_discount is 0

Cause
-----
The problem comes from

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L301

There are 2 issues here.

The first and most important one is how we find the discount lines.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L320

Discounts from coupons don't use the `sale_discount_product_id`, we'll have to define a new function to override in `sale_loyalty` for this.

The second issue is that we use the untaxed discount amount.

https://github.com/odoo/enterprise/blob/a971f55e736f9645eda137fd6dcb574483886483/delivery_shiprocket/models/shiprocket_request.py#L321

This leads to an incoherent total amount, since the tax is computed on the products' full prices. We should instead be forwarding the total discount value (with tax included to offset the taxes applied on the full product price).

-----
Enterprise PR:
https://github.com/odoo/enterprise/pull/92310
Ticket:
opw-4755357

Forward-Port-Of: odoo/odoo#228375
Forward-Port-Of: odoo/odoo#223517

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

Steps
-----
1. Have GeoIP enabled/mocked;
2. have at least 2 pricelists available in eCommerce;
3. have all pricelists restricted to a certain country group;
4. have the 1st pricelist be incompatible w/ the current GeoIP location;
5. open a cart as a public user;
6. check pricelist in back-end (should be correct);
7. go to "Sign In" & create a new portal account without address;
8. check pricelist in back-end (should still be correct);
9. go back to cart with portal account;
10. check pricelist in back-end.

Issue
-----
The first pricelist is assigned to the order, which shouldn't be compatibly with the partner's current GeoIP location.

Cause
-----
The pricelist is recomputed on changing the `partner_id` on a sale order. Commit 6504c0624b990 added a check on the `country_code` context value when retrieving the `property_product_pricelist` for a partner. This context value is currently not getting added during `_compute_pricelist_id`.

Because all pricelists are restricted to a country group, when the pricelist gets recomputed on `partner_id` change, there's no location-independent pricelist to fall back on, which is why the first pricelist is used regardless of country restrictions.

Solution
--------
Add a `_compute_pricelist_id` override which adds the current GeoIP country code to the context when computing the field for website orders.

opw-5000198

Forward-Port-Of: odoo/odoo#228909
Forward-Port-Of: odoo/odoo#225582

**Steps to Reproduce:**
1. Install `l10n_mx_edi_extended` module without demo data.
2.  Set company's country to "Mexico" and switch Fiscal Localization.
3. Deactivate USD currency.
4. Configure CFDI Certificate and activate Testing mode in PAC.
5. Create a new product with "UNSPSC Category".
6. Create an invoice with CFDI to the public and "Definitive" in External Trade.
7. Confirm and send the invoice.

**Sample certificate:**
Certificate file: https://drive.google.com/file/d/1kklNGeRtR08erxWRPfIdeiwheDibcB8M/view?usp=drive_link 
Private key file: https://drive.google.com/file/d/1VJnKVo1doA4cCYPeZBHXKT4JGkbHhOhk/view?usp=drive_link 
Private key password: 12345678a

**Error:**
`ValueError - Expected singleton: res.currency()`

**Cause:**
When sending the invoice, the system attempts to retrieve the USD currency to compute exchange rates. Since the search only considers active currencies, this results in no record being returned, which raises an error in further computation.

**Fix:**
This commit handles the case when USD currency is deactivated.

sentry-6860601127

Forward-Port-Of: odoo/enterprise#94179