Behaviour: Field Visibility

Understanding Field Visibility

Field Visibility, also known as Field Permissions, is for controlling when parts of your form should show and hide, and when they are editable. You will be able to set different rules for those in different project roles.
An example of setting up field visibility is seen below, but a further example is available in this tutorial.

 

Defining Field Groups

Rather than setting a ruleset for each individual field on the form, you group together your form fields into groups.

Go to Admin > Infocapture > Your Project > Field Visibility > Manage Groups

You'll see all the fields you've created, currently in one group called 'Unassigned'

Click 'Add New Group' and create a new group name, e.g. Manager Comment Fields

Now look for the fields you want to control in the Unassigned group. Tick those that you wish, select the Manager Comment Fields group from the list, click Move.

Finally, click the Save button at the top of the page.

 

Creating a rule

N.B. You will first need at least one Field Condition to choose when your field(s) should show and hide.

Using the breadcrumb or the back button, return to the Field Visbility screen. You will see there is now a table for the group you have created, although it does not yet contain any rules.

You will define your field visibility rule using at least one Field Condition, and you will specify what each project role should be able to see. Let us start with a simple example to explain.

I am using the Field Condition Default (always). This is the Field Condition that is always true. It's especially useful for Field Visibility rules, and you will find you will use it a lot. 
I want my visibility rule to be active at all times, so I'm using that.

Under the "All" column, I click into View and choose 'Allow'.
Again under the "All" column, I click Edit and choose 'Allow'.
N.B. If your system was last updated or installed before May 2018 (Version 8.3) you will not see the 'All' role, and each Project role will need to have its permissions defined individually.
Both of my project roles (human resources and admin), as well as the form specific roles (submitter and handler), all change to allow.
I've now set a rule that allows any user to both see and edit my field.
However - this rule is essentially useless! The behaviour will be the exact same even without this rule. Any of my users could view and edit these fields already, because I haven't set any restrictions yet.

So now I'll make this change:

I've clicked into the human resources column, and chosen 'Deny' for view and edit.
Notice that the 'all' column automatically changed to 'Mixed' to indicate that there are differences in the permission between roles.

What my rule now means is that anybody from human resources wouldn't be able to see my field, only the admin role can.
Unless they are the individual who submitted the ticket, or they are the one to whom the form is currently assigned, in which case they can.

I decide I don't want to have that extra permission to allow that if they're the submitter or handler, so I make this change:

I've changed the view and edit rights for the submitter and handler to Not Set.
Not Set
means that it won't make any changes to the permissions already been applied. In this case - if the user is the submitter or the handler, don't make any changes to what's already being decided by what role they're in, human resources or admin.
What I've also changed is to allow View rights to Human Resources, but I've left Edit as Deny.

The effect of this rule is that:
Any user from Human Resources can see my field, but can't edit it.
An admin can both see and edit the field.
A submitter or a handler of a form isn't granted any extra permissions, so it still depends on whether they're in Human Resources or Admin.

An important rule in understanding Field Visibility is that it reads through permissions rules like a book: left to right, line by line. If there's a conflict, it will go with whatever rule it last processed.
This is why I had to change Submitter and Handler to Not Set. Before I did so, those rules were being read after it had processed the view/edit permissions for the Human Resources role. So although I'd denied Human Resources permission, it was then allowed again by a later rule that said they were allowed (if submitter or handler).

Now I want to take my rule further. I want it to be the case that if a city in the UK is selected, then I do want Human Resources to be able to edit that field.
I now add in another field condition set on the next line.

You can see here that Human Resources are allowed to edit when this Field Condition is in effect.
As this Field Condition comes after the Default (always) condition, it is being processed afterwards and has 'priority' where the conflict occurs over whether Human Resources can or can't edit the field. But only when 'City is in UK' is true - at all other times it's not true and therefore not in effect, so my Always condition is in effect instead.

If you wish to rearrange the Field Conditions, grab the double bar icon on the far left to drag and drop the order.

What would happen if I swapped those two conditions around? It would not work!
In the event that my City is in the UK condition was true, it would be superceded by my Always condition as it was processed afterwards.

Always remember: The Default (always) condition must always go at the top of the table
If it appears anywhere other than the top, it will supercede any other condition as it is always true.

Field permissions are incredibly useful when used well. 
Don't forget - keep everything simple! Too many roles and too many roles are cumbersome and often inefficient. Here's an example of a Field Visibility rule that may be unnecessarily complex:

What can't be seen in this image is that the table extends to the right for a further 5 project roles, as well as the submitter and handler columns.
In this instance, there were 9 project roles and hundreds of field condition sets.
After reviewing, it was found that a huge number of rules and roles were so similar or identical, that they were unnecessary. The roles, field conditions, and field visibility rules were able to be reduced greatly in number.

Keep your rules simple!


Common questions

I can't see a table to add rules into?
The field(s) needs to be in a Field Visibility Group. Go to 'Manage Groups' and make sure it's in a group, and save. You'll then see a table to start adding rules.

The page doesn't change when I make the selection on the form that needs to reveal my hidden fields
Checkout the form, edit that field. Ensure you've checked Reload form on changing. You need the form to reload itself so that it can check through all the Condition rules, and apply any subsequent visibility rules.

I've checked both of the above but my rule doesn't work, the field is always hidden
Have you thought about the order of your Field Conditions in the table? As described in my City is in UK example above, sometimes one Field Condition is in effect more often than another, and is superceding the other.
If your logical rule is trying to say Hide field if X, unless Y..... then your field condition set for X needs to come first and Y needs to come second.

I'm still not clear. Do you have another example to help me understand?
Try this tutorial here for another example.

 

Recommended next article:
Automatic Changes

 

Created on 9 August 2018 by Jon Mulhern. Last modified on 14 August 2018

Was this helpful?  

0 Likes
Share