Administering Security for Entities

Aptify provides several levels of security to protect a system from unauthorized operations. An administrator can control a user's access to an entity down to the field level.

This topic describes the following security features for entities:

• About Entity Level Security
• Granting Entity Permissions to Groups
• Granting Entity Permissions to Users
• Modifying Security Settings for Attachments
• Modifying Security Settings for Wizards
• Modifying Security Settings for In Place Editing
• Managing the Recordset Query Limitation
• Managing Field Level Security Settings
• Managing Field Level Encryption
• Managing Row Set Security

About Entity Level Security

In order to access services within Aptify, users must have permissions granted to the entities that define those services. These permissions determine whether the user can create new records or read, update, and delete existing records. Permissions at the entity level also determine whether users have the ability to merge records within that service, or to view or update data through the use of the Object Viewer.

The Entity Level Permissions are cumulative and least restrictive so a user that is a member of two groups has the privileges of both groups. For example, if a user is a member of one group that has merging privileges for an entity and also is a member of a second group that does not, then the user has merging privileges for the entity. If a user can use the Object Viewer to display entity records, then the user has both merging and Object Viewer privileges for the entity. See Administering User Groups for more information.

You can review an entity's security settings by running one of the security reports available from the Report wizard within an Entities view. The Application service also includes a security report.

Only system administrators should have the ability to modify entity group and user permissions, as incorrectly applied security configurations could result in unauthorized users accessing restricted information.

Each entity needs to have permissions granted for any user or group of users other than the administrator to access the entity in some capacity. 

Important Note Concerning Entity Security

Aptify ships with a default set of permissions for each entity that is considered to be a starting point in the implementation process. Since every client implementation adopts a different security model specific to the user and group structure of each organization, it is important to apply this security model to the standard Aptify system. 

Rather than making assumptions regarding the appropriate security configuration in the installation process, Aptify believes that security should be examined during the implementation process, and entity security settings should be modified as necessary. Note that modifying the security attributes for existing entities does not violate any software warranty.

Contact an Aptify consultant for more information about how to design and implement a security model for your organization.

Granting Entity Permissions to Groups

Follow these steps to set entity permissions for all members of a Group:

1. Open the Entities record.
2. Click the Security tab.
3. Open a new Group Permissions sub-type record from the Group Permissions sub-tab.
4. Select the group from the Group ID list.
5. Select the check box next to an option to provide the group with the specified ability for the entity.
   • Read: Group members can open and read this entity's records.
   • Create: Group members can create new records for this entity.
   • Edit: Group members can modify existing entity records.
   • Delete: Group members can delete entity records.
   • Allow Merging: Group members can merge two or more entity records into one entity record. See Merging Records for information on how to merge records.Info: If you grant the group Allow Merging permissions, the system also automatically grants the group Delete permissions (since a merging operation deletes records).
   • Allow Object Viewer: Group members can view record data using the Object Viewer.
   • In Place Edit: Group members can edit record data for this entity directly within a list view without opening the record's form. See Modifying Security Settings for In Place Editing for details. Note that this option is not available unless the Edit box is checked.
   • Recordset Query Limit: These fields determine the maximum number of records that can appear in an entity view for this group. These settings are only applicable when Recordset Query Limitation is enabled on the entity's Configuration tab. See Enabling Recordset Query Limitation for details.
     
     
6. Click OK to save the Group Permissions record.
7. Repeat steps 3 through 6 to grant entity permissions to additional groups.
   • Alternatively, you can click OK and New in Step 6 to save the current record and open a new Group Permissions record in one step. 
8. Save the Entities record.

Remember to configure the Group Permissions for this entity's Sub-Types, if applicable. Group and User Permissions do not automatically flow down to an entity's sub-types.

Granting Entity Permissions to Users

Administrators can set entity permissions at the User level as well as at the Group level. In general, most of a user's permission set should come from his or her Group membership. However, under some circumstances, you may only want to grant entity access to a specific user.

Keep in mind that a user inherits all of the permissions of the groups to which he or she belongs. This means that if a user's group already provides basic access to the entity, you only need to specify the additional functionality in the user's permissions record.

Follow these steps to set entity permissions for a single user:

1. Open the Entities record.
2. Click the Security tab.
3. Click the User Permissions sub-tab.
4. Open a new User Permissions sub-type record.
5. Specify the user in the User field.
6. Select the check box next to an option to provide the user with the specified ability for the entity.
   • Read: User can open and read this entity's records.
   • Create: User can create new records for this entity.
   • Edit: User can modify existing entity records.
   • Delete: User can delete entity records.
   • Allow Merging: User can merge two or more entity records into one entity record. See Merging Records for information on how to merge records. Note that if you grant the user Allow Merging permissions, the system also automatically grants the user Delete permissions (since a merging operation deletes records).
   • Allow Object Viewer: The user can view record data using the Object Viewer.
   • In Place Edit: The user can edit record data for this entity directly within a list view without opening the record's form. See Modifying Security Settings for In Place Editing for details. Note that this option is not available unless the Edit box is selected.

   • Recordset Query Limit: These fields determine the maximum number of records that can appear in an entity view for this user. These settings are only applicable when Recordset Query Limitation is enabled on the entity's Configuration tab. See Enabling Recordset Query Limitation for details.

     If the user is already a member of a group that provides access to the entity, you only need to enable the advanced permissions for the user in the EntityUserPermissions record. For example, the JSmith user in Figure 5.2 is already a member of the Users group that provides Read, Create, and Edit permissions for this entity. Therefore, to provide merging rights to JSmith, you only need to check the Allow Merging box, since JSmith will inherit Read, Create, and Edit permissions based on his membership in the Users group. 

     If you do not know to which groups the user belongs, assign the user all of the access rights that he or she requires for the entity. A user can have overlapping permissions from User and Group Permissions records.

     
     

7. Click OK to save the User Permissions record.
8. Repeat steps 4 through 7 to grant entity permissions to additional users.
   • Alternatively, you can click OK and New in Step 7 to save the current record and open a new User Permissions record in one step. 
9. Save the Entities record.

Remember to configure the User Permissions for this entity's Sub-Types, if applicable. Group and User Permissions do not automatically flow down to an entity's sub-types.

Modifying Security Settings for Attachments

One of the features of the Aptify framework is the ability to attach files to any top-level record in the system (on the Attachments tab which appears on all top-level forms).

Attachment security in Aptify starts at a global level but can be applied on a per-entity or per-category basis.

At the global level, a user's basic access to create, read, edit, and delete attachments is based on his or her's permissions to the Attachments entity (see About Entity Level Security for information on general entity security). For example, if a user does not have Create access to the Attachments entity, then that user will not be able to add attachments to any record in the system.

Assuming that the user has appropriate access to the Attachments entity, the next layer of security is applied at the entity level. By default, attachment security for a particular entity uses the security settings for that entity. For example, if a user has Delete permissions to the Attachments entity but does not have Delete permissions to the Persons entity, that user will not be able to delete attachments linked to Person's record.

However, an administrator can also define specific security settings for attachments at the entity level that differ from that entity's general security settings. The process for defining attachments security at the entity level is described later in this topic.

Finally, assuming that the user has appropriate access to the Attachments entity and the appropriate attachments security access at the entity level, administrators and users can also apply security at the Attachment Category level. If an Attachment Category is defined with no User or Group Permissions, the attachment permissions for the corresponding entity apply. However, users and administrators can also define specific security settings for an Attachment Category, which can be used to prevent unauthorized users from seeing sensitive documents that are attached to records that the users can otherwise access.

See Working with Attachment Categories for information on defining security for an Attachment Category.

The following steps describe how to modify attachments security at the entity level so that is different from the entity's general security settings:

1. Open the Entities record for the entity whose attachment security you want to modify.
2. Click the Security > Options tab.
3. Select the Use Specific Attachment Permissions option.
   • When this option is cleared, Attachments for that entity use the entity's defined User and Group Permissions (as described About Entity Level Security).
   • When this option is selected, the Group Attachment Permissions and User Attachment Permissions sub-tabs appear under the Security tab.  
     
     
4. Click the Group Attachment Permissions tab or the User Attachment Permissions tab and create an Entity Attachment Permissions record for each group or user that needs to access attachments for the specified entity.
   • For each group and user, select the check box next to the rights you want to grant to that user or group. The options are:
     • Read: User or Group members can see, and open files attached to records in this entity.
     • Create: User or Group members can add new attachments to records in this entity.
     • Edit: User or Group members can modify existing attachments to records in this entity (this includes updating the attachment and renaming it).
     • Delete: User or Group members can delete attachments from records in this entity.
       
       
5. Add Entity Attachment Group and/or User Permission records for each user or group that needs access to attachments for this entity.
6. Save and close the entity.

Modifying Security Settings for Wizards

By default, wizards in Aptify are available to all users who have access to the underlying entity associated with that wizard. However, an administrator can configure both code-based wizards (that is, Entity Actions) and metadata wizards to restrict the set of users who can access them.

To disable a wizard entirely, an administrator can change that wizard's Status to Inactive. This will prevent all users from accessing the wizard.

To restrict the wizard to a sub-set of users, leave the Status as Active, clear the Allow Everyone to Run option, and specify the Groups and/or Users who should have access to the wizard on the Group Permissions and User Permissions tabs.

Note that to restrict access to code-based wizards, you need to modify the security settings at the Entity Actions record. See About the Entity Actions Form for details. To restrict access to Metadata wizards, you need to modify the corresponding Wizards record. See About the Wizards Form for details.

Modifying Security Settings for In Place Editing

Aptify supports the ability to modify record data directly within a view. This is known as In Place Editing. When enabled, a user can edit rows directly in a list view to update record data without having to open the record's form.
In the standard Aptify installation, In Place Editing is enabled for all users for the following services:

• Persons
• Companies
• Products
• Contact Log
• Tasks

See Editing Records in Place for information on how to use this feature.

In Place Editing is a powerful editing tool that may not be suitable for some users since it bypasses form validation (but any system validation at the business object level will still be fully enforced). Therefore, it is disabled by default for all entities and an administrator must enable it on an entity-by-entity basis.

In Place Editing supports both top level entities and sub-type entities. (The In Place Editing option is only available for sub-types when a sub-type is added to a view as a hierarchy.) As with Entity Security settings, In Place Editing security does not flow down from a top-level entity to its sub-types. Also, you can enable In Place Editing for a sub-type even when it is disabled at the top-level entity.

Follow these steps to enable In Place Editing for a particular entity:

These steps describe how to enable In Place Editing at the entity level. If you have enabled Field Level Security, you also need to enable In Place Editing at the field level (otherwise, you cannot edit any fields in the view, even though the In Place Editing icon appears in a list view's toolbar). See Modifying Field Level Security Configurations for instructions.

1. Open an Entities record.
2. Click the Security tab.
3. Click the Options sub-tab.
4. Place a check mark in the Allow In Place Editing check box.
5. Select an In Place Editing Security setting:
   • All Users: All users who have edit permissions for this entity can edit its records directly within a list view.
   • Specified Users/Groups: Only the Groups and Users that have the In Place Edit option selected on the corresponding Group/User Permissions record can use this feature.  
     
     
6. If you selected Specified Users/Groups, enable In Place Editing for the desired Groups and/or Users.
7. Click the Group Permissions tab.
8. Open the record for a Group for which you want to enable this feature and select the In Place Edit option. Note that this option is not available unless the Edit option is selected. Click OK to close the record.
9. Repeat the above step for additional Groups as necessary.  
   
   
10. Click the User Permissions tab.
11. Open the record for a User for whom you want to enable this feature and select the In Place Editing option. Note that this option is not available unless the Edit option is selected. Click OK to close the record.
12. Repeat the above step for additional Users as necessary.
13. Save and close the Entities record.
14. Close and relaunch the Aptify client.
15. Create or open a list view of the entity to confirm that the In Place Editing icon now appears in the view toolbar.
    • See Editing Records in Place for more information.
    • The In Place Editing icon will not appear in the view toolbar until after you have closed and reopened the Aptify Desktop client.

Managing the Recordset Query Limitation

Recordset Query Limitation lets an organization limit the number of records that are available to a user within a list view. This is particularly useful for entities that have a large number of records, such as Persons. If a user opens an "all" view of such a Persons entity, it can require a large amount of time and system memory to run a query that retrieves all records.

This situation is further exacerbated if the user is connecting to Aptify from a shared server using a terminal client, such as with Windows Terminal Server software. In this case, the view query reduces system response time for not only the user who opened the view but also for other concurrent users.

Limiting the number of records in a view prevents users from inadvertently slowing down the system. It also encourages users to create and use targeted views rather than spend time scrolling through all available records.

Note that Recordset Query Limitation does not prevent a user from accessing any particular record; all records are still available to the user. This feature only limits the number of records that can be displayed within a single page of a view.

Recordset Query Limitation applies only to List views; it does not apply to Pivot Table, Pivot Grid, Calendar, or Chart views.

This topic contains the following sub-topics:

• Enabling Recordset Query Limitation
• Disabling Recordset Query Limitation
• About the Recordset Query Limitation Effects
• About the Recordset Query Limitation and Page Size

Enabling Recordset Query Limitation

Recordset Query Limitation is configured on a per-entity basis. For example, if you want to limit the number of records that appear in views of the Form Templates and Database Objects Persons and Companies entities, you need to enable Recordset Query Limitation on both entities.

Enabling Record Query Limitation is a two-step process. First, you enable the feature on the particular entity and then you configure the maximum number of records that can be displayed in a view for each group or user who has access to the entity.

Follow these steps to enable Recordset Query Limitation for a particular entity:

1. Open or create a view of the Entities service that includes the entity you want to -configure.
   • You must be logged in as a user who has System Administrator privileges to make changes to an entity. 
2. Double-click the entity's entry in the view to open the entity's record.
3. Click the Configuration tab.
4. Select the Enable Recordset Query Limitation option.
   
    
5. Click the Security tab.
6. Double-click a group's entry in the list to open its EntityGroupPermissions record.
7. Configure the group's Recordset Query Limitation.
   • To limit the number of records in a view, select the Recordset Query Limited option and enter the maximum number of records to display in a view in the field provided.
   • With the configuration settings shown below, members of the Users group can see a maximum of 20 records in a view.
     
     
   • If you want a group to have access to all entity records within a view, leave the Recordset Query Limited option cleared.
   • With the configuration settings shown below, there is no limit to the number of records that can appear within a view for members of the Administrators group.
     
     
8. Click OK to return to the Entities record.
9. Configure the other groups as necessary.
10. Click the Users sub-tab.
11. Configure the Users' Recordset Query Limitation settings, as necessary.
    • The configuration for Users is the same as the configuration for the Groups. 
12. Click Save and Close to save your changes and close the entity record.

Disabling Recordset Query Limitation

Follow these steps to disable the Recordset Query Limitation for a particular entity:

1. Open or create a view of the Entities service that includes the entity you want to configure.
2. Double-click the entity's entry in the view to open the entity's record.
3. Click the Configuration tab.
4. Clear the Enable Recordset Query Limitation option.
   • This will disable the Recordset Query Limitation feature.
   • You do not need to disable Recordset Query Limit for each Group or User permissions record. However, if you leave the Group and User permissions configured as is, note that these permissions will be automatically reinstated if you enable Recordset Query Limitation again for this entity at a later date.
5. Click Save and Close.

About the Recordset Query Limitation Effects

When Recordset Query Limitation is enabled, the number of records that can appear within a view is limited based on the user's permissions. The following is an overview of how this limitation impacts a user:

• If a user is a member of multiple groups, Aptify uses the Group permission setting that provides the user with the highest limit. Consider the following scenario:
  • An organization sets an entity's Recordset Query Limit to 20 for the Users group.
  • The organization sets an entity's Recordset Query Limit to 50 for the Accounting group.
  • A user who is a member of both the Users and Accounting groups can see up to 50 records in a view of that entity. 
• Even if an administrator has defined Entity User permissions for a specific user, Aptify still uses the permission setting that provides the user with the highest limit. The user's particular permissions do not necessarily take precedence over his/her group permissions. Consider the following scenario:
  • An organization sets an entity's Recordset Query Limit to 20 for the Users group.
  • The organization set an entity's Recordset Query Limit to 10 for a user named John Public who is also a member of the Users group.
  • John Public can see up to 20 records in a view of that entity. 
• If a user creates or opens a view that would normally contain more records than his/her limit, a message box appears to alert the user.
  • For example, if a user is limited to 20 records for the Companies entity, the following message appears each time the user opens or creates a Companies view that would normally contain 20 or more records: 
• After a user clicks OK to close a Query Record Limitation message, the view opens but only displays the number of records specified by the user's limit.
  • Although the view shows a limited number of records, the user still has access to all of the records that would appear in the unrestricted view.
  • A user can use the sorting options to display different records within the same restricted view. For example, sorting the records in descending order and sorting the records in ascending order displays different record sets. Note that if using the sorting buttons directly in the view, the system resorts only the records that are currently displayed. The user must refresh the view first to see a new set of records. 
• A Query Record Limitation message box does not appear if a user creates or opens a view that returns a number of records that is less than the user's limit.
  • For example, if the user's limit is 20 records and he/she opens a view that contains 19 records, no message appears. However, if the user opens a view that contains exactly 20 records, the message appears.

About the Recordset Query Limitation and Page Size

When Recordset Query Limitation is enabled for an entity, the system appends an additional command to a view's SQL query before sending it to the database server. This command limits the maximum number of records returned by the server based on the user's Recordset Query Limit. If the number of records returned matches the user's Recordset Query Limit, a message is displayed to the user informing them that the limit was reached.

List views also support paging. This functionality breaks up a view's results into one or more pages of a specified maximum size. Paging appends the same command to a view's SQL query as Recordset Query Limitation (although in this case, the record limit is the size of the page). However, when using paging, a user can navigate the other pages to review all of the data returned by view.

If you intend to use Paging in conjunction with Recordset Query Limitation, keep in mind the following conditions:

• The Recordset Query Limit is not imposed if the view's Page Size is less than the Recordset Query Limit. However, the Recordset Query Limit continues to apply if the view's Page Size is greater than the Recordset Query Limit.
• Paging and a view's Page Size is controlled on a view-by-view basis, and users can modify these settings as necessary. Recordset Query Limitation is configured on an entity-by-entity basis by an administrator to prevent a user from executing a query that returns an excessive number of rows.

Managing Field Level Security Settings

Users and groups traditionally are given Create, Edit, Read, and Delete permissions to records within Entities in Aptify. If a user is granted Edit permissions, this means that they may edit any field in the record. Granting Read permissions means that users have access to read data contained in any fields in the record. Field Level Security adds another layer of security, allowing administrators to determine who should or should not be able to see or edit specific data points or fields within a record.
Field Level security is implemented at the Entity level, maintained at the Entity Field level, and requires administrative permissions within Aptify for access to the Entities entity and associated sub-entities. With field level security, the ability to read and/or edit specific fields within a record is controlled.

Granting Read permissions within Field Level Security alters how users may use views for the entity. Users granted Read permission to the entity may read any record belonging to that entity. Removing Read permission for one field means that the users may still read any record for that entity, with the exception of that one field. If Field Level Security is configured to remove Read permissions on specific fields, users are not able to view data in those fields either on the records or in a view.

Field level security applies to all users and groups granted Read or Edit permissions to that entity.

This topic contains the following sub-topics:

• Turning On Field Level Security
• Turning Off Field Level Security
• Resetting Field Level Security Configurations
• Modifying Field Level Security Configurations
• About the Field Level Security Effects
• Configuring the Show Access Denied Attributes

Turning On Field Level Security

Before configuring Field Level Security for an entity, the functionality must first be turned on. This is done at the Entities record.

1. Open the desired Entities record and select the Security > Options tab.
   • A Field Level Security section appears on the form. 
     
      
2. Select the Field Level Security option.
   • This displays the Field Level Security dialog, which lists all fields defined for the entity.
   • By default, all users and groups that have Read or Edit permissions at the entity level are given Read and Edit permissions for each field. Also, if Allow In Place Editing is selected for the entity, all users and groups that have In Place Edit permissions at the entity level are given In Place Edit permissions for each field.
   • In the examples shown below, In Place Editing is not enabled for the entity so the Allow In Place Edit check boxes are not selected in the Field Level Security dialog.
     
     
3. Modify the default Read/Edit permissions, as necessary.
   • Use the Select All and Remove All buttons as necessary to change all of the field settings with one button click.
   • If you remove Edit permissions for a field, the system also automatically clears the the corresponding Allow In Place Edit check box (if it is also selected).
   • For example, if you want all users and groups to have Read access only to the OwnerName field as the Field Level Security starting point, clear the corresponding Edit check box.  
      
     
4. Click OK to close the Field Level Security dialog box.
   • A message box displays, informing the user that this will overwrite any existing Field Level Security configuration already in place for the entity. 

5. Click Yes to return to the Entities record. 

    If you enable Field Level Security and use the default selections in the Field Level Security dialog box (that is, all fields have Read and Edit selected), all users who previously had access to the entity will continue to have the same level of access.

    The Field Level Security option provides the means to automatically configure field security at the current starting point, so that it does not have to be set up manually on each Fields record for the entity. Once Field Level Security is activated, changes can be applied as necessary to individual fields.

6. Modify the Field Level Security settings for individual fields, as necessary. See Modifying Field Level Security Configurations for details.

   This is an important step, particularly if you removed Read or Edit access for all users and groups within the global Field Level Security dialog.

7. Save the Entities record.
   • The system updates the appropriate files and creates the necessary Field Level Security records to capture the permission structure at the field level.

Turning Off Field Level Security

If Field Level Security is no longer necessary or desired for an entity, it must be turned off at the Entity level.

1. Open the Entities record and select the Security > Options tab.
2. Clear the Field Level Security option.
3. Save the Entities record.
   • All Field Level Security configuration is removed, and permissions to the record for users and groups default to those set up at the entity level.

Resetting Field Level Security Configurations

Once Field Level Security is turned on for an entity, any additional changes to the security configurations must be done at the Field level. However, the default configuration may be reset for all users and groups with Read, Edit, In Place Edit permissions at the Entity level.

1. Open the Entities record and select the Security > Options tab.
2. Click the Field Level Security Defaults button.
   • This displays the default Field Level Security dialog box, which lists all fields in the entity, and by default grants Read, Edit, and In Place Edit (if applicable) permissions to all groups and users that were granted the same permissions at the entity level. 
3. Modify the default Read/Edit/In Place Edit permissions, as necessary.
   • Any modifications made in this dialog box are applied to all users and groups who have access to the entity, regardless of existing Field Level Security configuration.
   • Use the Select All and Remove All buttons as necessary to change all of the field settings with one button click.
   • If you remove Edit permissions for a field, the system also automatically clears the corresponding Allow In Place Edit check box (if it is also selected).
   • For example, if you want all users and groups to have Read access only to the OwnerName field as the Field Level Security starting point, clear the corresponding Edit check box.
     
     
4. Click OK to close the Field Level Security dialog box.
   • A message box displays, informing the user that this will overwrite any existing Field Level Security configuration already in place for the entity fields. 
5. Click Yes to return to the Entities record.
6. Save the Entities record.

Modifying Field Level Security Configurations

Once Field Level Security has been implemented for the entity, security configuration is transferred from the entity level to the field level for reading and/or editing fields in the entity records based on the selections made in the Field Level Security Defaults dialog.

After you have enabled Field Level Security and have set the defaults, you can configure Read, Edit, and In Place Edit access on a field-by-field basis for each User or Group that has access to the entity.

Follow these steps to configure a field's security settings:

1. Open an Entities record where Field Level Security has been implemented.
2. From the Fields tab, open a Fields record.
3. Select the Security tab.
4. If you want to use In Place Editing in conjunction with Field Level Security, select the Allow In Place Editing option.
   • After selecting this option, select an In Place Edit Security setting:
     • All Users: All users who have edit permissions at the entity level can edit this field directly within a list view.
     • Specified Users/Groups: Only the Groups and Users that have the In Place Edit option selected on the corresponding Group/User Permissions record can edit this field within a list view. 
   • In order to support In Place Editing at the field level, it must also be enabled at the Entity level and the users/groups to whom you grant In Place Editing privileges at the field level must already have In Place Editing privileges at the entity level.
   • The Allow In Place Editing option is not available for virtual fields and other non-updateable field.
   • See Modifying Security Settings for In Place Editing for instructions on how to enable In Place Editing at the entity level.
     
     
5. Select either the Group Permissions or User Permissions sub-tab.
   • These tabs are only available when Field Level Security is enabled at the entity level (on the Entities record's Security tab).
   • These tabs list permissions for all Users and Groups that originally had a User Permissions or Group Permissions record at the entity level.
     
     
6. Open a Group or User record from the appropriate Permissions tab.
7. Configure the group's or user's field permissions.
   • Select the Read option to grant the user/group read access to the field. Clear the option to disable the user/group's access to the field.
   • Select the Edit option to grant the user/group edit access to the field. Clear the option to prevent the user/group from editing this field. Note that this selection is only applicable if Read is selected.
   • Select the Edit In Place field to grant the user/group the ability to edit this field in a list view (using the In Place Editing functionality, see Editing Records in Place for details). Note that this selection is only applicable under the following conditions:
     • The Edit option is also selected on the same Permissions record.
     • The Allow In Place Editing option is selected on the field's Security > Options tab and In Place Edit Security is set to Specified Users/Groups. (If set to All Users, then all users with the appropriate security can use In Place Editing for this field, regardless of this check box's setting.)
     • The user/group has Edit In Place privileges at the entity level. 
   • Enter any Comments regarding the field level security settings in the field provided (optional).
     
     
8. Click OK to close the Permissions record.
9. Click OK to close the Fields record.
10. Configure the field permissions for additional groups or users, as necessary.
11. Save the Entities record.

About the Field Level Security Effects

When Field Level Security is applied to an entity, users accessing records in that entity who are not granted both Read and Edit permissions will see modified views and forms for any records they opened.

• Read Permissions Not Granted
• Edit Permissions Not Granted

Read Permissions Not Granted

If the user is not granted Read permissions to a particular field in an entity, the following restrictions are applied:

Modifications to the View

If the user has been denied Read permission to any fields in an entity, the user can no longer use that field in a view. The restricted fields do not appear in the Fields list when creating new views or updating existing ones.

If a view that contained this field already existed before field level security was applied, the view will fail to load for non-administrative users (system administrators will still see the field in the existing view but not in new views). Note that not all fields may display in this list, depending on how your system administrator has configured the service.

Modifications to the Form

If the user has been denied Read permission to any fields, the behavior of these types of fields on a form, (determined by a system administrator) is one of the following:

• Field is Hidden: The field is hidden on the form when the user opens a record from the entity. Note that fields on the form will not dynamically adjust their position based on the hidden field. It will be up to a form designer to minimize the visual impact of hiding certain fields on forms (such as fields secured by field level security should appear at the bottom so their absence will not be readily noticed).
• Field is Visible with Access Denied: The field displays on the form as usual when the user opens a record from that entity. However, the field is grayed out, and the message Access Denied, followed by the field name, replaces any data in that field.
  
   

All non-restricted fields for that entity appear as normal on the form and can be edited, assuming the user is granted Edit permissions for the fields.

In Aptify, fields in which a user does not have read permissions to are hidden on forms for all services within Aptify. However, an administrator can modify these setting as needed. See Configuring the Show Access Denied Attributes for details.

Edit Permissions Not Granted

If Edit permissions are denied through the use of Field Level Security, the following restrictions are applied.

Modifications to the View

No modifications to the user's ability to use this field in a view are applied. Because the user can still read and access the data in the field, it is available for use in views.

Modifications to the Form

If the user has been denied Edit permissions, the fields and their data appear on the form as read-only for both new and existing records. Users may not enter data into that field on a new record, nor may they update the value of the restricted field.

Configuring the Show Access Denied Attributes

By default, if a user is not granted Read permissions to a particular field in an entity, the field is hidden on the form when a user opens a record from the entity. However, there may be cases when having the field visible is more appropriate (though the user would not have access to read the field). Therefore, Aptify allows an administrator to configure the visibility of these types of fields on the global or per-entity basis.

See About the Row Set Security Effects for more information about the show/hide options.

By default, any fields in which a user does not have read access to are hidden when opening a form in any service in Aptify. This behavior is controlled by the ShowAccessDeniedFieldDefaultValue attribute found on the Configuration > Attributes tab of the Entities entity.

• The possible values for this attribute are 0 (hide no-read fields when user opens any form in any service, the default value) and 1 (display no-read fields with Access Denied message when user opens any form in any service).
• If this attribute does not exist on the Entities entity (or has an invalid value), the value is assumed to be False and all fields within the system that a particular user does not have read permissions to will be hidden when opening records in an effected service.

You can modify this attribute at the global level as necessary based on the system functionality desired. In addition, you can also add the ShowAccessDeniedField attribute to any entity to control the behavior of fields where a user does not have read permissions.

• The possible values for this attribute are 0 (hide no-read fields when user opens a form in the particular service, the default value) and 1 (display no-read fields with Access Denied message when user opens a form in the particular service).
• If the ShowAccessDeniedField attribute exists for an entity, then that behavior specified within the attribute will be used. If an attribute does not exist for an entity (or has an invalid value), the global show/hide behavior setting will be used.

Managing Field Level Encryption

Administrators can encrypt data fields to prevent unauthorized users from accessing sensitive information, such as credit card or social security numbers. Aptify encrypts field data using Microsoft's Cryptographic Services (see About the Field Level Encryption Implementation for more information).

An administrator enables encryption on a per-field basis within a specific entity.

See Granting Access for Credit Card Number Encryption for information on how credit card numbers are encrypted in Aptify by default.

This topic covers the following sub-topics:

• About the Field-Level Encryption Process
• Important Notes Concerning Field Level Encryption
• Enabling Field Level Encryption
• Configuring the Encryption Block Size Attribute
• Configuring the Override Show Decrypted Field in View Attribute
• Changing Security Keys for Field Level Encryption
• Disabling Field Level Encryption
• About the Field Level Encryption Implementation

About the Field-Level Encryption Process

The following steps provide an overview of the encryption process:

1. An administrator configures a Security Key with the appropriate User and/or Group Permissions.
   • The service includes one default key, the Generic Entity Encryption Key. By default, the sa user and members of the Users, Accounting, and Administrators group have access to this key. 
2. An administrator enables encryption for a data field within an entity's record specifying the Security Key to use for encryption and decryption.
   • Aptify encrypts the specified field in all existing records during the save process. 
3. Authorized users enter data into the encrypted field in a record. When the user saves the record, this data is encrypted and then stored in the database.
   • Since data is encrypted within the database itself, unauthorized users cannot bypass the Aptify security measures to gain access to sensitive data using another database tool, such as SQL Server Query Analyzer or Microsoft Access. 
4. In Aptify, users who have access to the appropriate security key can display encrypted fields within a view in a decrypted format so that exported view results can be viewed in plain text when necessary. See the Show Decrypted Field Option for List Views for details. The encrypted data is not available in views or standard reports.

   • If a view contains an encrypted field and encryption option is not enabled, the field's content appears as a hashed value.
     
      
     
     

     The hashed value is the field's contents after the user data has been encrypted using the specified Security Key and the encryption algorithm.

5. The encrypted data is not available to unauthorized users. Also, unauthorized users cannot enter data into fields that have encryption enabled. Aptify disables the field on the form to prevent the unauthorized users from making any changes to the field's value. 
   
    
6. When an authorized user opens a record, the field's contents are decrypted; the user can view or modify the field's contents.

Important Notes Concerning Field Level Encryption

Review the following considerations before enabling encryption for a particular field:

• When you enable encryption for a particular field, Aptify encrypts the field for all existing records in the entity. If the entity has millions of records, it may take an hour or more to complete the encryption process (depending on the processing power of your server). Also, no transactional activity should take place during the encryption operation to avoid potential conflicts. Therefore, Aptify strongly recommends that you only perform encryption and decryption operations after hours when no one is using the system.
• The encryption process expands data. Therefore, you may need to increase the SQL Data Size within the entity to accommodate the encrypted data.
• If in doubt, perform a test prior to deployment by enabling encryption on a test entity and then attempting to save a record with data of the expected length in an encrypted field. An error message will appear in the Session Exceptions viewer that reports the number of characters needed in the encrypted field, as shown in the example below. If data already exists in the field when you attempt to encrypt it and the field size is too small, the entity save will fail and a corresponding error is logged to the Session Exceptions viewer.
  
  
• Consider the potential consequences of encrypting a field, such as how this change may impact other fields and entities, before enabling this feature. For example, encrypting the Persons entity's First Name will create a meaningless NameWCompany composite field. Therefore, to minimize unintended side effects, encrypt only those fields that require encryption per the organization's security policy.
• Standard reports run from the Report wizard do not decrypt encrypted fields. Therefore, encrypted text will appear as a string of meaningless characters in reports that include an encrypted field.
• Base Fields do not support encryption. Encryption is enabled on a per-field basis within specific entities.

Enabling Field Level Encryption

Follow these steps to enable encryption for a particular data field:

1. Open or create a view of the Security Keys service.
   • The Security Keys service is located within the Aptify Framework Administration application.
   • You must have the appropriate permissions to access this service.
   • The service includes one default key, the Generic Entity Encryption Key. By default, the sa user and members of the Users, Accounting, and Administrators group have access to this key. 
2. Do one of the following:
   • Right-click the Security Keys entity and select New Security Key Record from the drop-down menu. Proceed to Step 3.
   • Use the default Generic Entity security key. Open the security record and proceed to Step 4. 
3. Configure the Security Key's General tab.
4. Enter a name for the key in the Name field.
5. Enter an optional description.

6. Enter between 1 and 50 alphanumeric characters in the Key Value field. Using a large number of characters will make it more difficult for an unauthorized individual to decrypt the data.

   By default, only the sa user has the ability to delete a security key. 

   
    

7. Configure the User and/or Group permissions.
   • Click the Group Permissions tab and add Groups, as necessary. The members of the selected Groups can encrypt and decrypt fields that use this key. You should add any user group whose members will need to enter or read values in the encrypted field.
   • Click the User Permissions tab and add Users, as necessary. Each selected user can encrypt and decrypt fields that use this key.
   • Note that a Security Key record will not show up in a user's view of the Security Keys service unless the user has User Permissions or Group Permissions for that specified key. In other words, be sure to add an Administrator group on the Group Permissions tab or the administrative user on the User Permissions tab if you plan to manage the security keys from an administrator account other than the sa user. 
8. Save and close the record.
   • Note that you cannot change the Key Value for a Security Key once the key has been saved. If you want to change the key that encrypts a field, see Changing Security Keys for Field Level Encryption for details. 
9. Configure the Encryption Block Size attribute for the entity that you want to encrypt, if necessary.
   • The Encryption Block Size attribute determines how many records are processed in each block during the encryption process for the specified entity.
   • By default, the Block Size is 1000 records.
   • See Configuring the Encryption Block Size Attribute for details and configuration instructions. 
10. Within the Entities service, open the entity that contains the field you want to encrypt.
    • The Entities service is located within the Aptify Framework Administration application.
    • For example, if you want to encrypt the Credit Card Acct # field on the Orders form, open the Orders entity. 
11. Under the Fields tab, double-click the field that you want to encrypt to open the Fields record.
12. Click the Security tab.
13. Select the Encrypt Data option.
14. Enter the key you want to use for encryption in the Security Key field.
    • Click the blue link to create a new key. See Steps 3-5, above, for more information on creating a key.
      
       
15. Click the General tab and increase the SQL Field Size, if necessary.
    • The encryption process expands data. Therefore, you may need to increase the SQL Data Size within the entity to accommodate the encrypted data. See Important Notes Concerning Field Level Encryption for more information. 
16. Click OK to save changes and close the Fields record.
17. Save and close the entity record.

Aptify will encrypt the specified field in all existing records. This process may take some time depending on the number of records. To minimize potential conflict with users who are entering data into the system, Aptify recommends that you only perform encryption operations after hours when no one is using the system.

Configuring the Encryption Block Size Attribute

The Aptify encryption mechanism processes entity records in blocks. Each block contains a sub-set of the total number of records in the entity. The Encryption Block Size attribute specifies the number of records in a block.
For example, if an entity contains 100 records and the Block Size is set to 10, the encryption mechanism would process records 1-10 as one block, records 11-20 as a second block, and so on.

By default, Aptify uses a block size of 1000 for all entities. If an entity contains less than 1000 records, the encryption mechanism will process all of the entity's records in one block.

The ideal block size varies from organization to organization, but, in general, it should balance the following factors:

• Speed: Using larger blocks will decrease the time it takes to encrypt a field in all records.
• Processing Power: Using a block that is too large may require more memory than the server has available. For example, processing 10 million records in one block will most likely exceed the processing capabilities of a typical database server.
• Status Updates: The encryption mechanism updates the Entity Save status window after it processes each block. Using smaller blocks provides more frequent status updates.
• Error Reporting: The encryption mechanism reports the status of a block and not the status of an individual record. If an error occurs during encryption, using smaller blocks makes it easier to identify which record caused the problem.

Follow these steps to configure the Encryption Block Size attribute for an entity:

1. Open the entity from the Entities service.
2. Click the Configuration tab.
3. Click the Attributes sub-tab.
4. Open a new Entity Attributes sub-type record.
   • Click the New Record... button, or right-click in the gray area and select New from the pop-up menu. 
5. Enter Encryption Block Size in the Name field.
6. Enter the size of the block in the Value field.
   • Use a value of 1 or greater (integers only). Aptify uses the default block size of 1000 if the attribute's value is set to 0.
     
     
7. Enter an optional description, if desired.
8. Click OK to close the Entity Attributes record.
9. Click Save and Close to save the change and close the Entity record.
10. Close and reopen Aptify for the change to take effect.

Aptify uses a default Encryption Block Size of 1000 if an Encryption Block Size attribute record does not exist for a particular entity.

Configuring the Override Show Decrypted Field in View Attribute

Users who have access to the appropriate security key can display encrypted fields within a view in a decrypted format so that exported view results can be viewed in plain text when necessary (See Show Decrypted Field Option for List Views for details). However, there are several cases where this behavior may not be desirable and a possible security risk. In these cases, an administrator can add the ShowDecryptedFieldOverrides attribute to change the default show/hide behavior of encrypted fields within an entity.

• Note that it is not necessary to add the ShowDecryptedFieldOverrides unless you are changing the default behavior of an encrypted field. Default behavior is as follows:
• Fields of Extended Type Password and credit card number fields (CCAccountNumber) are disabled by default.
• All other encrypted fields are enabled by default.

Follow these steps to configure the Override Show Decrypt Fields attribute for an entity:

1. Open the entity from the Entities service.
2. Click the Configuration tab.
3. Click the Attributes sub-tab.
4. Open a new Entity Attributes sub-type record.
   • Click the New Record... button, or right-click in the gray area and select New from the pop-up menu. 
5. Enter ShowDecryptedFieldOverrides in the Name field.
6. Enter the field and the appropriate behavior in the Value field as follows:
   • EncryptedField(Show): Enter the name of the Encrypted field and Show in paratheses if you want to enable the Show Decrypted option for this field within a view.
   • EncryptedField(Hide): Enter the name of the Encrypted field and Hide in paratheses if you want to disable the Show Decrypted option for this field within a view. 
7. Using a pipe-delimited list, add additional fields and the appropriate show/hide behavior as necessary.
   
    

Changing Security Keys for Field Level Encryption

Follow these steps if you want to change the Security Key that Aptify uses to encrypt a specific entity field:

1. Create a new Security Key from the Security Key service.
   • See Steps 1 to 5 in Enabling Field Level Encryption if you need instructions on how to create a Security Key. 
2. Open the entity that contains the encrypted field whose key you want to change from the Entities service.
3. Under the Fields tab, double-click the name of the encrypted field to open the Fields record.
4. Click the Options tab.
5. Enter the new key in the Security Key field.
6. Click OK to save changes and close the Fields record.
7. Save and Close the entity record.

Changing the Security Key is actually a two-step process. First, Aptify decrypts the data using the old key, and then it re-encrypts the data with the new key. This process affects all records in the entity and may take some time depending on the number of records. To minimize potential conflict with users who are entering data into the system, Aptify recommends that you only perform encryption and decryption operations after hours when no one is using the system.

Disabling Field Level Encryption

Follow these steps to disable field level encryption:

1. Within the Entities service, open the entity that contains the field that has encryption enabled.
2. Under the Fields tab, double-click the field for which you want to disable encryption to open the Fields record.
3. Click the Options tab.
4. Clear the Encrypt Data option.
5. Click OK to save changes and close the fields record.
6. Save and Close the entity record.

Aptify will decrypt the specified field in all existing records. This process may take some time depending on the number of records. To minimize potential conflicts with users who are entering data into the system, Aptify recommends that you only perform encryption and decryption operations after hours when no one is using the system.

About the Field Level Encryption Implementation

Aptify uses the Cryptographic Services included with Microsoft .NET Framework 2.0 to encrypt and decrypt data files. The AptifySecurityKey assembly implements the Rijndael symmetric encryption algorithm by default, but also supports the Data Encryption Standard (DES) algorithm for backwards compatibility (version 3.5 used a DES implementation).

See http://msdn2.microsoft.com/en-us/library/93bskf9z.aspx for information on the .NET Framework's cryptography model.

Managing Row Set Security

In addition to Entity Security, Field Level Security, and Field Level Encryption, administrators can also prevent users from accessing specific data records within a service or entity. This is known as Row Set Security (since each record is considered a row within the database).

For example, an administrator can define a rule within an entity so that a user can only see the records that he/she created. For example, an organization can configure the Persons entity to allow a user to see only those records for which the user is the Main Account Manager. This rule would prevent users from accessing Person records managed by other employees.

Aptify implements Row Set Security by specifying a rule that filters out records from an entity's base view. The administrator enters the rule into the Entities record in the form of a SQL WHERE clause. Aptify appends the WHERE clause to the end of the Base View command.

Caution

Implementing Row Set Security may have a negative impact on system performance. Aptify recommends that only administrators who are familiar with SQL should use this feature. For best results, use the minimum number of Row Set Security statements required by your organization. Also, review the Aptify Performance Tuning white paper for suggestions on how to improve overall system performance (the white paper is available from Aptify Support). 

This section covers the following topics:

• Enabling Row Set Security
• Sample SQL Where Clauses
• Determining Whether a Base View is Generated
• Disabling Row Set Security
• About the Row Set Security Effects

Enabling Row Set Security

Follow these steps to enable Row Set Security for a particular entity:

1. Open or create a view of the Entities service that includes the entity you want to configure.
2. Double-click the entity's entry in the view to open the entity's record.
3. Confirm that the entity's base view is automatically generated by Aptify.
   • Row Set Security applies only to entities whose base view is generated automatically by Aptify. For entities that have a non-generated base view, the system administrator must apply the row set security logic manually. See Determining Whether a Base View is Generated for information on how to identify generated and non-generated base views.
   • You should review the base view to determine the proper syntax for your WHERE clause. For example, if the entity's table is aliased in the base view, your WHERE clause field also needs to be aliased. See Example 4: Limiting Access to Person Records and Company Records to the Main Account Manager for a WHERE clause that needs to include an alias. 
4. Click the Row Set Security tab.
5. Open a new Row Set Security sub-type record.
   • Either click the New Record... button in the menu bar, or right-click in the gray area and select New from pop-up menu to open a new record. 
6. Enter the rule in the Base View Where Clause field.
   • Row Set Security rules must use proper SQL syntax. Therefore, only administrators who are familiar with SQL should use this feature.
   • See Sample SQL Where Clauses for examples.
7. Enter a description for the rule.  
   
   
8. Click OK to save the rule.
9. Enter additional rules for the same entity, if necessary. Aptify uses an AND operator to separate multiple Base View Where Clauses within a generated base view.
   
   • Alternatively, you can Click OK and New in Step 8 to save the current and open a new Row Set Security record in one step. 
10. Save and close the Entities record.
11. Regenerate the base view for any related entities that join to the entity for which you just enabled row set security.
    • By default, when generating a base view for an entity, the system automatically references the base table rather than the base view for joined entities whenever possible for optimization purposes. However, when an entity's base view references a joined entity that Row Set Security enabled, then the entity's base view joins to the related entity's base view and not its base table (to ensure that row set security restrictions are respected across entities). Therefore, after enabling Row Set Security for one entity, you need to regenerate the base view for any related entities that joins to it to ensure that the base views are properly updated.
    • For example, an organization has defined row set security for the Persons entity so users can only see persons assigned to their particular organization. However, the base view for the Certifications entity in the Education Management add-on application references the Persons entity's base table rather than its base view for optimization purposes by default. Therefore, after enabling Row Set Security for the Persons entity, you need to regenerate the Certifications entity, so its base view references the vwPersons base view rather than the Person base table. 
12. Create views of the entity from multiple users to confirm that the Row Set Security logic operates as expected.

Sample SQL Where Clauses

The Base View Where Clause must use proper SQL syntax. Therefore, only administrators who are familiar with SQL should use this feature. This section provides four examples of Row Set Security.

Important Note

The following examples are for illustration purposes only; they demonstrate how Row Set Security modifies an entity's Base View. These examples are may not be suitable for real-world implementation. Also, note that complex Row Set Security statements may have a negative impact on system performance. 

Example 1: Display Records Created in the Last 30 Days

An administrator has created an entity for an organization that includes a DateCreated field (using the DateCreated base field). The organization's policy is that users should only have access to the records in this entity that were created in the last 30 days.

To satisfy this requirement, the administrator enters the following statement in the Base View Where Clause field for the entity:

DateCreated > GETDATE()-30  

[Where GETDATE() retrieves the current date and time]

Then, the administrator clicks a Save button, and Aptify regenerates the entity's base view so that it takes the following form:

CREATE VIEW vwSampleServices

AS

SELECT

ss.*

FROM

SampleService ss WHERE (-DateCreated > GETDATE()-30) 

As a result of this change, all users will be unable to access any record in this entity that was created more than 30 days in the past.

Example 2: Limit Access to Only Records Created by the Current User

An administrator has created an entity for an organization that includes a WhoCreated field (using the WhoCreated base field). The organization's policy is that each user should only have access to the records in this entity that he/she created.

To satisfy this requirement, the administrator enters the following statement in the Base View Where Clause field for the entity:

WhoCreated = SUSER_SNAME())

