Difference between revisions of "Visibility Condition"

From SmartWiki
Jump to: navigation, search
(See Also)
 
(30 intermediate revisions by 5 users not shown)
Line 1: Line 1:
The Visibility Condition section of [[Custom Fields]], [[UTA Standard Field Settings|UTA Standard Fields]] and [[Contact and Account Standard Fields]] allow you to use logical statements to determine whether a field is visible or not.
+
{{MySQL Syntax}} The Visibility Condition section of [[Custom Fields]], [[UTA Standard Field Settings|UTA Standard Fields]], [[Contact and Account Standard Fields]] and [[Submit Buttons]] allows you to use logical statements to determine whether or not a field is [[visible]]. Common visibility condition statements are based on roles, types, statuses, and even field values.
  
'''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.
+
'''Note:''' Visibility Conditions take effect when the page is loaded. They will not run dynamically if the condition is based on changing the value of a field that is on the page. If you wish to change the visibility of fields dynamically, you should use the [[Show/Hide Header]] procedure.
 +
<!--'''Examples'''-->
  
'''Examples'''
+
===Basic Condition Syntax===
 +
<!--* To make the field visible after 06 February 2015.
  
* To make the field visible after 06 February 2009.
+
now()>"2015-02-06"
  now()>"2009-02-06"
+
  or
 +
  "@date(currentdate)@">"2015-02-06"
  
  
 
* To make a Contact field visible only to the contact and to System Administrators (''[[roleid]]'' 12345):
 
* 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
+
 
 +
  "@me.userid@"="@userid@" OR @me.inRole(System Administrator)@
  
 
* To make a field visible to a role (''[[inRole]]'' Reviewer):
 
* To make a field visible to a role (''[[inRole]]'' Reviewer):
 +
 +
@me.inRole(Reviewer)@
 +
 +
* To hide a field from those in the role ''Reviewer''
 +
 +
!@me.inRole(Reviewer)@-->
 +
Visibility works by determining the truth of a given condition. For example: the field only shows for someone in the Reviewer role. In that case, the condition syntax would look like this:
 
  @me.inRole(Reviewer)@
 
  @me.inRole(Reviewer)@
  
 +
If the condition is true--that is, the user viewing the page does have the Reviewer role--then the field is displayed.
 +
 +
This can also work with a negative: the field is to be hidden from a Reviewer.
 +
 +
!@me.inRole(Reviewer)@
 +
 +
Note: because the statement must be true, the above syntax is actually looking to display the field to anyone NOT in the Reviewer role.
 +
 +
===More Examples===
 +
{| class="wikitable"
 +
|-
 +
||'''Condition'''
 +
||'''Syntax'''
 +
|-
 +
||Field is only visible if Status is either Draft or Open
 +
||<nowiki>"@status@" in ('Draft','Open')</nowiki>
 +
|-
 +
||Field is only visible when it contains a value
 +
||<nowiki>"@fieldname.length@"*1>0</nowiki>
 +
|-
 +
||Field is visible if the type is NOT "Contract"
 +
||<nowiki>"@Type@"!="Contract"</nowiki>
 +
|-
 +
||Field is only visible after February 6, 2015
 +
||<nowiki>"@date(currentdate)@">"2015-02-06"</nowiki>
 +
|-
 +
||Field is only visible if Start Date is on or after May 1, 2009*
 +
||<nowiki>"@fullstartdate@" >= "2009-05-01"</nowiki>
 +
|-
 +
||Field is only visible if the value of Date Initiated is on or after 2014-01-31
 +
||<nowiki>"@Date Initiated@" >= "2014-01-31"</nowiki>
 +
|}
 +
 +
* '''IMPORTANT:''' for a visibility condition based on the '''startdate''' or '''enddate''':
 +
*:* Use ''''@fullstartdate@'''' rather than ''''@startdate@''''
 +
*:* Use ''''@fullenddate@'''' rather than ''''@enddate@''''.
  
* '''IMPORTANT:''' for a visibility condition based the '''startdate''' or '''enddate''':
+
* ''This will format the stored date as yyyy-mm-dd so it can be compared using < and >.''
::* 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"
 
  "@fullstartdate@" >= "2009-05-01"
 +
 +
<!--** To make the field visible only if the date in the field named '''Date Initiated''' is on or after 2014-01-31
 +
 +
"@Date initiated@" >= "2014-01-31"
  
  
* To make the field visible only if the date in the field named '''Date Initiated''' is on or after 2009-01-31
+
** To hide the field for new Level 1 records until they have been saved once
"@Date initiated@" >= "2009-01-31"
 
  
 +
This should not be done with a Visibility Condition. Use the [[New Record Display]] setting
  
* 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'''
  
