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

BLOMASKY wrote
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

ACDC wrote
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

BenHayat wrote
BLOMASKY wrote
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

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

PointsWell wrote
BenHayat wrote
BLOMASKY wrote
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
[attachment=0]Screen Shot 2018-12-09 at 13.03.09.png[/attachment]

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..

FormConditions.zip

37.29kB

FormConditions.zip

37.29kB

BenHayat

ACDC wrote
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.

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

idpSteve wrote
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..

@[deleted] : 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

idpSteve wrote
Interesting..

@[deleted] : 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.

idpSteve

Ok, this makes sense. Thanks.

In my case a user can see the data in the hidden fields, or change it, simply by selecting something different from a dropdown. It isn't something confidential or secret, so it isn't an issue. I can see how this is a problem to some. Thanks for explaining.

bwalk

This was a great read, very informative.
Thanks for the education.