Hello everyone.
We implemented ACL-based control to allow viewing the field without permitting value entry. A Business Rule was configured to set field values at the time of data insertion. A Client Script was implemented to visually simulate that a field contains a value, without actually setting one. Through this approach, we sought to ensure secure field value assignment under full ACL-based control.
(1) ACL
Grant read permission via ACL. Alternatively, it’s not a bad approach to configure rules that indirectly deny permission by granting access only to users other than the intended individual.
(2) Business Rule
We configure a simple rule to update field values upon insert. For more complex cases, script-based implementation may be required.
(3) Client Script
We configured a simple onLoad rule using g_form.setValue. Conditional branching should be implemented in the script to reflect the actual use case. This logic must be consistent with the Business Rule configuration. Given the ACL settings, the value set by this rule is expected to be disregarded at runtime.
In cases where it is undesirable for the entered content to exactly match its visual representation, or where user input is fundamentally not trusted, or where phrasing and display must be customized per user, it is possible to design the system to minimize data contamination under such conditions.
However, if—for example—only two individuals within the organization are shown a special display, while data visualization aims to treat all users' data at the same level of granularity, the situation remains visible only on the screen. As a result, users may be unaware of how their input was actually recorded, making it highly likely that neither they nor others can verify what they truly entered.
Thanks regards.
