|
||
|
|
Overview
Tracker incorporates a security model that allows the administrator to control access to both function (Add, Delete, Edit, etc.) and data.
By using these features the administrator can create different classes of users (via user groups) with different available operations and access to data. For example, a user group could be defined that allows users access to query and view only those records created by other users in their group.
Note that this section is meant to serve as an introduction to basic Tracker security concepts. Detailed information on how to perform specific tasks are covered in the various help subjects where the options are actually set.
Topics Covered In This Section
The Tracker security model is based on the concept of individual users and user groups. Each individual user must log into the system, and each user is a member of one or more user groups. User groups are a convenient way to group similar users together, and define security for those users.
For example, rather than defining specific access privileges for all 50 users at a company, the administrator can split the users in to functional groups (Development, QA, Customers, etc.), define security for the functional groups, and then assign the users to those groups.
All users are members of one of the following system-defined user groups by default:
Users and user groups are covered in detailed in these help topics:
Each user group can be assigned privileges, and each user that is a member of the group inherits that set of privileges. All of the basic Tracker functions like Add, Edit, etc. are defined to be individual privileges that can be assigned to a user group.
For example, to allow a user to Add and View records, create a user group that has both Add and View privileges, and then assign the user to that group.
One special case is the Admin group, which always has Admin function privilege. Other user groups can also be defined to have this privilege, however it cannot be removed from the Admin group. Privileges are covered in detail in the following section:
Tracker allows multiple projects to be created and maintained in a workgroup. Each project can be defined to be visible to only certain user groups. Only users who are members of those user groups with visibility to a project can add or access records that belong to that project. Users cannot login to Tracker unless they are a member of a user group that has visibility to at least one project.
Each Project has one or more Forms (record types). Within each Project, visibility can be independently specified for each Form. So even within a single Project, some user groups may have access to multiple Forms while others will only have access to one Form.
Project and Form Visibility are explained in the following sections:
If you have purchased Restricted user licenses, user accounts with those licenses will automatically have their access limited to those records which they submitted. More specifically, their access is limited based on the setting of the Reporter field within the record. Users with sufficient privilege can set/modify the Reporter field to submit issues on a Restricted user's behalf. All reports which a Restricted user runs are automatically filtered to only display issues which they submitted (or were submitted on their behalf).
User license types are explained in the following section of the Installation Guide:
Tracker supports an optional record visibility model. This means that each individual record is defined to be visible to a set of user groups. The record can be seen by any user who is a member of a group in this set, it is invisible to all other users. This feature can be enabled or disabled via the Record Visibility setting under General Preferences.
Record Visibility should only be enabled by advanced Tracker administrators. In most cases, Project Visibility, Form Visibility, or Restricted User accounts can be used to configure and manage visibility. Record visibility is a record-by-record setting of visibility that is rarely needed. In most cases, it is more difficult to configure and maintain (each record may have different visibility settings) than the other visibility options. It is typically only necessary in situations where you must configure visibility on a case-by-case basis. This might be done by the person who submits the issue or by someone later on in the workflow. For assistance in choosing between the visibility options, contact Technical Support. They can review your requirements and provide suggestions regarding which option (or combination of options) may be best for you.
By default, when a record is created, it is set such that it is visible to:
NetResults Tracker © 1997-2018 NetResults Corporation. All rights reserved.
Need Support? Chat now...
NetResults Tracker Help
