Document toolboxDocument toolbox

Field Level Security (FLS)

Owned by Tom Wyczółkowski
Last updated: Mar 19, 2024 by Maciej Zabielski
3 min read

Introduction

Administrator can control access to specific Metadata Fields inside of an Object, based on User or Role.

This is achieved thanks to Field Level Security, later referred to as FLS. Each Object Class can have multiple FLS sets defined. Each set contains a list of all fields available in a given Class and a set of basic user rights, like Visible, Read Only, etc.. Each FLS set can have users or groups assigned. FLS as a result is applied to all objects of a given class, rather than single, specific object instance. 


Example: When a User logs into a system and requests an Object, first base security Scheme is checked. If Object Level access is granted, FLS is applied to objects metadata. If the Object contains, lets say, 10 fields of metadata, a User might be able to see only 5 of them. An Administrator might want to decide, which of those 5 fields a User can update. 


FLS system can also be used "on demand" to influence metadata sets shown by specific Tesselets, for example, show only selected metadata fields in object properties preview.

FLS Requirements

FLS definition

  1. Any number of FLS (a set of rights for all class fields) can be defined for each class

  2. FLS lists all fields for class and extends them by special properties:

    1. Read Only (when checked, the field will become read only)

    2. Hidden (data is transferred to the client, but corresponding schema will contain this property as indication for different processing on client View)

    3. Not Available (this field is not available to the user - it is not transferred, cannot be displayed or updated)

  3. Each FLS can have users, groups or roles assigned.

  4. There is at least one, default FLS for class (default FLS cannot be deleted)

FLS and Schema processing

  1. FLS is specific to object class and user - not single object instance

  2. Data request usually consists of two steps:

    1. retrieving class schema that is needed for creating display and store models

    2. retrieving raw data

  3. Schema must be processed through FLS, as it should contain information about properties like "read only", or should not have fields that are not available to selected user

    1. Base schema is retrieved from HDDB or from cache

    2. System checks if there is any applicable FLS (or multiple FLS) for current user, if not, default FLS is used

    3. If multiple FLS are found, they are combined and most restrictive set of properties is used. 

    4. Schema is modified according to FLS (field properties are changed, fields removed)

  4. Object data during GET request is filtered through FLS/Processed Schema in HRIS zone (fields removed - other properties stored in schema)

  5. Object data during update is also filtered through FLS/Processed Schema in HRIS zone to obtain symmetric security (user cannot update unavailable or read only fields). 

  6. During update, Transport Object content with update package is filtered before request is sent to HDAS.

FLS Rights

Right

Description

Right

Description

Not Accessible

This field is removed from object class schema and from the data.

It's not possible for the user to view or edit this field.

Read Only

This field is read only. It is grayed out on the user interface.

Any changes are not accepted for this field.

Hidden

This field is rendered as hidden, but it's data is still accessible if needed

for read/write operations.

 

FLS and possible conflicts with other settings

System does not enforce strict rules and it is up to an Administrator to setup profiles that actually makes sense.

For example, HyperDoc requires that each object class has at least ID and Label field. If an Administrator will set field that is used as label as Not Accessible,

this will be ignored, as this field is required on system level.

 

Another possibly conflicting situation takes place for required fields. Required option can be set in object class definition. Required field can be hidden from specific user that still has the right to add new objects.

In that case, this user will only have to fill in fields that are required and visible to him. If another user, with less restrictive rights wants to edit that object, this user will have to fill in missing and required fields before he is allowed to save this object

Ideally objects should be created by users that have sufficient rights to fill in all required fields.

 

Â