ClientSpace security tips

Role security changes do not appear to happen immediately

A common scenario for a Global Admin in ClientSpace is to apply dataform security within the application. For example:

•

You secure a dataform by opening dataform manager, selecting the form, and going to Form Properties to check the Secured option.

•

The system is immediately alerted to this change and the dataform is locked until you add the security entity (gen_DataformName) to a role.

•

After adding the security entity to a role, you can assume a user by going to System Admin > User Admin selecting a user and clicking Assume User.

User security is cached at the server level and reset at login

Assuming the user through Admin Settings provides the same security rights as that user. If you have just made security changes within the application, such as securing a dataform and adding the Security Entity to a role and you are unable to see the expected results, log an Extranet case and request they recycle the application pool to process the changes.

Best practice

To truly assume the same security settings as the user, it is a best practice to have a test user that you can configure with the appropriate security rights, then assume the test user and check security.

Securing a fieldset with View rights affects all the fields within that fieldset

ClientSpace allows hierarchical security, basically any field within a fieldset inherits the security applied to the fieldset (to a point). Individual field security within the fieldset is followed.

•

In the example, Fieldset Test 1 has been secured with Edit rights, none of the fields within the fieldset have their own security so they inherit the security of the fieldset and are also secured with Edit rights.

•

Fieldset Test 2 has been secured with View rights and the luState field within fieldset 2 has also been secured, but with Edit rights applied.

•

Fields within Fieldset 2 inherit the Fieldset security unless they have their own security, so CheckTestToo and DateToo are View only, while luState which has it's own security can be edited.

There must be a minimum of View rights for a field or fieldset to appear on the form. In the following image, security has been flipped:

•

Fieldset Test 1 has been secured with View rights, none of the fields within the fieldset have their own security so they inherit the security of the fieldset and are also secured with View rights.

•

Fieldset Test 2 has been secured with Edit rights and the luState field within Fieldset 2 has also been secured, but with View rights applied.

•

Fields within Fieldset 2 inherit the fieldset security unless they have their own security, so CheckTestToo and DateToo are editable, while luState which has its own security cannot be edited.