Request Tracker Admin Guide

Yüklə 106,16 Kb.
ölçüsü106,16 Kb.

Request Tracker

Queue Administrator Guide

Developed by Kenn Crocker

January 2007

Table of Contents

  1. Introduction 1

  2. System Administration Requests 2

    1. Request a New Queue 2

    2. Request a New Group 4

    3. Request a New Custom Field 6

    4. Set-up Notifications using Scrips and Templates 7

    5. Request Assistance for Technical Issues 7

  3. Queue Administration 8

    1. Add an Existing User to a Group 8

    2. Configure Group Rights and Privileges 10

    3. Sample Instructions to Set-up Rights Access for a Queue 10

    4. Apply a Custom Field to a Queue 16

    5. Project Management ………………………………..……………………………………… 22

  4. Appendix A: List of All Rights in RT 23

    1. Current Global settings ……………………………………………………………………. 25

    2. Recommended Queue settings …………………………………………………………….. 26

  5. Appendix B: Glossary of Terms …………………………………………………………………. 27

  1. Introduction

Request Tracker (RT) is a request tracking software system used in the Institutional Systems Department (IS) to allow the technical staff and project users the ability to enter and monitor work requests for various projects. This document will cover the roles and responsibilities of administering RT in IS and specifics on the responsibilities of being a Queue Administrator. For information on how to use the RT system, refer to the Request Tracker User Guide located at: (YOUR ONLINE SUPPORT SITE HERE).

There are two types of RT Administrators: System Administrator and Queue Administrator.

  1. System Administrators are responsible for the administration of the RT software in the IS department. Their responsibilities include overall system configuration, queue creation/configuration, group creation, custom field creation/modifications, scrip creation/modifications, and RT technical issue resolutions. The Technical Services group is responsible for RT System Administration.

  1. Queue Administrators (also called Queue Managers) are responsible for user administration; ie. adding members to a pre-defined group and granting privileges for said groups to their RT Queue(s). All queues have a Queue Administrator assigned. Queue Administrators are also the first line of support for their queue. All users of a particular queue should go to the Queue Administrator for assistance and, if needed, the Queue Administrator can contact the RT System Administrator(s) for assistance.

While RT System Administration will provide general RT training and documentation, Queue Administrators/Managers are responsible for conveying any queue-specific standards and rules to the users of their queues.

This document was written to provide Queue Administrators instructions and guidelines for managing their respective RT queues.

For an explanation of commonly used RT definitions and terms, please refer to Glossary of Terms document (Appendix B).

  1. System Administration Requests

Queue Administrators should contact an RT System Administrator to:

  1. Request a New Queue

A queue is the central administrative domain of RT; it keeps requests (tickets) organized. Requests are assigned/sent to queues. Technical Services requires that a queue name must reflect the request category, such as IS application software or service area. For example GL (IS application software) or EHS-Laser (EHS-Xxxxxx indicates a service area with multiple applications). Technical Services retains the right to modify/approve the name of any queue.

Once a queue is created it can never be deleted from the RT system. If a queue is no longer needed, Technical Services will disable it (the data must be retained for audit purposes).
Each queue shall have at least one administrator/manager called the “Queue Administrator” or “Queue Manager”. This person is responsible for the overall management of the queue (ie. the responsibility to determine which group(s) can access the queue and what rights each group should be granted for use of that queue). Technical Services will set-up the “Queue Administrator” as an AdminCc role for that queue in RT.
Once a queue is established, then rights to use that queue need to be set-up. Rights (referred to as privileges within RT) are the abilities given to a role or group of users to do something in RT, either on a global and/or queue basis only. The variety of rights within RT allows for a great deal of flexibility in granting access to a queue. The main point to keep in mind is “who needs access” to the queue and “what level of access” should that be.
Administration of the rights to a queue is navigated through the Configuration area in the top (blue) navigation bar of any page in RT.

To request a new queue, please provide Technical Services with the following information.

  • Name of Queue

Your queue name can contain letters, numbers, the underscore character, and dashes. (No spaces, slashes, single or double quotes are allowed). Most queue names reflect a project acronym (i.e. AP, GL, BAR). If not an acronym, then just the first letter is capitalized (ie. Travel, Purchasing).

Here are a few example of existing queue names:

Pick a name that reflects your project, service or organization. If you need to organize or separate tickets, you may need more than one queue. Technical Services will help you make this decision.

If you are considering a long name, keep in mind that the email address for your queue will contain the queue name. A short but descriptive queue name is best.

Finally, many RT users will have access to multiple queues. Avoid names that may be easily confused with other queue names or groups.

A list of existing queue names can be found at the RT Support website.

  • Name(s) of Queue Administrator(s)

Each queue must have at least one Queue Administrator/Manager (see page 1 definition).

  • Name(s) of Technical Support Personnel

