Is there a way to Show/hide an attribute on a condition?

[BenHayat]

Guys, I need to be able to show/hide certain attributes on a form using aware's widgets and not using HTML form based on certain condition at runtime.
Like in the following Pic, I need to show/hide Skill set.



But I can't find any property, like visible to set

[BLOMASKY]

I am probably missing something, but what about if you have a process that runs BEFORE calling the form that does a READ PROTECT?

Bruce

[BenHayat]

I am probably missing something, but what about if you have a process that runs BEFORE calling the form that does a READ PROTECT?

Bruce

I kind of thought about that, but that solution is more static. The screenshot is a sample for the sake of this post. But in reality, I need something more dynamic. For example, a user's selection from a radio button would trigger what other attributes to show or not. So a process before form is too early.
What we need is a conditional visibility based on data entered before, just like applicability feature we have elsewhere.

[ACDC]

What we need is a conditional visibility based on data entered before, just like applicability feature we have elsewhere.

I agree, something very simple that renders huge results. Each attribute should have an Applicability condition.

I use an invisible separator containing the attribute(s) as a workaround, you can hide it based on an applicability rule and then have a rule on the object that manages it dynamically when there is a form change (recalc on forms) and it behaves elegantly as opposed to READ PROTECT

[BenHayat]

What we need is a conditional visibility based on data entered before, just like applicability feature we have elsewhere.

I agree, something very simple that renders huge results. Each attribute should have an Applicability condition.

I use an invisible separator containing the attribute(s) as a workaround, you can hide it based on an applicability rule and then have a rule on the object that manages it dynamically when there is a form change (recalc on forms) and it behaves elegantly as opposed to READ PROTECT

Oh yes, yes Tony.
Forgot about the separator having visibility feature. I wish this visibility would be added to each attribute.
Thank you Tony. Great workaround.

[PointsWell]

I am probably missing something, but what about if you have a process that runs BEFORE calling the form that does a READ PROTECT?

Bruce

I kind of thought about that, but that solution is more static. The screenshot is a sample for the sake of this post. But in reality, I need something more dynamic. For example, a user's selection from a radio button would trigger what other attributes to show or not. So a process before form is too early.
What we need is a conditional visibility based on data entered before, just like applicability feature we have elsewhere.

IF BO.RadioButton<> 'Show' OR (BO.RadioButton WAS CHANGED AND BO.RadioButton <>'Show') THEN READ PROTECT BO.SkillSelect

Then check Dynamic

Screen Shot 2018-12-09 at 13.03.09.png (17.03 KiB) Viewed 18826 times

The rule will then work when you change the Radio Button setting.

It would be easier to have conditional visibility as a field setting.

[BenHayat]

I am probably missing something, but what about if you have a process that runs BEFORE calling the form that does a READ PROTECT?

Bruce

I kind of thought about that, but that solution is more static. The screenshot is a sample for the sake of this post. But in reality, I need something more dynamic. For example, a user's selection from a radio button would trigger what other attributes to show or not. So a process before form is too early.
What we need is a conditional visibility based on data entered before, just like applicability feature we have elsewhere.

IF BO.RadioButton<> 'Show' OR (BO.RadioButton WAS CHANGED AND BO.RadioButton <>'Show') THEN READ PROTECT BO.SkillSelect

Then check Dynamic

Screen Shot 2018-12-09 at 13.03.09.png

The rule will then work when you change the Radio Button setting.

It would be easier to have conditional visibility as a field setting.

Serious? Never knew READ PROTECT works in interactive mode.
Thanks!

[ACDC]

Using READ PROTECT to expose attributes on a form for the sake of simple form design is an overkill. All the rules on the object will be fired when there is no need for this. We need something simple that runs on the form without resolving all the rules

READ PROTECT (for this purpose) works fine if you don't have many object rules, but on a complex object with many rules, its a dog

[idpSteve]

Try this bsv and see if it is what you want..

You can remove the separator look with some javascript and make it look like regular attributes on a form. If this suits your needs I can help with that. Let me know..

[BenHayat]

Using READ PROTECT to expose attributes on a form for the sake of simple form design is an overkill. All the rules on the object will be fired when there is no need for this. We need something simple that runs on the form without resolving all the rules

READ PROTECT (for this purpose) works fine if you don't have many object rules, but on a complex object with many rules, its a dog

ACDC is right with rules getting re-evaluated. This is my most complex, biggest and with most rules, and that's why the form is big and complex if I put every attribute on it. I need to be able to show/hide the attribute.

I created a new FR thread related to having Visibility property for each attribute.
PLEASE go in and place your vote and desire for support to consider it.

[aware_support]

Dynamic protection rules have been designed to dynamically hide/show attributes on a form.

Code: Select all

Using READ PROTECT to expose attributes on a form for the sake of simple form design is an overkill. All the rules on the object will be fired when there is no need for this

Not true. Only dynamic rules will be executed.

If you do not want to use them (and I don't understand why) you will have to use scripts (which will require you to know some Kendo UI stuff, but it is doable).

We will not be supporting applicability conditions in attributes.

[idpSteve]

Using separators works fine for me, it's not a lot of extra work and is very responsive.

[PointsWell]

Using separators works fine for me, it's not a lot of extra work and is very responsive.

Be mindful that this approach is only hiding the field on one form, so needs to be repeated everywhere the condition is applicable. READ PROTECT hides the field based on the condition EVERYWHERE - all forms all queries all processes (depending on the EXCEPT use).

Also the Separators approach potentially allows for the injection of data via the developer console of a form and then its use elsewhere. The READ PROTECT limits the prevents the use of the data (to different user levels depending on whether you use EXCEPT)

All caveated with 'As far as I understand (and have used READ PROTECT)'

[idpSteve]

Interesting..

@PointsWell : Would having separators then be less 'safe' than showing fields on a form and just having a user ignore them? I'm not sure if you're saying someone would be able to add data to a field hidden in a separator, or if you're saying using a separator is an added risk that doesn't exist on a form without separators.

[PointsWell]

Interesting..

@PointsWell : Would having separators then be less 'safe' than showing fields on a form and just having a user ignore them? I'm not sure if you're saying someone would be able to add data to a field hidden in a separator, or if you're saying using a separator is an added risk that doesn't exist on a form without separators.

Using hidden fields via CSS is moving the control from server side to client side. The use of separators is not risking in and of itself, but the use of css hide to take the separator away creates (potential) risk.

In your example create a staff record via the UI. Then go to the database table and manually add data to another field that should remain hidden. Then return to your UI, view the record you’ve just modified and then open up the developer console. That “hidden” data will be served to the browser. Then change the hidden value (via the console). Now save.

Obviously in the example we are talking about we are hiding the field to guide the user to complete fields, but if we were using hide as a means of preventing one user from seeing data that should be available to another then this route has risk.