Configure Field Level Security
Field Level Security (FLS) allows you to control access to specific fields, summation options, values and value sets on a per-user or per-group basis.
Note
- You cannot use field level security to hide field groups.
- Field level security should not be applied to users who are SuperADMIN administrators. Configuring FLS for these users is not recommended.
- Do not apply field level security to the default summation option. This must always be available to all users.
- If you have weighted databases, do not apply field level security to the main weight.
- If field level security is applied to a field or field item that is configured as a mandatory field then users will not be able to access that database using SuperWEB2 as this is considered an invalid configuration.
For example, if you block access to an entire field with field level security then you cannot also make that field mandatory.
However, it is possible to configure a field to be mandatory if only some of the field items within it have field level security applied to them. This can be useful if you are restricting access to a subset of data for particular users, as it can be used to ensure that the results are always filtered according to the field with restricted values. For example, if you are blocking access to data for specific states you can require the geographical field to always be in the table so that users cannot see any data for the hidden states.
- Before you start configuring permissions, make sure you understand the Permissions Model - Inheritance and Conflicts.
To implement FLS you need to log in to SuperADMIN and use the cat command.
The basic syntax is as follows:
cat <dataset_id> [ <item> ] access {<user>|<group>} read {true|false}Where:
| Parameter | Description |
|---|---|
<dataset_id> | The ID of the dataset. |
<item> | The ID of the item to apply security to. This can be a field, summation option, value, or value set. You can also omit this to apply the permission to the whole dataset. In some cases you can use the item's display name (the name displayed to end users in the client) instead of the ID.
If the item is nested within a hierarchy (e.g. it is a value within a value set), then you must specify each level of the hierarchy, separated by spaces. For example, the following command sets security on the value Victoria, which is nested beneath Area/State: cat bank 'Area' 'SXV4__Retail_Banking__C_State' 'Victoria' access vicuser1 read true See the section on working with hierarchies below. |
{<user>|<group>} | The user or group this setting applies to. |
{true|false} |
|
Examples:
| Example | Description |
|---|---|
cat bank 'Customer Profit' access bankusers read false | Denies access to the Customer Profit summation option for all users in the bankusers group. |
cat bank 'Area' 'SXV4__Retail_Banking__C_State' 'Victoria' access vicuser1 read true | Allows access to the value Victoria for the user vicuser1. In this example Victoria is a value within a hierarchy, so each level of the hierarchy is specified. |
How Do I Find the Field Display Names or IDs?
Fields have both a display name (the name that is displayed to end users in the client) and a unique internal identifier. You can only use the display name in the cat command if it is unique within the dataset.
If you attempt to use a display name that is not unique, SuperADMIN displays an error message:
> cat bank Customers access vicuser1 read false
[3] values found for [Customers]. Use item ID instead of NameUse these commands to find the display name or ID of a field:
| Command | Description |
|---|---|
cat <dataset_id> fields | Displays all the fields in the specified dataset, showing the field type and display name. |
cat <dataset_id> <field> | Displays the properties for the specified field, this includes the ID and any value sets attached to the field. |
Working with Hierarchies
In the sample Retail Banking dataset, the Area field is the top level of a geographic hierarchy.
To explore the hierarchy, use the command cat bank <field>
> cat bank Area
[ XTAB Field : 'Area' ]
[ ID : 'SXV4__Retail_Banking__F_Customer__Area_FLD' ]
[ Value Set : 'SXV4__Retail_Banking__C_State' ]
[ Value Set : 'SXV4__Retail_Banking__C_Geography_2' ]
[ Value Set : 'SXV4__Retail_Banking__C_Geography_1' ]
[ Value Set : 'SXV4__Retail_Banking__C_Geography_0' ]To set security on an item in the hierarchy, you must specify the full "path" to the value, with each level of the hierarchy separated by a space.
For example:
> cat bank 'Area' 'SXV4__Retail_Banking__C_State' 'Victoria' access vicuser1 read true
> cat bank 'Area' 'SXV4__Retail_Banking__C_State' 'New South Wales' 'Sydney' access vicuser1 read falseFinding Value Set Values
To set security on a value set value you also need to specify the full "path" to the value.
You can find the values using the command:
cat <dataset_id> <item> valuesFor example:
> cat bank Occupation values
[ Value : 'Clerical' (id:2) ]
[ Value : 'Executive & Managerial' (id:1) ]
[ Value : 'Home Duties' (id:7) ]
[ Value : 'Independent Means; Retired; Pensioner; Unemployed' (id:8) ]
[ Value : 'Primary production' (id:4) ]
[ Value : 'Professional' (id:0) ]
[ Value : 'Sales' (id:3) ]
[ Value : 'Self employed' (id:A) ]
[ Value : 'Staff' (id:X) ]
[ Value : 'Tradesmen' (id:5) ]
[ Value : 'Transport & Recreation' (id:6) ]
[ Value : 'Unemployed' (id:J) ]
[ Value : 'Unknown' (id:N) ]
[ Value : 'Not Applicable' (id:-1) ]The values correspond to the display names shown in SuperSTAR clients, and the IDs (e.g. id:J) are the codes for each value.
To set Field Level Security on one of the values you need to specify the full path to the value. For example:
cat bank Occupation 'Executive & Managerial' access vicuser1 read falseChanging Settings for All Values in a Value Set in Bulk
It is also possible to use a single command to allow or deny access to all the values in a value set. This is useful for cases where you have a large value set and you want to give a user access to a small number of the values in it. Previously, you had to specifically deny access to every value individually. Now, you can run one command that denies access to all the values and then enable just the specific individual ones.
To do this, use the following commands:
Allow or deny access to all the values in the specified field
cat <dataset_id> <field> values access {<user>|<group>} read {true|false}Allow or deny access to all the values in the specified value set
cat <dataset_id> <field> <valueset> values access {<user>|<group>} read {true|false}You need to specify the full path to the value set, as described above.
Example
For example, the following commands prevent user2 from accessing any values on the Age field, except for 18, 19 and 20:
cat bank Age values access user2 read false
cat bank Age '18' access user2 read true
cat bank Age '19' access user2 read true
cat bank Age '20' access user2 read trueIf you subsequently decide you want to allow user2 to access all of the values on Age, you can revert the setting by running this command:
cat bank Age values access user2 read true