Each person in the application group that might work on a ticket in the queue.

  • Name(s) of Business Users/Analysts Personnel

Each person from the department (that owns the process) that might have a request.

  • Name(s) of New Custom Field Requirements

Any information needed in a ticket not provided by basic ticket information or by an existing Custom Field.

  1. Request the Creation of a New Group

It is strongly recommended that rights and privileges be configured at the group (set of users) level rather than at the individual user level. Groups are easier to administer and allow queue managers the advantage of providing their technical staff (as a whole) with rights that are different from those the user group needs or the business analysts group.

For example, a technical group would normally have the right to own or resolve a ticket but a user group should not have this right.

There are four (4) types of groups defined within the RT system, but at LBNL we only use the first three (3):

System group

Used by RT to keep track of certain user attributes with a system-wide (Global) meta group. These pre-defined groups of users are defined as Everyone, Privileged, and Unprivileged. There are only Privileged users at LBNL.


A pseudo-group related to a ticket on a global and/or queue basis. This type of grouping is pre-defined by RT and intrinsic to various responsibilities or mechanisms within the system, ie: to differentiate treatment/abilities as a Role as opposed to members of a group. You might want ALL members of a group to be able to create a request ticket, but only the Requestor getting E_mail about the ticket they created. Another example would be you want ALL members of the technical support group to be able to OWN a ticket, but you only want the Owner of a single ticket to be able to modify certain information about that ticket.

User defined group

A group (created by request) to organize users for access with similar functions and/or responsibilities, ie:
- technical support personnel for a software application

- business analyst personnel that work with the business department that owns the process that the software supports

- business process personnel that use the software and might have needs and/or requests for new work.

Personal group

Groups defined by individual users for their own personal use.
(These groups are not being used or supported in IS)

To request the creation of a user-defined group, please provide Technical Services with the following information:

  • Name of the purposed group

Example of a group name:

TSG-TES-Support-Team (developers that own/work on requests),

EHS-Laser-Users (users allowed to create requests for this queue).

Travel-Technical-Support (developers that own/work on requests).

  • Brief description of the group, purpose and/or function

Descriptive sentence to identify the group and/or function.

  • What users you want added to the group *

List of user names to be members of this group.

  • What rights you want this group to have in the queue*

Example 1: I want these users to be able to create requests, see the queue and reply to tickets. Typically, these people are the users of your application or function. You do not normally want them to own or modify tickets.
Suggested list of rights to grant:

  • SeeQueue (already provided for requestors on a global basis). This will allow other members in a group to see the queue in a drop-down box when creating tickets).

  • CreateTicket reserved for User-defined groups that Queue Admin wants to have this right.

  • ShowTicket (already provided for requestors on a global basis). This will allow other members in a group to see all tickets in the queue.

  • ReplyToTicket (already provided for requestors on a global basis). This will allow other members in a group to reply to any E_mail sent out on all tickets in the queue.

Example 2: I want my project developers/technical support to be able to take ownership of the request, take a ticket from another developer (steal), modify any ticket, reply and comment to any ticket (in the queue), and add other watchers.
Suggested list of rights to grant

  • SeeQueue

  • CreateTicket

  • ShowOutgoingEmail

  • ShowTicket

  • ReplyToTicket

  • ModifyTicket (already provided for owners on a global basis). This will allow other members in a group to modify all tickets in the queue even if they did not OWN the ticket.

  • OwnTicket

  • TakeTicket

  • StealTicket

  • CommentOnTicket

  • ShowTicketComments

  • Watch

*This is the responsibility of the Queue Administrator but Technical Services will do this during initial set-up on request.

  1. Request a Custom Field

To request the creation of a custom field for tickets in a queue, please provide Technical Services with the following information:

    1. Desired name for Custom Field.

    2. Description of purpose or use of the new field.

    3. Name of queue where the new field is to be applied to tickets.

    4. Who is to be allowed to see and/or modify data in the new field when in a ticket.

    5. Type of data to be entered (see example in box below).

    6. Values of data to be entered/selected from (see example in box below).

  • Type of data to be entered:

  • Values assigned to the custom field.

  1. Set-up Notifications using Scrips and Templates

All RT email notifications are set up using scrips and templates. A Scrip is basically “an action that is automatically triggered due to a specifically coded condition that is met as a result of a single transaction". A Template is basically an “email form letter” that is used as a notification. A template can be attached to any scrip. However, not all scrips (actions) are about notifications. Some are about the manipulation of data (existing or initial) contained in a ticket (ie. a scrip that causes data to be inserted into a Custom Field automatically when the ticket is created).

There are a set of standard global scrips that apply to all RT queues and there are queue specific scrips. The picture below shows all scrips that are applied to the GL queue. The top list displays the Global scrips (which apply to all queues) and the bottom list displays the scrip(s) written specifically for the GL queue (notice “Copy Subject to Description” is NOT a notification, the template is left blank. Hence the title does not begin with the word “Notify”).

