Working with Record Security
From the Security page, you can perform the following tasks:
This section will describe the second kind of security - record security that can be assigned by an ordinary user and applies only to one single record at a time.
Examples of when you may need to set record security include:
- Public records need to be made accessible to limited-privilege users.
- Public records need to be made inaccessible to specific groups.
- Private records need to be made accessible to specific users or groups other than the user who created the record.
Public records are available to all users, and groups must be added to make the records inaccessible.
Private records must have all users or groups added to its permissions in order to make the record accessible.
More information on Public vs. Private record security can be found here.
The security features described here have no effect on a user whose level of access is "superuser" rather than "normal" or "limited". A superuser can manipulate any record, even if you explicitly deny them access to a record in the record's Security page.
Users who create a record typically have access to it, regardless of the settings on the Security page--provided they have the right to read that record type. Similarly, all project and task assignees and appointment attendees are automatically granted the rights to read, update, and delete the records.
Depending on your organization's security settings, related records of projects may automatically inherit the same security settings as their parent project. For example, if a parent project's security is set so that you cannot delete it, then you may not be able to delete its related appointments, histories, and tasks, even if you are the user who created those related records.
Similarly, while a parent project is pending approval, you may not be able to modify that parent project or any of its related appointments, histories, tasks, and other options, depending on the administrative security settings.
The individual record security feature cannot be used to override the comprehensive security feature. For example, if you explicitly grant View rights for a Contact record to group "reviewers", but "reviewers" does not have View rights for the Contact record type, then that groups's users would still be unable to view that Contact record.
The ability to control security for an individual record is a set of two rights (view security and edit security) that are granted to you by your system administrator. If you do not have these rights, you will not be able to see or use the Security page of a record.
The individual rights that can be assigned on the Security page are:
Record Security Rights
|
Right |
Description |
|---|---|
|
Read |
Allows the users in a group to view or read the record. If a user or group is denied this right, the record will be invisible to them (will not appear in lists or search results.) Important: If you grant any of the other three rights to a user or group, you automatically grant them the right to read the record. See the security rights dependencies diagram. |
|
Update |
Allows the users in a group to edit and change the record. If a group has Read rights to a record, but does not have Update rights, the record will be included in lists and search results, but a small image of a lock |
|
Delete |
Allows the users in a group to delete the record. |
| Perm (Permission) | Allows the users in a group to set the record security through its Security tab to grant or deny access rights to other users. |
Rights are somewhat dependent on each other. For example, if you want to grant a Permission right, to edit the record security, you must also assign the Read and Update rights. If you want to assign the Update right, or the Delete right, you must also assign the Read right. Note that the application will automatically assign the dependent rights when you select a right that has dependencies.
The following diagram illustrates the dependency of the record rights when you want to allow any of them to a user or group. The arrow in the diagram indicates that the right it points FROM requires the right it points TO.
When denying access rights, the dependencies cause slightly different effects. By default, if you deny a group the Read right, the rest of the rights for the record are automatically denied. Also, if you deny a group the Update right, the Permission right is denied. Again, the application automatically sets the other dependent rights when you select an individual right.
Viewing Record Security
While viewing a record, click on the Security link in the left pane.
To view the two Security page sections
- Privacy determines whether the record behaves as public or private. If it is public, the record will be shown or hidden based on the rights that have been assigned to the overall record type. If it is private, the record will be hidden from all users except the user who created it. However, there can be exceptions to those behaviors, and the exceptions are determined by entries in the Group Rights section.
- Group Rights contain exceptions to the public/private behaviors, organized by user group. For example, if a record is private, you could enter an exception that would allow a specific group to edit that record, while all other groups would still be unable to see the record.
|
Field Name |
Description |
|---|---|
|
Option |
Indicates whether this row Allows or Denies specific rights to the record. |
|
Group |
The user group to be affected by these rights. |
|
Read, Update, Delete, Perm |
Four fields, each containing Yes or No, to indicate which rights are being allowed or denied. See a detailed explanation of these rights in Record Security Rights. |
See Working with Record Security for more information.
Editing Record Security
While editing a record, click on the Security link in the left pane.
See Working with Record Security for conceptual information.
To edit the Security page sections
- Privacy determines whether the record behaves as public or private. Click the appropriate option button to make that determination.
- Group Rights contain exceptions to the public/private behaviors, organized by individual users. Enter information as described below.
Field Name
Description
Option
Choose whether to Allow or Deny specific rights to the record.
Group
Select a user group to be affected by these rights.
(check-boxes)
A group of check-boxes determines what kind of rights are being allowed or denied. Click the boxes that should be affected. See a detailed explanation of these rights in Record Security Rights.
Action
Click the minus icon to delete the associated row. Click the plus icon to add a new row of information.
- Click Save.
Public and Private Record Security
Records can be set to either Public or Private security. These settings can be accessed via the Security link on the left side navigation pane of any record.
Public records automatically allow all AllRights users to view the record. Only limited-privilege users need to be added to view the record. Similarly, you must specifically add groups or users with AllRights to "Deny" in order to block these records from those users.
Private records default to only let the record creator view the record. You must specifically add groups or users to Allow and select their Read, Update, and Delete permissions to make this record accessible.