Read only directly/conditionally to behave the same way to make the field uneditabe.

[Ashif Malayil]

shalmaxb, both are direct restricting. No dynamic functioning is possible.

[shalmaxb]

perhaps in role/field level it could work

[Ashif Malayil]

victor, you are right, but I want to set up a restriction for the Assigned User field. The goal is to ensure that any changes to this field are made only through specific access controls. However, when I use dynamic logic to apply restrictions, it still allows edits to these records while mass updating or import.

Where I can't filter based on whether the field is restricted or unrestricted. Ideally, it should work such that if the field is restricted, it should not be updated, while the rest of the records should update as intended.

This is the scenario I am currently working on.

[victor]

Of course, before writing the answer.
It is illogical to put in Administration > Entity Manager > Entity_name > Layouts > Mass Update fields that are read-only in any way.

[Ashif Malayil]

It's how it works currently. In the future, it's planned to force read-only dynamic logic in the backend including the mass-update. But it will the backend only check for mass-update, it will be still available in the frontend.

yuri This is indeed a must have feature, as both functionalities direct read-only and dynamic read-only logic serve the same purpose. However, when dynamic logic is applied, its purpose is not fully realized, especially since it doesn't reflect during mass updates.

It would be ideal if the same dynamic logic applied universally, including in the List View, to ensure consistency across all areas of the system. This would greatly enhance the user experience and make the functionality more robust.

I hope we can see this improvement in future updates. You are doing a fantastic job, and your continued efforts are truly appreciated. Looking forward to the incredible features you’ll introduce in the updates to come!

[Ashif Malayil]

If you make the field available for reading through the Read-only option or through the Сonditional option, then it will be logical to simply remove Assigned User from Mass Update.

Have you done this before, i think it's not working like that now.

[yuri]

It's how it works currently. In the future, it's planned to force read-only dynamic logic in the backend including the mass-update. But it will the backend only check for mass-update, it will be still available in the frontend.

[victor]

If you make the field available for reading through the Read-only option or through the Сonditional option, then it will be logical to simply remove Assigned User from Mass Update.

[a.slyzhko]

Hi!

Field param 'Read Only' is applied in both front-end and back-end. But it's not the same with dynamic logic. All parameters set via panel (screenshot in the attachment) are front-end only. Which is sad, but we have what we have.

[Ashif Malayil]

Hello,

I encountered an issue with the Assigned User field in my system. Here's what I observed:

1. When I mark the Assigned User field as "Read Only" directly (by checking the Read Only box in the field settings), I am unable to mass-update the field. While performing a mass update, the field appears as None, making it uneditable.
2. Instead, I tried adding a conditional option to make the field read-only (instead of directly marking it as read-only by checking the box). However, in this case, while performing a mass update, the Assigned User field remains editable, unlike the first scenario where it was uneditable.

I expected both approaches marking the field as read-only directly and conditionally to behave the same way since their purpose is to prevent editing the field. However, the outcomes are different in the context of mass updates.

Can anyone explain why this discrepancy occurs or suggest a way to ensure consistent behaviour?