This update corrects a technical issue in the Romanian localization reports module that prevented the correct handling of date formats. The change ensures that date information is consistently formatted as strings, resolving potential reporting errors and improving data accuracy. This update focuses on internal reporting processes.

Options dict is not supposed to contain date objects.

This update restores the Sales Order (SO) and Service Order (SOL) buttons within the project updates view for field service projects. Previously, these buttons were accidentally removed, preventing users from easily accessing related sales information. This change ensures users can seamlessly link project updates to their corresponding sales orders.

Versions:
----------
- 17.0

Steps to Reproduce
------------
- Create a product and add the template of the field service project.
- Create a sale order.
- Open the project updates.
- We do not see the SO and SOL buttons.

Issue
------------
- SO and SOL smart button was removed on project updates in this commit
  https://github.com/odoo/enterprise/commit/7a82c52fb007ad0f827dd5d124f80d6195bff919

Fix
----------
- We are adding the SO and SOL buttons back.
- So the user can at least see the linked data.

task-3887972

This update fixes a potential upgrade issue caused by incorrectly mapping window actions to experimental grid views. Removing grid views previously led to problems during updates, particularly when uninstalling related modules. This change ensures that grid views are properly handled, preventing future upgrade complications.

When a grid view is removed we should cascade the removal to the window actions mapping. Grid views are considered experimental. They do not have a `_get_default_grid_view` method, and crafting an acceptable general one is close to impossible due to grid views' requirements in terms of the model fields.

Allowing the grid mapping for window actions have been proven to cause issues during upgrades if clients uninstall one of the few modules providing grid views (like analytic_enterprise).

Forward-Port-Of: odoo/enterprise#74912

This update prevents the creation of templates when uploading PDF documents for signature processing via the 'Upload a pdf & sign' button. Previously, users could inadvertently save template information. This change ensures a cleaner workflow and avoids unnecessary data storage.

When uploading a pdf through "Upload a pdf & sign" button, no template should be saved.

Hence the "Template Properties" button shouldn't show up. This commit aims to hide the button for this type of files.

Task: 4317966

Forward-Port-Of: odoo/enterprise#73912

A bug was causing two 'Sign Now' buttons to appear in the signature request dialog. This has been corrected by adjusting the button visibility condition to ensure it disappears when either condition is met. This improves the user experience and prevents confusion.

Version:
- 17.0

Step to reproduce:
- upload sign template
- click on sign now button on template

Issue:
- two sign now buttons are visible to user

Cause:
- there is an issue in condition to make button invisible as it require both the condition to be true to make button invisible

Solution:
- change condition which will make button invisible when any one condition true.

task-4234996

This update fixes an issue where clicking between buttons in the softphone interface would unexpectedly generate an input field. The fix ensures that input is only created when a user actively clicks on a button, improving the user experience and preventing unwanted data entry.

Issue:
Clicking the space between buttons but no click on any buttons, a input of "123456789*0#" will be generated.

Fix:
Do nothing when click in this situation, only generate input when clicking on buttons.

This update resolves an issue where incoming call ringtones were playing across all open tabs in Odoo. Now, ringtones will only play on the main 'master' tab, creating a cleaner and less disruptive user experience. This improves usability and reduces potential confusion for users.

Currently when receiving incoming calls, it's possible that all opened tabs will play the ringtone. To reduce the chaos, we now only play the incoming ringtone on the master tab.

Task-4402909

This update fixes an issue where users were seeing work orders assigned to other employees, even when using the 'My Work Orders' filter. The problem stemmed from incorrect cache handling after a PIN code was entered. Now, users will only see work orders assigned to their own account, ensuring accurate shop floor visibility.

### Steps to Reproduce
* Navigate to the Employees app and set a PIN code for Mark Demo
* In the Manufacturing app, assing a work order to Mark Demo and another to Michael Admin
* Open the Shop Floor interface, adding Michael Admin and Mark Demo as active employees
* Click on the My WO filter and select Michael
* Switch to Mark Demo and enter his PIN code

### Current Behavior
* The work orders assigned to Michael are displayed for Mark, even with the My WO filter enabled.

### Expected Behavior
Only the work orders assigned to Mark should be
displayed

### Reason
This issue occurs when a PIN is activated for an employee. When the PIN validation pop-up is displayed, the cache cleanup is performed for the previously logged-in user rather than the newly connected user. Consequently, the old user's workorders remain visible because the cache is not refreshed correctly.

### Fix
Ensure that the cache is cleared only after the PIN is successfully validated and the user is connected. Additionally, verify that the My WO filter corresponds to the newly connected user before updating the cache. This will ensure that only the relevant work orders are displayed.

opw-4256568

This update fixes an issue where the kitchen display incorrectly prioritized display lines when reducing product quantities in POS orders. Now, the system correctly sorts display lines based on their stage (e.g., 'To Cook', 'Ready'), ensuring the most relevant line is updated first. This improves the efficiency of order preparation.

In a POS restaurant order, when reducing the product quantity of an order line, the reduced display line in the preparation display was always the first one created, regardless of which order line was changed.

Steps to reproduce:

1.  In the POS restaurant, add a product with a quantity of 2 and an internal note. Confirm the order.
2.  Add another order with the same product and internal note but with a quantity of 5.
3.  In the kitchen display, change the stage of the first display line (quantity 2) from "To Cook" to "Ready."
4.  In the POS, reduce the quantity of the second order line (quantity 5) to 4.

Issue: The system reduces the quantity of the first display line (the one in the "Ready" stage).

Cause: In `_process_preparation_changes` of `pos_order.py` in the `pos_preparation_display` module, display lines are filtered and sorted based on their creation order. However, since there is no 1-to-1 relation between display lines and order lines, it is impossible to directly target specific display lines.

Fix: After this commit, display lines are now sorted based on their stage. Priority for quantity reduction is given to the line in the earliest stage. 

opw-4354093