Controlling visibility to an issue allows you to control who can see an issue in Issuetrak. Many implementations require some sort of ability to control whether a user can see an issue. We can do this by using a combination of Entity Structures (Organizations and Departments), along with Subscribers and user Permissions to allow a user to access an issue.
The Basics
A user's access to an issue is controlled through:
| Access Control | Definition |
|---|---|
| Administrator rights | All administrators are able to view all issues. |
| A role on the issue | Are they assigned to the issue, did they submit the issue, or are they a member of the issue through a Subscribers list? With a direct role in the issue, a user can always view the issue. |
| User permission | Without a role on the issue, a user needs the permission Can view issues submitted by other users to view any additional issues. With this permission, they can view all issues in the site unless bound by entity membership. |
| Entity Membership | Being associated with an entity can limit access to issues. If an entity is restricted to an internal view, then users can only view issues that belong to that entity. |
When put together, these options control any individual user’s access to view issues as well as user lists in Issuetrak. This allows you to control whether a user sees all issues within the site or is locked down to only a specific subset of issues.
Administrator rights
Users designated as administrators within Issuetrak are not impacted by visibility controls and see all the issues and user lists within the site. They cannot be limited. A user is considered an administrator when they have any one of the following:
- Agents with the Sys Admin parameter
- Agents with the Can access and maintain Administration functions permission
- End Users or Agents with the Allowed Read Only access to Administration information permission
Issue Roles
The following roles always grant access to an issue. A user cannot be restricted from seeing an issue they play a role on.
| Role | Definition |
|---|---|
| Enterer | The person logging the issue |
| Submitter | The person with the problem that the issue is for |
| Assignee | The owner of the issue |
| Task Assignee | The owner of part of the issue process/workflow |
Subscribers and Issue Visibility
Subscriptions can also grant access to view an issue. Subscriptions can be set up by Priority, Issue Type, or Subtype, as well as the entities of Organization, Department, and Location.
In order to allow a user to view an issue using an Subscribers list:
Steps:
- Click the gear icon in the upper right > Click Defaults beneath System.
- Check the box next to ”Allow Subscribers to Add Notes to an issue”.
- Click Update.
A confirmation message will appear when this is complete.
When might you want to use Subscribers for visibility?
In Issuetrak there are several different ways to control the issues that a user can access. Most of these controls allow you to configure sweeping access across a site, organization, or department. For most of our customers these controls work just fine. Some customers, however, run into the following two problems in controlling visibility:
-
A user can only belong to one Department or Organization and needs to access some of the issues in another department or organization.
- The visibility controls that come from Organization and Department are not granular enough for some of the site’s users.
Fortunately, granting issue visibility is easily set up in Issuetrak by adding users or groups to Subscribers lists. You can elect to not send emails and, as long as the person stays on the list, the issues remain visible. This doesn’t give users full access to work the issue, but it does allow them to add notes and attachments.
Adding Users to Subscribers
Throughout Issuetrak, there are Subscribers lists available. Organization, Location, Department, Issue Type, Priority, and many other features all have a link to set up specific Subscribers. The link has the title “View/Maintain Subscribers”. Clicking on the link opens the page for you to view everyone currently on the Subscribers.
There’s also an option to add new users or groups to the existing list. Adding a user to any Subscribers list will grant the default events for your site. If you do not want the user to get any notifications, then you will need to edit the user’s selected events for this list. Instructions for editing events on Subscribers Lists are part of the “Issue Notifications” article in Related Articles below.
Once the user has been added and the events adjusted, the user will be granted read-only access to the issues. They will be able to search for the issues, view them in their dashboard and see them in reports.
Example Scenario
As an example, let’s talk about User A. User A is part of an Internal-only organization named “Organization A.” User A has the permission to close and edit issues, as well as “Can view issues submitted by other users.” She can edit and close any of the issues within Organization A.
Now, let’s introduce another organization, “Organization B.” User A needs to view and add notes to the issues in Organization B, but does not need to close or edit them. To extend User A’s visibility, simply add her user account to the Subscribers list for Organization B.
As a member of the Subscribers list, User A can now view and add notes to any of the issues within Organization B.
Entity Membership
Internal versus External Entities
Organizations and Departments each have an optional value of “internal” that can be set. When the entity is marked as “Internal”, then members of that entity are restricted. Regardless of these settings, a user must have the permission Can view issues submitted by other users in order to see anything beyond what they play a role in.
Organizations
For Organizations, members with the permission Can view issues submitted by other users can only view issues submitted under the same organization as they belong to. If the organization is not marked as internal, it is considered “external,” meaning that members can see all the issues and all the users from their own, as well as all other organizations. When organizations are created, they are marked as internal by default. That option can be unchecked when creating or editing the organization's information.
Departments
When the optional Department entity is enabled, you have a choice of how internal views affect your users. The option “Limit to Submitting department” looks at the submitting user's department, and if a user belongs to that department, then the user can view the issue. The option “Limit to Assigned department” looks at the department of the assigned agent or group, and if a user belongs to that department, then they can see that issue. When departments are created, they are external by default, but this can be changed when creating or editing the department information.
User Visibility
The ability to see users in a dropdown list or search is controlled by the same visibility controls. Administrators see all users and can’t be restricted. The rest of the users would only see other users if they have permission to see others’ issues or the ability to assign issues or tasks to others. When they have one of those permissions, if they’re in an internal organization or department, they only see the users within that entity.
Closing Thoughts
There are multiple ways to control the visibility of issues within Issuetrak, and not all of them may be needed on your site. The best results come from using a combination to create a layered structure that meets your company goals. If you have any questions or would like the assistance of our product experts, please do not hesitate to contact us with any questions.