* To make the field visible if the Template or Type is named '''Sample''' or '''Example'''
 
 
  "@type@"="Sample" OR "@type@"="Example"
 
  "@type@"="Sample" OR "@type@"="Example"
  
  
* To make the field visible for a user with [[roleid]] 9999
+
** To make the field hidden for a user if they have a [[UTA Role]] of ''XYZ''
  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.
+
  INSTR("[#(?object=contact::criteria=rolename like 'XYZ')~userid~,#]","@me.userid@")=0
  
  
*To make the field hidden for a user with roleid 9999
+
** To make the field visible for a user whose parent company has Organization category 1234
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 visible for a user whose parent company has company category 1234
 
 
  "@me.parent.catlist@" like "%,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 '''Standard Fields'''. [[Custom Fields]] have a separate [[Status Field Permissions|Status Field Permission]] section that can be used.''
 
  
 +
** 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 Permissions|Status Field Permission]] section that can be used.''
 +
*
 +
 +
 +
 +
** To make the field visible only when it contains a value.
 +
 +
  "@''fieldname''.length@"*1>0
 +
*
 +
*:: ''Note: When used with [[Custom Field Type: Text – Multiple Lines|Multiple Line Text fields]] that may contain double quotes, use "@''fieldname''.value@"!="" (See [[Ssescape|SSEscape]] for additional information.)''
 +
*
 +
 +
 +
 +
** More Examples:
  
*More Examples,
 
 
  "@Destination City@"="Toronto"
 
  "@Destination City@"="Toronto"
 
  "@Type@"!="Contract"
 
  "@Type@"!="Contract"
  
 
+
'''Note:''' remember to include the @fieldname@ in quotes.-->
'''Note:''' remember to include the @fieldname@ in single quotes.
 
 
 
 
===Multiple Conditions===
 
===Multiple Conditions===
 
It is also possible to test multiple conditions:
 
It is also possible to test multiple conditions:
 +
 
* For an '''OR''' condition use two pipes (|)
 
* For an '''OR''' condition use two pipes (|)
  
  '@status@' = 'Closed' || "@me.fullname@"="Jane Doe"
+
  "@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''.''
 
''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 (&)
 
* For an '''AND''' condition use two ampersands (&)
  '@status@' = 'Closed' && "@me.fullname@"="John Doe"
+
 
 +
  "@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''.''
 
''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:
 
* 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")
+
 
 +
  ( "@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.''
 
''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==
 
==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.)
+
* 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|SSEscape]] for additional information.)
  
 +
==See Also==
 +
{{DeterminingIDs}}
  
==See Also==
+
** [[UTA Standard Field Settings]]
* [[UTA Standard Field Settings]]
+
** [[Contact and Account Standard Fields]]
* [[Contact and Account Standard Fields]]
 
* [[Determining the statusid]]
 
* [[Determining the roleid]]
 
* [[Determining the typeid]]
 
 
{{VisibilityofCustomFields}}
 
{{VisibilityofCustomFields}}
For More Examples of Conditional Statements
 
* [[Advanced Logic]]
 
 
 
[[Category:Custom Fields]]
 
[[Category:Custom Fields]]

Latest revision as of 14:18, 20 October 2021

This feature uses MariaDB syntax
The Visibility Condition section of Custom Fields, UTA Standard Fields, Contact and Account Standard Fields and Submit Buttons allows you to use logical statements to determine whether or not a field is visible. Common visibility condition statements are based on roles, types, statuses, and even field values.

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

Basic Condition Syntax

Visibility works by determining the truth of a given condition. For example: the field only shows for someone in the Reviewer role. In that case, the condition syntax would look like this:

@me.inRole(Reviewer)@

If the condition is true--that is, the user viewing the page does have the Reviewer role--then the field is displayed.

This can also work with a negative: the field is to be hidden from a Reviewer.

!@me.inRole(Reviewer)@

Note: because the statement must be true, the above syntax is actually looking to display the field to anyone NOT in the Reviewer role.

More Examples

Condition Syntax
Field is only visible if Status is either Draft or Open "@status@" in ('Draft','Open')
Field is only visible when it contains a value "@fieldname.length@"*1>0
Field is visible if the type is NOT "Contract" "@Type@"!="Contract"
Field is only visible after February 6, 2015 "@date(currentdate)@">"2015-02-06"
Field is only visible if Start Date is on or after May 1, 2009* "@fullstartdate@" >= "2009-05-01"
Field is only visible if the value of Date Initiated is on or after 2014-01-31 "@Date Initiated@" >= "2014-01-31"
  • IMPORTANT: for a visibility condition based on 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"

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

Visibility of Custom Fields can also be controlled using: