Difference between revisions of "About Roles and Data Visibility"

From AgileApps Support Wiki
imported>Aeric
imported>Aeric
 
(44 intermediate revisions by the same user not shown)
Line 1: Line 1:
__NOINDEX__
<noinclude>__NOINDEX__</noinclude>
:*[[Custom Access Criteria]] are a set of rules which define the [[Users]] who can perform various Actions (add, view, update, delete) on [[Record]]s in [[Objects]]
====Standard Access Controls====
:*[[Visibility Controls]], a security control used to define whether User data is available to other users, whether records in objects are visible or hidden and optionally, whether the User has rights to modify data records based on [[Record Owners|Record Ownership]]
A user's access to data is normally determined by a number of factors, shown here. It is also possible to define custom access criteria, described subsequently.
:*[[Role Based Permission Control|Field Visibility (Role Based Permission Control)]], a security control that provides data visibility rights at the [[Fields|Field]] level
 
:*[[Role Based IP Login Restriction]], a security control that restricts login to users in a limited IP address range
:* The user's [[Access Profile]] specifies global access permissions and administrative permissions.
:*[[Data Sharing Policies]], a set of actions and rules that enable users to share data across [[Teams]], with the level of access based on each [[User]]'s [[Role]] in a primary [[Team]]
 
:* The [[Application Access]] settings determine which applications the user can run. The [[Objects]] available to the user are therefore the combination of
:::a. Objects that are part of the running application
:::b. Objects that are shared from other applications.
 
:* The user's [[Role]] in the application, as specified by the [[Application Access]] settings, specifies high-level access rights to individual application objects.
::* The privileges granted in Access Profiles and Roles are ''additive''. If either the Access Profile or the user's Role grants permission to perform some operation on an object, then the user has that permission.
::* By default, [[Role]] privileges are additive, as well. If a user has been assigned multiple roles in an application, then the user has the sum of the privileges accorded to those roles.
::* If the [[Switch User Roles]] capability is turned on, then the user has the ability to select which role is active, and has the privileges accorded to that role.
 
:* The [[Team]] the user belongs to, and the access to records owned by other team members, as determined by the user's [[Role]].
 
:*[[Record Level Visibility]] can be used to restrict the visibility of individual records to a specified audience.
 
:* [[Team Data Sharing Policies]], which allow data to be shared across Teams. (These settings override the record-level access permissions specified in the individual's Visibility Controls.)
 
:*[[Field_Settings#Field_Visibility|Field Visibility]], when used, specifies data visibility at the [[Fields|Field]] level.
 
:* '''Task-based access''' allows access to records that may not otherwise be visible:
::* Users who own a [[Task]], or whose team owns the task, can view the record the Task is attached to.
::* If the Task has open ownership, the record the Task is attached to can be viewed by anyone, for as long as the Task is unassigned.
::* When a [[Process Task]] specifies that the task is to be closed with an accompanying Form, the user can view and edit record the Task is attached to while they are completing the task.
::* When user lacks permission to view an object, they will be able to view the record in that object by following a link to it (for example, in the task's <tt>Related To</tt> field). They also see the record when completing the task. But there is no tab for viewing other records in that object, and a search will not reveal it.
 
====Role Permissions====
{{:Role Permissions}}
====Custom Access Controls====
[[Custom Access Criteria]] can be defined, as well. Those criteria can evaluate field values and apply functions to return true or false for different kinds of actions that can be taken on a record.
 
For example, records with a salary in excess of a certain amount can be made available to designated roles, only.
<noinclude>
 
[[Category:Data Permissions]]
</noinclude>

Latest revision as of 23:07, 8 September 2015

Standard Access Controls

A user's access to data is normally determined by a number of factors, shown here. It is also possible to define custom access criteria, described subsequently.

  • The user's Access Profile specifies global access permissions and administrative permissions.
  • The Application Access settings determine which applications the user can run. The Objects available to the user are therefore the combination of
a. Objects that are part of the running application
b. Objects that are shared from other applications.
  • The user's Role in the application, as specified by the Application Access settings, specifies high-level access rights to individual application objects.
  • The privileges granted in Access Profiles and Roles are additive. If either the Access Profile or the user's Role grants permission to perform some operation on an object, then the user has that permission.
  • By default, Role privileges are additive, as well. If a user has been assigned multiple roles in an application, then the user has the sum of the privileges accorded to those roles.
  • If the Switch User Roles capability is turned on, then the user has the ability to select which role is active, and has the privileges accorded to that role.
  • The Team the user belongs to, and the access to records owned by other team members, as determined by the user's Role.
  • Team Data Sharing Policies, which allow data to be shared across Teams. (These settings override the record-level access permissions specified in the individual's Visibility Controls.)
  • Task-based access allows access to records that may not otherwise be visible:
  • Users who own a Task, or whose team owns the task, can view the record the Task is attached to.
  • If the Task has open ownership, the record the Task is attached to can be viewed by anyone, for as long as the Task is unassigned.
  • When a Process Task specifies that the task is to be closed with an accompanying Form, the user can view and edit record the Task is attached to while they are completing the task.
  • When user lacks permission to view an object, they will be able to view the record in that object by following a link to it (for example, in the task's Related To field). They also see the record when completing the task. But there is no tab for viewing other records in that object, and a search will not reveal it.

Role Permissions

These are the permissions that can be specified for a role:

Record Access Permissions
For each object, specify the ability to Create, and Delete records.
If Record Level Visibility is enabled for an object, specify the ability to Control Visibility.
(In general, the ability to access an object implies the ability to view any of the records it contains. However, if Record Level Visibility is enabled, a role can also specify the ability to set visibility criteria for individual records, in order to restrict visibility of that record to a designated audience.)
Access to Records Owned by Others Within the Team
Specify the ability to Update, Delete, and View records contained in a each object.
(These permissions apply to records owned by a different member of the team.)

Custom Access Controls

Custom Access Criteria can be defined, as well. Those criteria can evaluate field values and apply functions to return true or false for different kinds of actions that can be taken on a record.

For example, records with a salary in excess of a certain amount can be made available to designated roles, only.