**Steps to produce:**
- Install project module.
- Go to project > Open any project > Open any task > Click on gear icon.
- Click on Add properies > Set Field type as `Many2one` and Model as `Contact`.
- Now assign value to Property 1 > Click on `External button` > Click on `Save & Close`.

**Issue:**
- The assigned value disappears after saving.

**Root cause:**
- At [1], since `id` is not an active field (see [2]), it is not present in
  record.data, which is expected. However, record.data is then passed to
  m2oTupleFromData, which assumes that the data includes an id because it is
  normally used on data coming directly from the ORM.
- Additionally, since display_name is also not present, m2oTupleFromData falls
  back to record.data.name, which is not proper.

**Solution:**
- Use an ORM read to retrieve the proper display_name of the record before
  constructing the Many2one tuple.

[1]: https://github.com/odoo-dev/odoo/blob/24ccc3faf14ade70b21bf253af16a534df726fc8/addons/web/static/src/views/fields/properties/property_value.js#L87-L89
[2]: https://github.com/odoo/odoo/blob/369ca1e5a154235e80b9ea6af7b3f10442c0939f/addons/web/static/src/model/relational_model/record.js#L793-L795


Before:
<img width="589" height="68" alt="bef" src="https://github.com/user-attachments/assets/b2aeba0c-1c52-4663-9f94-5c7808a882db" />

After:
<img width="613" height="81" alt="after1" src="https://github.com/user-attachments/assets/a3b3d733-929d-4a24-9e17-c73d9569e9b7" />


**opw-5257819**



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

Forward-Port-Of: odoo/odoo#238052

When the company's currency is not UYU we will get an error when doing the convention of the rate return by (UY) BCU (Banco Central Uruguay). All the rates should be used the same date in order to properly do the conversions.

### Steps
1. Create a new Company with country Uruguay
2. Change current logged company to new Company
3. Change the currency to USD
4. Go to Settings, option Automatic Currency rate and configure provider yo [UY] Uruguayan Central Bank
5. Click manual synchronization
6. Check rates  

### Current behavior before PR

All currencies except UYU currency has created taxes with date today.
Only one error in UYU currency that is created with yesterday rate
![image](https://github.com/user-attachments/assets/adfdf9a1-f0cf-4825-bfe4-47ff5c8da2c4)

### Desired behavior after PR is merged:

All the currencies are created with the same date, the correct day that is today rate.

References: LATAM 1341 / ADHOC Task 51716

Forward-Port-Of: odoo/enterprise#85065

Step to reproduce:
- create new journal and a pricelist with different currency (here TWD i.e 36.833 * USD)
- set that pricelist and journal in a pos
- have a product with sales (here 1000$) and cost price (300$)
- create pos and finalize the order with that product
- go to sales > reporting > sales > pivot view
- check margin for that order

Observation:
- the margin is calculated wrong due to improper brackets
- current calculation  ( for TWD currency , multiply with currency rate)
sale price - ( cost price / currency rate)
i.e. `1000 * 36.833 - (300* 36.833 / 36.833) = 36833 - 300 = 36533`


Fix:
- fixed the calculation, used brackets
- actual calculation 
- `(1000 * 36.833 - 300 * 36.833) / 36.833 = 1000 - 300 = 700`

Before
<img width="687" height="97" alt="image" src="https://github.com/user-attachments/assets/3a821a5c-eb12-4eae-9465-1702e9d4ac97" />


After
<img width="679" height="110" alt="image" src="https://github.com/user-attachments/assets/d62dbb1d-6839-4099-90b1-6f9a19576721" />


opw-5166714


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

Forward-Port-Of: odoo/odoo#239407

On a fsm task, using the smart button to go to the invoice, will not give the same domain for the products, if you go from the sale order or directly from the task

Steps to reproduce:
-------------------
* Create a product
	- Purchase: False
	- Sale    : True
* Create a fsm task
* Add products
* Go to the sale order
* Create the invoice (regular invoice)
* Go back to the task
* Go to the invoice using the invoices smart button
* Try to add your product
-> issue it's not possible.

Observation:
---------------
The domain of the search is not the same if we go from the sale order or from the task.

This is because the domain depend on the context and the context is not the same :
[Domain](https://github.com/odoo/odoo/blob/8258ddf12ed6c0495628f7a480d1e2424e756540/addons/account/views/account_move_views.xml#L1134-L1141)

When using the smart button on the SO, some elements will be added to the context, the important one is: default_move_type : "out_invoice":
[SO context](https://github.com/odoo/odoo/blob/18.0/addons/sale/models/sale_order.py#L1453)

Instead when using it on the task, the context does not have that element:

https://github.com/odoo/enterprise/blob/cb79d565031ee0e1bec9db82aa35deb2e1c03576/industry_fsm_sale/models/project_task.py#L325-L327

This will be calculate here in the js files:

[evalContext](https://github.com/odoo/odoo/blob/c3367bd7c6900e42394b006ccf48c3b36a1b87e9/addons/web/static/src/views/fields/field.js#L400)

opw-5135567

Forward-Port-Of: odoo/enterprise#101938
Forward-Port-Of: odoo/enterprise#98612

Currently, the behavior of the "Maximum closing difference" feature with employees depends on the user connected in the backend and not the employee using the pos.

Steps to reproduce:
-------------------
* Set max closing difference as 0
* Have 1 admin user and 1 pos user
* Have 2 employees
* Set admin user and employee 1 as advanced employees of the pos
* Set pos user and employee 2 as basic employees

Steps with admin:
* Make sure you are logged as the admin in the database
* Open pos (could be a session opened by other user)
* Log in with Admin user
* Try to close the pos with a difference of 10 -> You can, ok
* Log in with employee 1 (advanced)
* Try to close the pos with a difference of 10 -> You ca but shouldn't

Steps with pos user
* Now log in the database as pos user
* Open pos (could be a session opened by other user
* Log in with employee 1 (advanced)
* Try to close the pos with a difference of 10 -> You cannot, ok
* Log in with Admin user
* Try to close the pos with a difference of 10 -> you cannot but should

Why the fix:
------------
Employees that have no linked user should not ba able to override the max difference.

Employees who have a connected user should only be able to override the max difference if their user is admin of the pos.

opw-5184041

Forward-Port-Of: odoo/odoo#239770
Forward-Port-Of: odoo/odoo#235356

## Versions
saas-18.3 > saas-18.4
Backport of OE's commit c02eb8584da1cef7d28310d9be947b56a38a5cbd

## Issue
A customer subscribing to a service can checkout without filling its data (incl. country). This leads to a failure of the next payment and a message in the chatter telling that "Automatic payment failed. No country specified on payment_token's partner".

## Steps to reproduce
*Ensure Sales app is installed*
- Create a customer account without filling personal data in;
- Navigate to the shop:
  - Look for a subscription service (ending with "SUB") and add it to cart;
  - Go to the cart and click the checkout button (automatically bypassing the addresses form);
  - Pay with Demo.
- Logout and sign in as admin user:
  - Go to Sales and open the latest SO (related to the test user):
    - Duplicate the SO and activate debug mode;
    - Open "Other Info" tab:
      - Change the subscription starting date for any date in the past;
      - Set the Payment Token selecting the available one; - Confirm the order.
- Navigate to Scheduled Actions:
  - Look for "Sale Subscription: generate recurring invoices and payments" action and open it:
    - Click "Run Manually".
- Come back to the duplicated subscription SO and look at the chatter's last message:
  - OdooBot's message tells that "Automatic payment failed. No country specified on payment_token's partner".

## Cause
Task 4307281 introduced address info bypass to fasten checkout for services but subscriptions, even for services, require the country to be set for recurring payments as per https://github.com/odoo/enterprise/blob/f40e24e67a1664a13acdd01578d8269d084ee421/sale_subscription/models/sale_order.py#L1751-L1757

opw-5412037

Steps to reproduce [18.2+]:

1. Add a dynamic snippet to a website page (e.g., Events).

2. Unpublish all event records.

3. The snippet first appears with a visible header, which then
disappears.

[A]- Starting from [1], the `o_dynamic_empty` class was introduced to
handle the dynamic snippets visibility, and an upgrade script (see [3])
set this class by default on them.

Later in 18.0 (after [2]), the class was changed to `s_dynamic_empty` in
the XML template, while on the JS side, the class used to toggle snippet
visibility was `o_dynamic_snippet_empty`. This class was also added to
snippets on destroy (before saving).

[B]- As a result, a dynamic snippet may end up with:

- `o_dynamic_empty` & `o_dynamic_snippet_empty`: for old (before 18.0) but
edited snippets.
- `o_dynamic_empty`: for old snippets never updated in edit mode on 18.0.
- `s_dynamic_empty` & `o_dynamic_snippet_empty`: for new snippets created
in 18.0.

Remark: the `s_dynamic_empty` class was introduced by mistake and does
not have any associated CSS

Since only `o_dynamic_snippet_empty` has `display: none` in CSS, the
interaction flow became inconsistent (starting from 18.2): snippets were
initially visible, then hidden if no content was found... which caused
the flickering behavior described above.

And because of [B], old snippets with the `o_dynamic_empty` class
will be visible by default in 18.0.

This commit restores the intended (and original) behavior:

- A dynamic snippet should be invisible by default,

- Then the interaction decides (based on actual content) whether the
snippet should be displayed.

[1]: https://github.com/odoo/odoo/commit/63def9c87305dd7773e0592a28fe19d0b63c0878
[2]: https://github.com/odoo/odoo/commit/76cf201e1fc356ad00b27bcdec408c54949df33b
[3]: https://github.com/odoo/upgrade/commit/af5821d9aeb75d09653fc33f14e98fae5f5ba906

opw-5354523

Forward-Port-Of: odoo/odoo#240036
Forward-Port-Of: odoo/odoo#238305

## Issue:
When exporting the XML for a VAT return, the client nihil field was incorrectly set to YES
According to Belgian regulations, this is only allowed on the last report of the calendar year
https://finances.belgium.be/sites/default/files/downloads/165-625-directives-2019.pdf

## Cause:
Prior to 18.3, nihil was a checkbox option on export
Since 18.3, it is automatically selected based solely on a price formula, without checking the report’s date

This PR brings back the Client Nihil checkbox in 19.0
But didn't change the default value
Causing the issue to still be present
https://github.com/odoo/enterprise/pull/99496

## Steps to reproduce:
- Select the Belgian company
- Open the Tax Return and select the VAT Return
- Click Returns and enter an opening date in January
- Click Review for the first available report
- Ignore errors and return to previous page
- Click on Submit -> Download XML
- Before the fix, ClientListingNihil is set to YES

## Potential remaining issue:
The legal document specify that it should also be checked in case of "cessation d’activité"
So it may be interesting to consider adding the option back

opw-5184056