[Where SUSER_SNAME() retrieves the name of the current user]

Then, the administrator clicks a Save button, and Aptify regenerates the entity's base view so that it takes the following form:

CREATE VIEW vwSampleServices

AS

SELECT

ss.*

FROM SampleService ss WHERE (WhoCreated = SUSER_SNAME())

As a result of this change, each user can only access the records in this entity that he/she created.

Example 3: Limit Access to Only Records Created by the Current User But -Provide Administrators with Access to All Records

An administrator has created an entity for an organization that includes a WhoCreated field (using the WhoCreated base field). The organization's policy is that each user should only have access to the records in this entity that he/she created.

Also, members of the Administrators group should be able to view all records in the entity.

To satisfy this requirement, the administrator enters the statement below in the Base View Where Clause field for the entity. Note that this scenario is very similar to Example 2 and uses the same Where Clause Base View as in Example 2 but includes a new "OR" statement to support administrator access:

WhoCreated = SUSER_SNAME()

OR SUSER_SNAME() IN

(SELECT u.UserID FROM APTIFY.dbo.vwUsers u

INNER JOIN APTIFY.dbo.vwGroupMembers gm ON gm.UserID=u.ID

INNER JOIN APTIFY.dbo.vwGroups g ON g.ID=gm.GroupID

WHERE g.Name = 'Administrators' )

[Where SUSER_SNAME() retrieves the name of the current user]

Then, the administrator clicks a Save button, and Aptify regenerates the entity's base view so that it takes the following form:

CREATE VIEW vwSampleServices

AS

SELECT

ss.*

FROM

SampleService ss WHERE (WhoCreated = SUSER_SNAME()

OR SUSER_SNAME() IN

(SELECT u.UserID FROM APTIFY.dbo.vwUsers u

INNER JOIN APTIFY.dbo.vwGroupMembers gm ON gm.UserID=u.ID

INNER JOIN APTIFY.dbo.vwGroups g ON g.ID=gm.GroupID

WHERE g.Name = 'Administrators' ))

As a result of this change, each user can only access the records in this entity that he/she created, and members of the Administrators group can access all records in the entity.

Example 4: Limiting Access to Person Records and Company Records to the Main Account Manager

Important Note

The following example is for illustration purposes only; it demonstrates how to create complimentary Row Set Security rules for two entities. This example may not be suitable for real-world implementation since no user will have access to all Persons or Companies records.  

An organization's policy is that users should only have access to the Companies and associated Persons for which they are the Main Account Manager. This type of scenario requires the addition of Row Set Security logic to two entities: Companies and Persons. Note that Companies and Persons have separate Main Account Manager fields.

This example uses the Companies entity's Main Account Manager value; it assumes that users should only see the Persons that are associated with the Companies for which the user is the Main Account Manager.

To fulfill these requirements, the administrator enters the following statement in the Base View Where Clause field for the Companies entity:

c2.MainAccountManagerID IN

(SELECT MainAccountManagerID FROM APTIFY.dbo.Company c

INNER JOIN APTIFY.dbo.Employee e ON -e.ID=c.MainAccountManagerID

INNER JOIN APTIFY.dbo.vwUserEntityRelations uer ON e.ID=uer.EntityRecordID

INNER JOIN APTIFY.dbo.vwUsers u ON u.ID=uer.UserID

WHERE u.UserID=SUSER_SNAME() AND

-uer.EntityID_Name='Employees' )

This clause specifies that the base view contain the Companies records for which the current user is the Main Account Manager.

Note that the c2 alias preceding MainAccountManagerID in the first line is required because the base view aliases the Company table. Therefore, you should always review the entity's Base View prior to saving a Row Set Security record to ensure that your WHERE clause matches the syntax of the base view to which it will be appended

The administrator then enters the following statement as a Row Set Security Base View Where Clause field for the Persons entity:

p.CompanyID IN

(SELECT CompanyID FROM APTIFY.dbo.Person p

INNER JOIN APTIFY.dbo.Company c ON p.CompanyID=c.ID

INNER JOIN APTIFY.dbo.Employee e ON -e.ID=c.MainAccountManagerID

INNER JOIN APTIFY.dbo.vwUserEntityRelations uer ON e.ID=uer.EntityRecordID

INNER JOIN APTIFY.dbo.vwUsers u ON u.ID=uer.UserID

WHERE u.UserID=SUSER_SNAME() AND -uer.EntityID_Name='Employees' )

