Security Rights

Last updated
Save as PDF

TeamConnect includes the following types of security settings:

Record security—The security settings of a record. You handle record security from the Security page in a record.
Functional security—The rights of each user or group account to perform specific operations or functions on TeamConnect objects. Functional security affects all records of a specific object type.

Note: Use the following code to access SecurityService: SecurityService SecurityService = platform.getSecurityService();

Record Security

You can use record security in the API to update record permissions and determine whether a user or group can access a record. The SecurityAccess interface includes all the methods for retrieving and updating permissions for users and groups. To call these methods, use the GroupSecurityAccess and UserSecurityAccess interfaces, which extend SecurityAccess.

Updating the security of a record has two parts:

Creating the security object—Before you can update the security of a record, you must create a security object for the user or group. This security object is specific to the record and the user or group. When you create this security object, you also allow or deny the user or group read access to the record. Create this object with the allowUserAccess(), allowGroupAccess(), denyUserAccess(), or denyGroupAccess() methods in the EnterpriseEntity interface.

Note: A record can only have one security object for each user or group. If you try to create a security object for a user or group that already exists, you receive an error.

Updating security—After you create the security object, you can use the SecurityAccess methods through the UserSecurityAccess and GroupSecurityAccess interfaces to update permissions. If you want to update a security object that already exists, use the getUserSecurityAccessList() or getGroupSecurityAccessList() methods in EnterpriseEntity to retrieve a record's security object from a list.

Allowing Security Access

To allow access to a record, create the security object and give the user or group read access. For example, if you are adding group rights to a record, you use the EnterpriseEntity.allowGroupAccess() method to create a security object and grant read access to the group. After you retrieve the group, you can use methods part of the GroupSecurityAccess interface to update permissions, as shown in the following code sample.

public void allowGroupSecurityAccessObject(Contact record) {
    // Creates a record-level security object which (by default) grants the group read access to the record
    Group group = platform.getGroupService().getGroupForName("test group"); 
    GroupSecurityAccess gsa = record.allowGroupAccess(group);

// To allow more permissions, specify them individually 
gsa.addUpdate().addDelete().addChangeSecurityAccess();
}

If group rights for a record already exist, you cannot use the allowGroupAcess() method to retrieve the security object. If you want to update the group rights of the record, you must retrieve it from the list of records for the group's security objects using the getGroupSecurityAccessList() method.

Denying Security Access

To deny access to a record, create the security object and deny the user or group specific rights.

For example, if you want to deny group access to a record, you must create the security object using the EnterpriseEntity.denyGroupSecurityAccess() method. In addition, when you create the group, you can specify which security permissions you want to deny for the group's access to that record, as shown in the following code sample:

public void denyGroupSecurityAccessObject(Contact record) {
    //Creates a record-level security object which includes the specified permissions
    Group group = platform.getGroupService().getGroupForName("demo group");
    GroupSecurityAccess gsa = record.denyGroupAccess(group, true, true, true, true);
    
// Check if the object contains the delete permission 
if (gsa.isDelete()) {
    record.setNote("Can be deleted by " + group.getDisplayName());
    }
}

Note: Specifying true for the Boolean parameters of the denyGroupAccess() method denies access to a particular right, but specifying false does not allow or deny access.

If you want to update a group's rights after creating the security object, you can use the SecurityAccess methods through the GroupSecurityAccess interface.

Functional Security

Users with similar functions are typically organized into user groups (instances of GroupAccount). The rights assigned to the group reflect the functional security rights of the users in the group. You cannot modify functional rights using the TeamConnect API, only through the user interface. If you want to know if a user has a particular functional right, you can use the following interfaces:

SecurityService — Provides methods that can check a user's rights within TeamConnect.
OperationType — Provides enumerations that include all the rights a user can have.

Some of the SecurityService methods use the OperationType class. For example, the following code checks if a user can create an account:

boolean hasEntityOperationRights = platform.getSecurityService().isEntityOperationEnabled(user, OperationType.CREATE, "ACCT");

In the previous code snippet, the securityService.isEntityOperationEnabled() method checks if the given user, called anyUser, has the necessary rights to create an account object. If the user has the rights, this code returns true.

In addition to a method for checking rights at the object level, SecurityService also includes methods for checking whether a user has rights to categories, tools, and user invoked rules:

isCategoryOperationEnabled() checks rights for categories.
isToolAccessEnabled() checks rights for system or custom tools.
isUserInvokedAccessEnabled() checks rights for user invoked rules.
isEntityOperationEnabled() checks rights for objects.