Page Comparison

Security Entities
Entities are the security objects used by the application to check what rights a user has to view, create or modify a system object. Entities are most commonly created by securing a Dataform or dataform field. Securing a dataform creates a Security Entity with the same name as the dataform, for example, if you secure the WhatDo dataform a security entity of gen_WhatDo is created (gen_zWhatDo for a custom dataform). In a similar way, securing a dataform field will generate a security entity for the field of dataformname_fieldname. 

So securing the YouWant field on the WhatDo dataform will create a security entity named gen_WhatDo_YouWant. When a dataform or field is marked as secure, and that entity applied to a role, this item is unavailable in the system unless a user is either a Global Admin or a member of a role with at least View only rights for that security entity. In this way, you can apply very granular security to dataform objects. This security is also hierarchical, meaning if you secure a fieldset on a dataform, all of the fields inside the fieldset are secured by default, effectively hiding them unless the user has at least view rights to the fieldset. Careful application of Security entities and role security can make dataform configuration incredibly robust, allowing the application to have a customized look and feel for different groups of users without having a large number of dataforms. 

Security entities can also be artificially created as part of the development process to secure items that are not generated by the system such as processes or custom objects like dashboards. The CRM entity, for example, is an object which provides a method for securing the Sales prospecting modules of ClientSpace. As with dataform field entities, the CRM_Phone entity controls rights to the Telephone field on the org and so on.

Similarly, business object security can be used to secure specific attributes of the system, such as the biz_clientservicecase_massupdate object that secures the mass update button for the client service case dashboard, or the biz_workflow_cm_accept that provides the user access to the Accept link on the Client Master page. Some extreme examples of artificial security entities are the tblOrganization and tblContact entities. These two entities were created specifically to provide audit rights on the Contact and Organization records. Users in a role with Admin rights to these entities are able to use the audit function on these non-dataform records.

Another example is Incident_AllowTaskMaintenance. Ordinarily, only the Owner or Assigned To user can edit task fields. Adding the Incident_AllowTaskMaintenance entity to a user allows them to edit certain fields on a task even if they are not the Owner or Assigned To user.
 
Adding a dataform entity to a security role allows the administrator to secure dataform records in the following ways:
 

• View: user can view the record (form or field) but is unable to add or manipulate the record.
• Add:* user can add new dataforms of that type, or insert information into a field. Add rights apply anywhere in the system dataforms may be added, whether that is within a multiform list, from a dashboard or from the + symbol on a dataform link.
• Edit:* user can adjust a dataform or field. 
• Admin: user has full rights to a dataform or field, inclusive of all other rights.