This clause specifies that the base view return only the Persons records for which the current user is the Main Account Manager for the Person's specified company. Note that the Persons base view aliases the Person table so the p.CompanyID in the first line is also aliased.

Note that this rule requires that each user be linked to an Employee record (specified in Step 7 of the User Administration Wizard). Also, to prevent users from creating Person records without specifying a Company, an administrator should make Company a required field within the Persons entity. Likewise, to prevent users from creating Company records without specifying a Main Account Manager, an administrator should make Main Account Manager a required field within the Companies entity.

Determining Whether a Base View is Generated

The Row Set Security configuration option applies only to entities whose base view is generated automatically by Aptify. For entities that have a non-generated view, the system administrator can add row set security logic by manually appending a WHERE clause to the end of the entity's Base View.

Entities that use generated base views include:

• Persons
• Companies
• Employees
• Orders
• Payments

Follow these steps to determine whether or not an entity uses a generated base view:

1. Open or create a view of the Entities service that includes the entity whose settings you want to review.
2. Double-click the entity's entry in the view to open the entity's record.
3. Click the Base View link to open the entity's Base View record.
   
   
4. Locate the DB field.
   • If the base view is automatically generated, SQL is Generated appears to the right of the DB field.
   • If the base view is non-generated, SQL is Generated does not appear to the right of the DB field.
     
     

Disabling Row Set Security

Follow these steps to disable Row Set Security for a particular entity:

1. Open or create a view of the Entities service that includes the entity you want to configure.
2. Double-click the entity's entry in the view to open the entity's record.
3. Click the Row Set Security tab.
4. Right-click the rule you want to remove and select Delete from the drop-down menu.
5. Click Save and Close.

About the Row Set Security Effects

Row Set Security modifies an entity's base view within the SQL database. Therefore, the following results occur when the feature is enabled for a particular entity:

• Users can only view the Entity records defined by the rule.
• Users can only search the Entity records defined by the rule.
• Advanced users cannot bypass the Aptify security measures to gain access to restricted records using another database tool, such as SQL Server Query Analyzer or Microsoft Access.