NOTICE: You are in the old ClientSpace Help system. Please link to the new ClientSpace Help here https://extranet.clientspace.net/helpdoc/home/ClientSpace.htm

ClientSpace NEXT Security

Owned by Tony Hayes
Last updated: May 30, 2019 by Diane Hogan (Deactivated)
4 min read

Security Behavior Changes in Next

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" checkbox.

In Next 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 may attempt to assume a user using the classic method of going to System Admin   | User Admin selecting a user and clicking the "Assume User" button. 

Switching to NEXT you would expect the security change to be in effect, but the user security rights are not acting as you would expect.  Switching back to classic causes the security to act as expected.

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

Assuming the user through Admin Settings in NEXT should provide 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, contact your account manager and request they recycle the application pool to process the changes.  

Best Practice

In order 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 of the fields within that field set

ClientSpace Next has been enhanced to allow 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 still respected.

In the above 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.

It is important to note that 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 it's own security cannot be edited.


Best Practice

Draw a diagram of the dataform prior to adding security to it in order to map out how you would like the field access to occur.  This will allow you to envision the different users that will need access to the dataform, and help you to better plan out how to architect the security and associated user roles.


Attachment Security

File security has been standardized to work the same way for non-admins across all entities in the system. Previously the dataform file right Action item menu was wide open, so if you have view rights to the dataform you can add, edit and delete files, but, on orgs, contacts, activities and tasks, you needed at least edit rights to the entity in order to add, edit or delete files.

All entities now work like this:
* First, you must have edit rights for the entity (dataform or otherwise) that you're on in order to do anything but view files.
* If you have edit rights, then you can optionally lock files down using an "_$Attachment" security entity.

  • Dataforms use {TableName}_$Attachment - set by checking the "Attachments Secured" box on Dataform properties
  • Orgs, contacts, activities will use CRM_$Attachment - must be added by a ClientSpace representative - if you would like to utilize CRM attachment security contact your Account manager.
  • Tasks will use Incident_$Attachment - must be added by a ClientSpace representative - if you would like to utilize Task attachment security contact your Account manager.


Article Images:


NOTICE: You are in the old ClientSpace Help system. Please link to the new ClientSpace Help here https://extranet.clientspace.net/helpdoc/home/ClientSpace.htm