• 1. Description
• 1.1 List of Visibility Rules
• 2. How to use it
• 2.1 Visibility Rules in Panel Menus
• Examples:
• 2.2 Visibility Rules in Toolbars and Ribbons
• Examples
• Steps to use it
• 2.3 Visibility Rules in Tabbars (Pages)
• Customisation of Tabbar Visibility Rules
• Security token Visibility-Rules
• Steps to use it
• 2.4 Visibility Rules in Forms
• Examples:

1. Description

Visibility Rules can be used in the application to show, hide or lock different objects based on the assigned Security Tokens.

Validation Rules can be set on different levels/objects:

• By specifying the visibilityRules on the MenuFunction / MenuStructure level ( on a Ribbon, Toolbar or PanelMenu)
• By specifying the SecurityToken attribute on a Page ( for Tabbar )
• By specifying the SecurityRestrictions attribute on a Form

Visibility Rules are executed in the B1 Application when a screen is loaded or when actions are performed (for eg. when selecting a page in Tabbar) to hide/show or lock the corresponding objects when validation does not pass.

1.1 List of Visibility Rules

2. How to use it

2.1 Visibility Rules in Panel Menus

Depending on the button type, the security restrictions can be configured from the menuStructure or menuFunctions, visibilityRules attribute. For the moment NotRestricted, Customization rules are supported.

Examples:

For Security Token visibility rules use the following visibilityRule on MenuFunction or MenuStructure level( see note at end of page)

{ "NotRestricted": "Token1,Token2" }

To add Security Tokens use the Security Desktop screen. See step by step guide under the existing runbook for Tabbar: “Security Token visiblity rules” - Steps here 👷‍♂️Visibility Rules in Tabbar (pages)

For customization visibility rules use the following visibilityRule.

{ "customization" : "DEMO" }

The customization is a PASOE application setting, which is accessible from the 'Customization' session property.

<customization>DEMO</customization>

Two new CLAPI methods are also available: showPanelMenuButton and hidePanelMenuButton, both receiving as parameter the button name (SCL menuFunctionCode/menuStructureCode).

Note: There are multiple types of panelMenu buttons:

• Buttons with no Dropdown - like saveGridLine, removeGridLine. These buttons are menuFunctions, so the visibilityRules is set on the menuFunction.
• Buttons with Dropdown (contextMenu) - like GridPanelStandard which has a context menu for Multiline, BatchSize etc. This button is a menuStructure, so the visibilityRules need to be set on the menuStructure level.

2.2 Visibility Rules in Toolbars and Ribbons

The PrimaryDOAutorization visibility rule is supported for ribbons and toolbars. For blocks, visibilityRules can be specified on the MenuStructure level and for items it can be defined on the MenuFunction level.

The provided list of tokens is handled like any other OpenEdge CAN-DO list.

Examples

{ "PrimaryDOAuthorization": "CanCreate" }
{ "PrimaryDOAuthorization": "CanDelete" }
{ "PrimaryDOAuthorization": "CanModify" }
{ "PrimaryDOAuthorization": "CanFetch" }
{ "PrimaryDOAuthorization": "CanSaveChanges" }
{ "PrimaryDOAuthorization": "Can*" }

When calling the visibilityRules it will check for the TABLEIO Link Source, which could be the form, and from that form it will read the DISPLAY or DATA link of that form. From the DataSource of the form it will read the catalog SecurityRestrictions and apply the visibiltyRules.

There is one limitation in this version, it only works with one BusinessEntity DataSource.

Requirement:  Setting the rest application settings configuration file, ( .applicationsettings, .restapplicationsettings files) "UseDetailedRequestAuthorizationOnUpdate": true

Steps to use it

1. Set a visibility rule: In SCL Menu Function maintenance, select a menu function and in the Visibility rules add { "PrimaryDOAuthorization":"CanCreate" } or { PrimaryDOAuthorization":"CanCreate,CanDelete,CanModify" } (based on your needs)


2. Set the links: From the designer, open the repository object and select the Flow tab. Create a TABLEIO link, with the Ribbon as Link Source and Form as the Link Target (the Form must also be linked to a DataSource using a DATA or DISPLAY link, to specify the security restrictions of the DataSource Catalog )
3. Set the Security Object: Under “Manage - Security - Security Objects” Create a new record with the name of the DataSource and add the Tokens for the needed actions

4. Set the Security Assignment: Under “Manage - Security - Security Assignments” Create a Security Assignment Maintenance record, Security Realm as SOT(Smart Security Object Token), select the defined records in Step 3




Important Note

In order for any changes to take effect, you need to restart or trim PASOE (after each change)

2.3 Visibility Rules in Tabbars (Pages)

We support hiding Tabbar pages using visibility rules.

This can be achieved by using the 'SecurityToken' attribute on the Page level, in the object designer. There currently are two types of visibility rules supported:

• Based on customisation
• Based on security tokens

Customisation of Tabbar Visibility Rules

These visibility rules are specified using the following format:

restrict:customization:<can-do list of restricted customizations>

The customisation is a PASOE application setting, which is accessible from the 'Customisation' session property.

<customization>DEMO</customization>

It allows designers an easy way to add customised handling to their code.

The provided list of customisations is handled like any other OpenEdge CAN-DO list.

Examples:

• restrict:customization:CUST1 Will hide the page for customisations CUST1
• restrict:customization:!CUST1 Will hide the page for all customisations, except for CUST1

Security token Visibility-Rules

These visibility rules are specified using one of the following two formats:

restrict:token:<list of tokens>

{ "NotRestricted": "<list of tokens>" }

The tokens are part of SCL security and can be assigned to users or user groups. It allows designers to customize the application depending on the user. In order to add new Security Tokens

The provided list of tokens is checked for any restricted tokens, and also includes CAN-DO function support. If at least one of them is restricted, the Tab/Page will be hidden.

Examples:

restrict:token:Token1,Token2

{ "NotRestricted": "Token1,Token2" }

Will be displayed only if Token1 and Token2 are not restricted for the current user.

Steps to use it

1. Under Manage - Security - Security Tokens Add a new token, for eg. “Morse”

2. Under Manage - Security - Security Assignments Add a new assignment record and select your newly created token “Morse”


3. Adjust SecurityToken attribute on the Page level to something like:
Copy

{ 'NotRestricted': 'Morse2' }

Result: Hides the page because NotRestricted is "Morse2", which is different from defined token "Morse"

2.4 Visibility Rules in Forms

Visibility Rules in Form are useful for disabling the form and fields based on security restrictions.

The visibility rule can be specified via the attribute “SecurityRestrictions” on the Form.

Examples:

{ "NotRestricted": "Token1,Token2" }

restrict:token:<list of tokens>

The provided list of tokens, which are part of Security Restrictions, is checked for any restricted token. If at least one of them is restricted, the form will be locked.

{ "NotRestricted": "Morse" }
{ "NotRestricted": "MorseRestrictToken" }
{ "NotRestricted": "Morse,MorseRestrictToken" }

Additionally, the provided list of tokens is handled like any other OpenEdge CAN-DO list. In the example below, if any token whose name begins with "Can" is found to be restricted, the form will be locked.

{ "NotRestricted": "Morse*" }

For an example on how to add Security Tokens, please see the step by step guide under: Security token Visibility-Rules on 👷‍♂️Visibility Rules in Tabbar (pages)

Back to Documentation

Back to Home Page