Hello, i am aware that you can do some simple scripting in the “Visible” field in page designer. The screenshot below hides the attribute on a new record.
My questions is it possible to use this functionality to show/hide an attribute/field based on logged in user or user group?
Best answer by SimonTestard
I don’t believe that’s possible as the conditional evaluation for these is based on this syntax and does not allow the use of Context Substitution Variables as far as I’m aware.
So you can do conditional evaluation but only to other attributes/properties that are part of that record’s context (so, other fields available in the list, basically, such as comparing two dates in a given list to determine whether a third field is shown or not)
Technically this could still work but you would first need to create and deploy a custom attribute to that entity to retrieve say, #USER_ID#, in order to then be able to use that field to evaluate whether another field should be shown or not.
This is quite cumbersome to do.
The more normal way to do what you want would be to use different Page Designer Contexts and map those contexts to Users or User Groups, which is indeed easy to do and would achieve conditional visibility.
So, you create a new Page Designer Context, make the field not visible (if that’s what you want to do), and then assign that context through Context Configuration Mappings to a particular UserGroup or Users :)
I don’t believe that’s possible as the conditional evaluation for these is based on this syntax and does not allow the use of Context Substitution Variables as far as I’m aware.
So you can do conditional evaluation but only to other attributes/properties that are part of that record’s context (so, other fields available in the list, basically, such as comparing two dates in a given list to determine whether a third field is shown or not)
Technically this could still work but you would first need to create and deploy a custom attribute to that entity to retrieve say, #USER_ID#, in order to then be able to use that field to evaluate whether another field should be shown or not.
This is quite cumbersome to do.
The more normal way to do what you want would be to use different Page Designer Contexts and map those contexts to Users or User Groups, which is indeed easy to do and would achieve conditional visibility.
So, you create a new Page Designer Context, make the field not visible (if that’s what you want to do), and then assign that context through Context Configuration Mappings to a particular UserGroup or Users :)
+11I have not done. but if those information not available in page, try define and add custom fields for user or user group and use it
I don’t believe that’s possible as the conditional evaluation for these is based on this syntax and does not allow the use of Context Substitution Variables as far as I’m aware.
So you can do conditional evaluation but only to other attributes/properties that are part of that record’s context (so, other fields available in the list, basically, such as comparing two dates in a given list to determine whether a third field is shown or not)
Technically this could still work but you would first need to create and deploy a custom attribute to that entity to retrieve say, #USER_ID#, in order to then be able to use that field to evaluate whether another field should be shown or not.
This is quite cumbersome to do.
The more normal way to do what you want would be to use different Page Designer Contexts and map those contexts to Users or User Groups, which is indeed easy to do and would achieve conditional visibility.
So, you create a new Page Designer Context, make the field not visible (if that’s what you want to do), and then assign that context through Context Configuration Mappings to a particular UserGroup or Users :)
OK, yes that makes sense. Interesting idea with the custom entity holding the userid and using that. And yes, page context is probably the correct way to approach this. Thank you
OK, yes that makes sense. Interesting idea with the custom entity holding the userid and using that. And yes, page context is probably the correct way to approach this. Thank you
No worries at all. Be careful if you go the context route as if you end up with a user being assigned multiple contexts (for example if they’re part of multiple groups), if those contexts both have a configuration of the SAME element, IFS will detect the conflict and WILL revert the user back to the Global Context on that element!
(Contexts are element specific so if a user is mapped to different contexts but each context has configurations on different elements, then no problem there, as there’s no conflict)
You will also possibly need to rebase the contexts when you do updates/upgrades if those elements have been changed by IFS during the update too, just for what it’s worth :)
Enter your E-mail address. We'll send you an e-mail with instructions to reset your password.