If you have difficulty developing a scrip for your queue, contact Technical Services to request help or for them to develop the scrip for you.

  1. Request Assistance for Technical Issues

All users of the queue should go to the Queue Administrator for assistance and if needed the Queue Administrator can contact the RT System Administrator for assistance.

  1. Queue Administration

Queue Administrators are responsible for managing their queues. They decide how they want their queues to be configured and they work with the System Administrators to accomplish this goal. For instance, they decide which group(s) will access their queue, what privileges that group will have, what notifications (outside of the global standards) will be used, and any Custom Fields needed in order to meet the ticket information requirements for processing requests in their queue.

Queue Administrators should also be managing the tickets’ status/activity. They need to make sure tickets are being assigned appropriately, monitor ticket priorities and statuses, and that stalled tickets are not forgotten. If there are a lot of tickets in the queue, they may need to meet periodically with the functional owners and/or representatives in order to determine ongoing priorities.
Most importantly, Queue Administrators decide how they want the queue users to interact with RT. This can be done informally or formally with a set of standards or procedures. Because individual Queue Administrators will have different ways of working with their users, there isn’t one standard or procedure. It is the Queue Administrator’s responsibility to determine what works best for them in managing the queue and communicate that to their users.

    1. Add an Existing User to a Group

To be able to do anything in Request Tracker, a user must be granted rights. When a Queue Administrator needs to allow a user access to his/her queue, there are a couple pre-requisites:

  • The Queue Administrator needs to be sure that the user has already logged in. That action is what sets up the user (if owner of an LDAP UserID/Password) as a Privileged user (able to be granted any privileges).

  • Determine if there is an existing group that has the privileges this user needs.

If there is no group that exists with the appropriate privileges for said user to access the queue, then the Queue Administrator must either modify the rights to an existing group (to meet this need) or request a new group be created (by sending either an E_mail to “YOUR RT SUPPORT GROUP EMAIL/ALIAS ADDRESS GOES HERE” or by creating a new ticket in the TSG-RT queue within RT).

Now all that remains is for the Queue Administrator to add the user to whatever group seems appropriate.
It is important to remember that when users are no longer functioning as part of a group that you work with, you should remove them from that RT group. If you are aware that they no longer work for LBNL, then you should contact the RT System Administrator about removing the user from RT completely.

To add a user to a group, go to the top navigation bar and navigate thru Configuration > Groups > group name > Members. In the Add members drop down list, select the user you want (click the desired name and it will highlight) to add and click the Modify Members button at the bottom right of the screen.

You can also add a group as a member of a group (see the screen shot below). When adding a group to the membership, the UserID of the members (of any added group) will display among the other individual members already part of the group (under Users). This way you will know specifically who you are adding when you add a group. By removing a group, you remove all members of that group in one effort.

    1. Configure Group Rights/Privileges

Group rights (also called privileges) are what allows users with the same functional requirements (therefore in the same group) to access a particular queue in the RT system. These rights are set within the context of single queue. A single group may have access to several queues with a different set of rights for each one. When managing a queue, the Queue Administrator needs to decide what kind of privileges these groups will need in order to accomplish their goals pertaining to requests (See Appendix A for a listing of All rights used in RT by LBNL).

A queue may have several different groups of users sending or monitoring requests and therefore will need to configure a different set of rights per group. Technical Services recommends having a technical/support group (those who work on tickets) separate from the user group (those who monitor or make requests). As an example of granting rights and privileges, we will grant rights to two different groups for the Test queue:

  • IS-Test-Support (those that own/work on requests),

  • IS-Test-Users (those allowed to create requests for this queue).

    1. Sample Instructions to Set-up Rights Access for a Queue

In the top Navigation bar, select Configuration > Queues. A list of enabled queues will be displayed. Select your queue (in this case Test). The Basics information screen will be displayed.

