The issue was that when extracting field names from an address, the current implementation only considered fields and spaces. Adding any additional characters would break the field names, resulting in invalid field names. For example, given the address line "%(zip)s, %(city)s", the current code would return the fields ["zip,", "city"], where the first field name is invalid. We should only consider what is between "%(<field_name>)s".

Steps to reproduce:

- Go to Contact > Configuration > Countries (Developer mode must be enabled).
- Search for "United States" and then edit.
- In "Layout in Reports", add any characters to the 3rd line where there is the "city" field, and save.
- Open any contact (you may need to refresh).
- The order of fields is now incorrect and does not match the "Layout in Reports".

This fix ensures that only valid field names are extracted from the address line, maintaining the correct order as specified in the "Layout in Reports".

opw-3920886

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

Currently an exception was generated when the user processed an instance refund from
Razorpay, and we get notes as a list in notification data (see  response here [Ref](https://github.com/razorpay/razorpay-python/blob/master/documents/refund.md#create-an-instant-refund)).

error: 
```
AttributeError: 'list' object has no attribute 'get'
  File "odoo/http.py", line 2383, in __call__
    response = request._serve_db()
  File "odoo/http.py", line 1913, in _serve_db
    return self._transactioning(
  File "odoo/http.py", line 1976, in _transactioning
    return service_model.retrying(func, env=self.env)
  File "odoo/service/model.py", line 134, in retrying
    result = func()
  File "odoo/http.py", line 1943, in _serve_ir_http
    response = self.dispatcher.dispatch(rule.endpoint, args)
  File "odoo/http.py", line 2100, in dispatch
    return self.request.registry['ir.http']._dispatch(endpoint)
  File "odoo/addons/base/models/ir_http.py", line 227, in _dispatch
    result = endpoint(**request.params)
  File "odoo/http.py", line 757, in route_wrapper
    result = endpoint(self, *args, **params_ok)
  File "addons/payment_razorpay/controllers/main.py", line 41, in razorpay_webhook
    tx_sudo = request.env['payment.transaction'].sudo()._get_tx_from_notification_data(
  File "addons/payment_razorpay/models/payment_transaction.py", line 328, in _get_tx_from_notification_data
    reference = notification_data.get('notes', {}).get('reference')
```

This commit will fix the above issue by preventing getting the dict data if `notes` in notification data is list type.



sentry-5793000218

Forward-Port-Of: odoo/odoo#179135

Currently, when applying two discounts (from loyalty programs) that are applied on specific products, the second discount value does not match with the setup of the reward.

Steps to reproduce:
-------------------
* Go to the **Point of Sale** App
* Create a new product, P -> Price 100$, no tax applied
* Under **Products** select **Discount & loyalty**
* Create a new loyalty program
  * Rule 10 points per $ spent
  * Reward 1: 10$ on P for 10 points
  * Reward 2: 50$ on P for 40 points
* Open shop session
* Add P to the order
* Add reward 1
* Add reward 2
> Observation: The first reward is 10$ but the second is 55$

Why the fix:
------------
We will use the example from the given steps to explain what happens.

https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1376-L1377

On the first line of the above `discountable` and `discountablePerTax` will be
100. On the second line `discountable` will be 90 as the order total is 90, as the discount is counted here.

https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1417

Here we have `masDiscount` being 50 (`reward.discount`). Thus we end up with `discountFactor = min(1, 0.555)`. This factor is later on used to set the price of the discount line. The price is set up as follow.

https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1426

Where entry one corresponds to the value of `discountablePerTax` which is 100. Thus the discount is valued at `0.555 * 100 = 55.5$`.

To solve this we make `discountable` and `discountablePerTax` account for the discounts that aleady apply on the same product. We then look at what happens in the function `_getDiscountableOnSpecific` as in our case it corresponds to `getDiscountable`.

https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1250-L1251

As this comment says we don't want to discount more than what is available. In our case only 90$ are available since we have already applied the 10$ discount.

https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1269-L1273

We see that when we scan through the order lines, only discount from the same reward as the one we are trying to apply are counted. In short, if we were trying to apply another 10$ discount instead of the 50, then the line would be counted. But since the 10$ and 50$ discounts apply on the same product, they should both be counted.

We want to add more discount lines to `linesToDisount` because at the end, it is used compute `discountable` and `discountablePerTax`.

https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1331-L1341

We want to add the discount lines that applies to at least one product of the current reward. But we also need to check if that common product is on the order. If we imagine reward 1 applied on P1, reward 2 applied on P1 and P2 but we only have P2 in the order then reward 1 should not count when applying reward 2.

We filter on the `reward_type` to exclude lines that are related to free products rewards. 

With the current change there is a difference in behaviors when the discount is a percentage or a fixed amount. Since we now count the discounts at the end, we can remove this part of the code as it would count twice the discounts that are percentages.

https://github.com/odoo/odoo/blob/e01df041b9428cf14cb150bdb0803c6f5ff2d80f/addons/pos_loyalty/static/src/js/Loyalty.js#L1298-L1309

opw-4083557

Forward-Port-Of: odoo/odoo#178352

[FIX] project: restrict access to project in email sent

Before this commit, when the `Project Stages` feature is enabled and the
user set an email template on a project stage, if the user moves a
project to that stage with the email template, an email is sent to the
customer (if set on the project) and the customer can click on the project name
to see all tasks inside that project even if the project is private.

This commit makes sure the project name displayed in the template is
only clickable is the project visibility is 'portal'
(`Invited portal users and all internal users`).

Steps to reproduce:
------------------
1. Install project
2. Go to Project > Configuration > Settings
3. Enable Project Stages feature
4. Set email template to project stage
5. Create a project with a customer set and project visibility is not
   set to "Invited portal users and all internal users".
6. Move the project to the project stage with the email template set.

Current behavior:
----------------
An email is sent based on the email template set but the project name is
clickable to allow the customer to see the tasks of the project in the
portal even if the project is not public.

Expected behavior:
-----------------
The project name should not be clickable inside the email sent when the
project visibility is not "Invited portal users and all internal users".

Close #175396

Forward-Port-Of: odoo/odoo#178171