Visibility Condition

Revision as of 08:14, 11 July 2014 by Arthur Lathrop (talk | contribs)

Revision as of 08:14, 11 July 2014 by Arthur Lathrop (talk | contribs)

This feature uses MariaDB syntax

The Visibility Condition section of Custom Fields, UTA Standard Fields and Contact and Account Standard Fields allow you to use logical statements to determine whether a field is visible or not.

Note: Visibility Conditions take effect when the record is saved. They will not run dynamically if the condition is based on the value in a field on the page. If you wish to change visibility of fields dynamically you should use the Show/Hide Header procedure.

Examples

  • To make the field visible after 06 February 2009.
now()>"2009-02-06"


  • To make a Contact field visible only to the contact and to System Administrators (roleid 12345):
@me.userid@=@userid@ or instr("@me.rolelist@",",12345,")>0
  • To make a field visible to a role (inRole Reviewer):
@me.inRole(Reviewer)@


  • IMPORTANT: for a visibility condition based the startdate or enddate:
  • Use '@fullstartdate@' rather than '@startdate@'
  • Use '@fullenddate@' rather than '@enddate@'.
This will format the stored date as yyyy-mm-dd so it can be compared using < and >.
"@fullstartdate@" >= "2009-05-01"


  • To make the field visible only if the date in the field named Date Initiated is on or after 2009-01-31
"@Date initiated@" >= "2009-01-31"


  • To hide the field for new Level 1 records until they have been saved once
@opportunityid@>0


  • To make the field visible if the Template or Type is named Sample or Example
"@type@"="Sample" OR "@type@"="Example"


  • To make the field visible for a user with roleid 9999
instr("@me.rolelist@,",",9999,")>0
instr checks to see of the 2nd term (,9999,) can be found within the first term (@me.rolelist@) and returns the numeric character position at which it is found. It returns a value of -1 if the search term is not found.


  • To make the field hidden for a user with roleid 9999
instr("@me.rolelist@",",9999,")<0
In this case instr will return false (-1) if the role is not found that will only display the field for users that don't have roleid 9999


  • To make the field hidden for a user if they have a UTA Role of XYZ
INSTR("[#(?object=contact::criteria=rolename like 'XYZ')~userid~,#]","@me.userid@")=0


  • To make the field visible for a user whose parent company has company category 1234
"@me.parent.catlist@" like "%,1234,%"


  • To make the field visible only when the status is Draft or Open
 "@status@" in ('Draft','Open') 
Note: The above Visibility Condition would only be used for Standard Fields. Custom Fields have a separate Status Field Permission section that can be used.


  • To make the field visible only when it contains a value.
 "@fieldname.length@">0
Note: When used with Multiple Line Text fields that may contain double quotes, use "<ssEscape>@fieldname.value@</ssEscape>"!="" (See SSEscape for additional information.)


  • More Examples:
"@Destination City@"="Toronto"
"@Type@"!="Contract"


Note: remember to include the @fieldname@ in quotes.

Multiple Conditions

It is also possible to test multiple conditions:

  • For an OR condition use two pipes (|)
'@status@' = 'Closed' || "@me.fullname@"="Jane Doe"

The above field will be visible either if the status of the record is Closed, OR if the user viewing the record is named John Doe.


  • For an AND condition use two ampersands (&)
'@status@' = 'Closed' && "@me.fullname@"="John Doe"

The above field will be visible only if the status of the record is Closed AND the user viewing the record is named John Doe.


  • You can also use a combination of these, using brackets to control the order of validation:
( '@status@' = 'Closed' || '@status@' = 'Cancelled') && ("@me.fullname@"="John Doe" || "@me.fullname@"="John Deer" || "@me.fullname@"="Dear John")

The above field will be visible only if the status of the record is either Closed OR Cancelled, AND the user is one of the 3 named users.


Note

  • It is usually best practice to use double quotes (") around variables rather than single quotes ('). This is because single quotes are also apostrophes, so if the variable is processed and replaced with a term with an apostrophe it will close the statement and cause a server side error. (In principle the variable could also be replaced with text containing a double quote, also resulting in an error, but double quotes are less commonly stored.) (See SSEscape for additional information.)

See Also