We are now entirely within the queue selected (Test) and any changes we make will have an effect for this queue only. In the fourth navigation bar (below the bold red heading entitled

Editing Configuration for queue Test) select Watchers. There are two classes of watchers: Cc and AdminCc.

  1. Cc watchers are those persons that can receive email notifications regarding any ticket in the queue based on the Global notifications. If the Queue Administrator wants to include them on other conditions, then queue-based notifications can be set up. Cc watchers do not usually work on the requests. They just need to be kept informed.

  1. AdminCc are those persons that are assigned and granted rights as the administrator of a Queue, hence the role entitled AdminCc. Because of that distinction, an AdminCc may want a different set of notifications and is therefore a separate selection as a recipient. If the Queue Administrator wants to be notified for conditions other than the Global ones, then they can set up queue-based notifications for those conditions.

      1. AdminCc rights already granted at the Global level:

        1. AssignCustomFields – the right to add an existing Custom Field for all tickets in a queue.

        2. AdminGroupMembership – the right to add a UserID to the membership of any group with access to your queue(s).

        3. DelegateRights – the right to grant all rights currently owned by the AdminCc to another UserId.

        4. ModifyACL – the right to modify the access rights that are under his jurisdiction (the ones he grants as AdminCc).

        5. ModifyOwnMembership - the right to remove himself from membership of any group.

        6. SeeGroup – the right to see ALL groups that exist in RT.

        7. ShowACL – the right to see what access rights have been granted to the queue(s).

        8. ShowConfigTab – the right to see and use the Configuration option in the top navigation bar. Without this right, the AdminCc would not be able to change any rights or memberships or create/modify any queue-based scrips/templates.

        9. ShowScrips – the right to see the scrips in use for a queue.

        10. ShowTemplate – the right to see the templates available for use by a scrip.

        11. WatchAsAdminCc – the right to add watchers for AdminCc notifications (E_mails) for a ticket in the queue managed by said AdminCc.

      1. Recommended AdminCc rights at the Queue level:

        1. AdminQueue – Allows AdminCc to manage this queue only.

        2. DeleteTicket – Technical Services recommends letting only the Queue Administrator delete tickets.

        3. ModifyQueueWatchers – Allows AdminCc to manage watchers for this queue only.

        4. ModifyScrips – This allows the AdminCc to create queue specific scrips.

        5. ModifyTemplate - This allows the AdminCc to create queue specific templates.

        6. ModifyTicket – Technical Services recommends reserving this right for the Queue Admin and the owner of a ticket. It’s like checking out a software program; you do not want more than 1 person changing a program at a time, the same control should apply for a ticket.

        7. StealTicket – This allows the AdminCc to take a ticket that already has an owner. This allows the Queue Admin to re-assign it to another developer/owner.

For our first example, we will add a user as a Cc.

In the top Navigation bar select Configuration > Queues > Test > Watchers > New Watchers.
Under the New Watchers area, select Name or User Id from the drop-down menu under the heading “find people whose”. Type in the user name or id (the user names are case sensitive) and click the Go button. The name will appear under the Users title. Select Cc from the drop-down menu. Click the Save Changes button.

Now, select Group Rights (on the right) along the same navigation bar. From the top downward you will see listed System groups, Roles, and User defined groups.
Under System Groups, there is only one grouping to consider, Privileged. At this level, any right you grant will be allowed for ALL Privileged users in RT, regardless of their queue or group affiliations. With this in mind, there is really only one privilege you should consider granting; CreateTickets. Anything else should be granted to Roles or a user defined group.

There are four Roles defined in RT. They are Cc, AdminCc, Requestor, and Owner (See the next page for an example display). Roles are like a ‘pseudo’ group

Cc Role
We recommend no basic rights for the Cc Role in a queue because those have already been granted at the Global level. They are: ReplyToTicket, SeeQueue, ShowTicket, and Watch. If you want the CC role to get the same E_mail as the AdminCc, then you could add WatchAsAdminCc.
AdminCc Role
The AdminCc was granted appropriate rights by the System Administrator when the queue was set up. They are: AdminQueue, DeleteTicket, ModifyQueueWatchers, ModifyTicket, and StealTicket (if not already granted to the support group for this queue). At the Global level, they are allowed to AssignCustomFields, DelegateRights, ModifyACL, ModifyOwnMembership, SeeGroup, ShowACL, ShowConfigTab, ShowScrips, ShowTemplate, WatchAsAdminCc.
Requestor Role
A Requestor is anyone who has created a ticket. It is under this role that you grant rights to those users, who are basically a sub-group of the User group that is allowed to create tickets. Globally, they already have the right to ReplyToTicket, SeeQueue, ShowTicket, and Watch. Technical Services recommends careful consideration before granting these additional rights: CommentOnTicket, ShowOutgoingEmail, ShowComments. These particular rights would allow users to see any and all comments made by a technician or other support group member and you might not really want that. Select these three rights and click the Modify Group Rights button to apply these changes.
Owner Role
Owner is another defined role/pseudo group. Globally, they have been granted the right ModifyTicket. Since the owner of a ticket is also in the support group for the queue, Technical Services recommends strong consideration before granting these additional rights (beyond the other rights that would already be granted through the Support group), DeleteTicket and StealTicket. As the manager of the queue, you might want to have more control over who can steal or delete tickets that are owned. A Group cannot be an owner because there can only be one owner of a ticket.
The Queue Administrator may not want to define the role of owner but instead, include these rights at a group level only.

See an example of these rights on the next page.

User defined groups

All existing groups are available to be given access to the queue (remember the global right “SeeQueue” granted to AdminCc?). It is here that the Queue Administrator will grant rights to one or more of these groups. For the Test queue, the following rights are recommended for the IS-Test-Support and IS-Test-Users groups:

Note: See Appendix A for a complete list of Queue Rights.

    1. Apply a Custom Field to a Queue

A custom field that has been created can be applied globally to all tickets or just to those tickets in a single queue, or to groups, users, and ticket transactions. LBNL uses them just for tickets. Technical Services System Administrators will create Custom Fields at the request of a Queue Administrator.

Once a Custom Field has been defined, Queue Administrators will have the ability to:

  1. Select an existing Custom Field and applying that field to the tickets in their queue

Example: Select Configuration > Custom Fields.

Now, Select the desired field and click the “Applies to” (4th navigation bar item).

  1. Add, change, or delete values for their Custom Field

Example: Select Configuration > Custom Fields.
Select the field and click to add, change, or delete a value from a custom field.
Click the Submit button to apply the changes.

  1. Change the display order of the Custom Fields for a ticket in a Queue.

Example: Configuration > Queues > [Select the queue] > Ticket Custom Fields.
Select [Move Up] or [Move Down] to move the field.
Click the Submit button (bottom right of screen) to accept changes.

  1. Set up rights to See and/or Modify the Custom Field in a ticket.

Example: Configuration > Custom Fields> Select the field] > Group Rights
Select rights desired for the group(s).
Click the Submit button (bottom right of screen) to accept changes.

    1. Project Management

Part of the RT design for ticket management allows any ticket to relate (link) to another ticket in three different ways:

  • Parent/Child; this relationship is just like it sounds. It is in your queue and therefore you have some control over when/whether it gets resolved in time for your parent ticket to get resolved on schedule. One ticket is the parent or owner of another ticket making the child ticket a “sub” or “minor” task of the parent/major task of the initial request. The child ticket can also act as a parent to another child/sub task.

  • Depends on/Depended on by; this relationship is similar to the parent/child relationship mentioned above with the exception that the task being depended on is not in your queue and therefore not a “child” that you have control over (priority/completion date). However, this separate task still needs to be completed before the “parent” task can be resolved. Hence, the “Depends on” relationship.

  • Refers to/Refers to by; this relationship is not a dependency and more of a reference link. Basically, this type of relationship would be for a ticket that might need to be created/resolved as the result of another ticket but not subordinate or dependant in any way.

Below is an example of what these relationships might look like on your ticket screen:

Notice that this ticket (#51991) has several relationships:

  1. It depends on 51990; meaning this ticket cannot be resolved until 51990 is resolved.

  2. It is depended on by no other ticket.

  3. It has a parent ticket (#54375); that parent cannot be resolved until this ticket and any of this ticket’s children and dependencies are resolved.

  4. It has children (#51992) and ALL are part of the parent (#54375) and IN the same Queue.

  5. There are no other tickets in reference.

What these relationships give you is the ability to run a query of all tickets and their dependencies whether it be children tickets (in the same queue) or non-children tickets (“depends on” tickets in other queues). Of course, you can include other ticket info like Time Left, Comments, etc. that can aid you in presenting a fairly detailed picture of the work involved in resolving the highest parent ticket.

There are other ways to manage your projects as well. There are reminders. These are links to pseudo tickets that will reside with the ticket they are set up for and show up in the home page of the user they are assigned to. Right now, the only way to manage reminders is manually. They will not automatically go away when the ticket they are assigned to is resolved or deleted. They also will not automatically move from queue to queue with a ticket either.

You can also set up the Tidal (TES) job scheduler to send an email to your queue for every job that abends. This will automatically create a trouble ticket in RT for you. No waiting for a phone call or email and then creating the ticket yourself. RT, in turn, will send you (and anyone on your email list) an email alerting you to the fact you have a new ticket for a production job that abended, plus the ticket number and subject (Job name and description).
You could create a query for all tickets in your queue that came from TES. This query could be produced in chart form. This is another report that can aid you in showing what percentages of work is spent solving production jobs as opposed to fixing source code, etc.
The main point here is that as Queue Administrators, you can be very inventive by using a variety of queries to show what is going on, who is doing it, when they started, when they expect to finish, how long it took, what and who you are waiting on, etc.

Appendix A: List of All Rights in RT

The following is a list of the right definitions that are available in RT. In order to control users, groups, and global access this list will include the Technical Services guidelines for right assignment. ALL rights (privileges) are granted to groups and roles. NO individual user’s are granted privileges.

  • AdminAllPersonalGroups: not in use at IS because we don’t use Personal groups.

  • AdminCustomFields: reserved for System Administrators (Technical Services).

  • AdminGroup: reserved for System Administrators.

  • AdminGroupMemberShip: granted by System Administrators to Queue Managers (AdminCc). Allows grantee to add/delete members of any group they are members of.

  • AdminOwnPersonalGroups: not in use at IS

  • AdminQueue: Queue level right granted by System Administrator to Queue AdminCc’s. Allows grantee to manage a Queue in conjunction with other rights granted to this role.

  • AdminUsers: reserved for System Administrators.

  • AssignCustomFields: granted by System Administrators to Queue AdminCc’s. Allows grantee to select any existing Custom Field to be applied to all tickets within their respective Queue(s).

  • CommentOnTicket: granted by Queue AdminCc. Technical Services recommends using discretion when granting this right to users. Allows comments to be entered into a ticket without needing the “ModifyTicket” right.

  • CreateSavedSearch: global right granted by System Administrators to allow all users access to the query/report capabilities offered by RT. This limitation for which queues is defaulted to the queues they have rights to via group membership and that group’s rights to a queue.

  • CreateTicket: granted by Queue AdminCc. Limit this right only to those people (group of customers) that have a need to create a ticket in your queue. This right, without the “SeeQueue” right allows the creation of a ticket using E_mail only. To create a ticket within RT/WebUI, the “SeeQueue” right must also be granted.

  • DelegateRights: granted by System Administrators to Queue AdminCc’s. Allows grantee to grant any privilege they have to someone else.

  • DeleteTicket: granted by Queue AdminCc. Technical Services recommends that the technical support group for the queue be granted this right.

  • LoadSavedSearch: global right granted by System Administrators to allow all users the ability to load a saved search from the Query Builder tool (see CreateSavedSearch).

  • Modify ACL: granted by System Administrators to Queue AdminCc’s. Allows grantee to modify an existing ACL (Access Control List) they created. The rights granted to a group for your Queue is an ACL. The rights granted globally to all AdminCc’s is an ACL.

  • ModifyOwnMembership: granted by System Administrators to Queue AdminCc’s. Allows grantee to alter their membership in any group they are already a member of.

  • ModifyQueueWatchers: granted by System Administrators to Queue AdminCc’s to allow the addition or deletion of a queue watcher.

Appendix A: List of All Rights in RT

  • ModifyScrips: reserved for System Administrators.

  • ModifySelf: global right granted by System Administrator.

  • ModifyTemplate: reserved for System Administrators for Global Templates.

  • ModifyTicket: granted by the Queue Administrator. Technical Services recommends granting this right to the group that has users that actually work on the ticket (technical support). This right allows all fields (except custom fields, but including comments) to be modified.

  • OwnTicket: granted by the Queue Administrator. Technical Services recommends granting this right to the group that has users that actually work on the ticket.

  • ReplyToTicket: This right has been granted to all Privileged users on a global basis. Allows grantee to issue a reply (E_mail) within a ticket in RT.

  • SeeQueue: granted by the Queue Administrator. This right allows grantee the ability to see the Queue in the drop-down list when creating a ticket within RT/WebUI. Used in conjunction with “CreateTicket” to create tickets and used with “ShowTicket” to see tickets in a Queue or via Query.

  • ShowACL: granted by System Administrators to Queue AdminCc’s. Allows grantee to see any ACL created by said person. See ModifyACL.

  • ShowConfigTab: granted globally by System Administrators to Queue AdminCc’s. This right allows the Queue administrator access to the configuration area in the top navigation bar. The configuration area is where rights are granted/modified, scrips/templates created/modified.

  • ShowOutgoingEmail: granted by the Queue Administrator. Allows user to see (in ticket history) the outgoing email sent/received by RT for a ticket.

  • ShowScrips: granted globally by System Administrators to Queue AdminCc’s. Allows grantee to see the notification scrips applicable to their respective Queue(s).

  • ShowTemplate: granted globally by System Administrators to Queue AdminCc’s. Allows grantee to see the templates used by scrips applicable to their respective Queue(s).

  • ShowTicket: granted by the Queue Administrator to allow users or group of users the right to see tickets in an RT queue or via query. Used in conjunction with “SeeQueue”.

  • ShowTicketComments: granted by the Queue Administrator to allow any user or group of users the right to see ticket comments only in a ticket.

  • SuperUser: reserved for RT System Administrators only.

  • Watch: granted by the Queue Administrator to allow users or group of users the ability to add recipients (of correspondence) on a ticket within a Queue.

  • WatchAsAdminCc: granted by System Administrators to Queue AdminCc’s. Allows grantee the ability to add recipients (of AdminCc correspondence) on a ticket within a Queue.

Appendix A: List of All Rights in RT
The following is a list of the RT Global Group/Role Privileges:

  1. System Groups:

    1. Everyone;

      1. None

    2. Privileged;

      1. CreateSavedSearch

      2. EditSavedSearch

      3. LoadSavedSearch

      4. ModifySelf

      5. ShowSavedSearch

  2. Roles;

    1. Owners;

      1. ModifyTicket

    2. Requestors;

      1. ReplyToTicket

      2. SeeQueue

      3. ShowTicket

    3. CC;

      1. ReplyToTicket

      2. SeeQueue

      3. ShowTicket

      4. Watch

    4. AdminCc;

      1. AdminGroupMembership

      2. AssignCustomFields

      3. DelegateRights

      4. ModifyOwnMembership

      5. SeeGroup

      6. ShowConfigTab

      7. ShowScrips

      8. ShowTemplate

      9. WatchAsAdminCc

  1. User-Defined Groups;

    1. Queue-Admin;

      1. AdminGroupMembership

      2. SeeGroup

      3. ShowConfigTab

      4. ShowScrips

      5. ShowTemplate

Appendix A: List of All Rights in RT

The following is a list of the default RT Queue “Group” Privileges:

  1. System Groups:

    1. Everyone;

      1. None

    2. Privileged;

      1. CreateTicket (by AdminCc request only, otherwise allow only User-Group)

    3. UnPrivileged;

      1. None

  2. Roles:

    1. Cc;

      1. None

    2. AdminCc;

      1. CreateTicket (if NOT on Privileged)

      2. DeleteTicket

      3. ModifyACL

      4. ModifyQueueWatchers

      5. ModifyTicket

      6. ShowACL

      7. StealTicket

    3. Requestor (by AdminCc request only);

      1. CommentOnTicket

      2. ShowOutgoingEmail

      3. ShowTicketComments

    4. Owner (by AdminCc request only, otherwise leave as AdminCc);

      1. DeleteTicket (if AdminCc allows)

  3. User-Defined Groups:

    1. XXXX-Support;

      1. CommentOnTicket

      2. CreateTicket (if NOT on Privileged and by AdminCc request only)

      3. OwnTicket

      4. ReplyToTicket

      5. SeeQueue

      6. ShowOutgoingEmail

      7. ShowTicket

      8. ShowTicketComments

      9. StealTicket (if AdminCc allows)

      10. TakeTicket

      11. Watch

    2. XXXX-Users;

      1. CommentOnTicket (if AdminCc allows)

      2. CreateTicket (if NOT on Privileged)

      3. ReplyToTicket

      4. SeeQueue

      5. ShowOutgoingEmail (if AdminCc allows)

      6. ShowTicket (if AdminCc allows)

      7. ShowTicketComments (if AdminCc allows)

      8. Watch

Appendix B: Glossary of RT Terms

ACL: RT has a rich authorization schema, based on Access Control Lists (ACLs). ACLs provide fine-grained control over what a user can and cannot do at the ticket, queue, group, and global levels. Rights can be granted by an administrator to specific users, groups or roles in which case what a user is allowed to do is a combination of user, group and role ACLs.

AdminCc: This person manages the Queue (see RT Queue Admin Guide). The AdminCc may or may not get correspondence about a ticket, depending on the notification scrips set up for the queue.

Attachment: An attachment is a discrete piece of content added to the ticket body. Every attachment is associated with a transaction.

Body: The ticket's body is the full, detailed explanation of the ticket. It is maintained as a series of discrete elements, called attachments , which are grouped together in a transaction. A ticket's body consists of all its transactions , arranged chronologically.

Conditions: How does RT know whether to execute a scrip? This decision is based on the scrip's condition , which determines whether a scrip is applicable to the current transaction.

Custom fields: These are application-specific metadata that are created specifically for customization of RT. Custom fields can be created for 4 types of objects; tickets, transactions on tickets, users and groups. Each custom field can exist for only one type of object. Ticket and transaction custom fields can be tied to any number of queues, but user and group custom fields apply system-wide. Currently, we only use custom Fields for tickets (in a Queue).

Types of custom fields:

  • Select – These fields have a predetermined set of values.

  • Freeform – These fields contain single lines of text.

  • Text – These fields hold multi-line blocks of plain text.

  • Wikitext – These fields hold multi-line blocks of wiki text.

  • Binary – These fields are uploaded files.

  • Image – These fields are like Binary fields, but they are displayed on the Web UI instead of presented as download links.

Dates: There are many dates associated with each ticket, everything from when the ticket was originally created, to when it was last modified, to when it was resolved. RT automatically sets some of these at the time of certain actions, while some can be modified by anyone with the appropriate rights.

Types of dates:

  • Created: The date that ticket was initially created. Updated by RT.

  • Starts: The date when work should begin on the ticket. Can be set by anyone with permissions to modify the ticket.

  • Due: The date by which the ticket should be completed. Can be set by anyone with permissions to modify the ticket.

  • Started: The date that work was actually started on the ticket. Can be set by anyone with permissions to modify the ticket.

Appendix B: Glossary of RT Terms

  • Last Contacted: This date indicates that last time notification about the ticket was sent out. Updated by RT.

  • Last Updated: The date of the last modification to the ticket. Updated by RT.

  • Resolved: The date that the ticket was resolved. Updated by RT.

Groups: Users are arranged into groups, which represent collections of users. Groups can be arranged in any way. Users can be members of any number of groups, so groups can be used to organize users as well as configure access permissions.

History: A ticket's history is everything that has happened to a ticket. RT automatically tracks every change to a ticket, including when the ticket was created, how it has changed, and any comments about it or replies to it. Like real history, ticket history cannot be changed, so be aware that any comments or replies you make about a ticket are permanent. This audit trail provides detailed information about not only what changed, but who changed it and when it changed. As of RT 3.4, RT also tracks every outgoing email about a ticket.

Ticket updates (of history) can take one of two forms:

  • Reply: Public remark that is sent to a requestor.

  • Comment: Private note visible only to those with the privilege to "SeeComments." This is useful for conveying technical information that is not of interest to a requestor or non-support groups.

Owner: The person responsible for the ticket and its resolution. Each ticket can have only one owner at any given time. The owner may or may not get correspondence about a ticket, depending on the notification scripts set up for a queue.

Priority: Priority represents the relative importance of a ticket. It is represented on a numerical scale from 5 to 1, with 1 being the highest priority.

Queue: A container for grouping tickets. The queue is the central administrative domain of RT. Permissions are applied to queues, rather than directly to tickets, so which actions you can take on a ticket depends on what privileges the manager of a queue allows for the ticket's queue.

Queue-Administrator: A person listed as the AdminCc. This person manages the queue.

Relationships: RT maintains relationships between tickets and other objects. Relationships can be between multiple tickets but also can link tickets to external items like URLs or other bug tracking systems.

Types of relationships are:

  • Depends on: The ticket can't be resolved unless another ticket is also resolved.

  • Depended on by: The converse of Depends on.

  • Refers to: The ticket doesn't need the other ticket, but it provides useful information for this ticket.

  • Referred to by: The converse of Refers to.

  • Reminders: A pseudo ticket that is attached to a real ticket. It shows up on the Owner’s home page.

Appendix B: Glossary of RT TermS

  • Parent: A ticket about a large project or problem that has one or more subprojects connected to it.

  • Child: A subproject of a parent.

Requestor: A person or people who created the ticket or have a vested interest in the outcome. This person may or may not get correspondence about a ticket, depending on the notification scrips set up for the queue.

Scrip: Scrips are custom actions that are automatically triggered in response to specific conditions. For example, RT can email the requestor when a ticket is resolved. Scrips can be applied to all tickets or to all tickets in a specific queue.

Status: A ticket's status describes it’s current state.

Status types are:

  • new: The ticket has just been created and hasn't been touched yet.

  • open: The ticket is being worked on.

  • pending qa: The work is complete and is currently awaiting results from the QA/Acceptance testing.

  • pending rv: The ticket is currently awaiting review/approval before being assigned to a queue for work.

  • qa approvd: The QA/Acceptance test is complete and the results have been approved.

  • rq approvd: The ticket has been approved for work and will be moved to a queue based on priority.

  • stalled: Due to circumstances beyond your control, the ticket isn't getting worked on right now. It will open again when someone adds a comment or reply.

  • resolved: Work on the ticket has been completed and migrated to production.

  • rejected: The ticket is not going to be resolved, for whatever reason, but needs to be recorded in the system.

  • deleted: The ticket never should have been in the system.

Subject: The subject of a ticket is analogous to the subject of an email: a short summary of what the ticket is about, at most a few hundred characters, intended to convey the gist of the ticket at a casual glance.

Templates: When a scrip is activated, it executes a template. Most templates turn into email messages, but since you can embed Perl in them, they can do just about anything.

Ticket: The record of a problem report or enhancement request or whatever you are tracking. A ticket is identified by number and has a set of attributes, such as the subject or summary, who opened it, when it was opened, the priority of the request, and the current status.

Transaction: A transaction represents a single modification to a ticket, from status changes to adding content to the body. A transaction that adds content to the body of a ticket consists of one or more attachments.

Appendix B: Glossary of RT TermS

Users: A user represents a single entity within RT. Usually, the RT Administrator creates manually, but RT can be configured to autocreate user objects. Once a user exists, they can log in and modify their contact information.

Watchers: A watcher is someone who is interested in a ticket. Watchers are notified when something about the ticket changes. Some types of watchers are inherited from the queue in which the ticket lives, while others are attached to the ticket itself.

Types of watchers are:

  • Cc: Someone who should get copies (depending on the notification scrips set up for a queue) of any correspondence, etc.that goes out from the ticket. this person will see the email but may not have the right to work on the ticket.

  • AdminCc: A Cc that also gets copies of private comments (depending on the notification scrips set up for a queue) about the ticket and generally has permission to work on the ticket.

Request Tracker Queue Administrator Guide Rev. December 15, 2007

Yüklə 106,16 Kb.

Dostları ilə paylaş:

Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur © 2024
rəhbərliyinə müraciət

    Ana səhifə