Ticketing can make life easier for many people and departments in an organization -- basically anyone who needs to keep track of a list of tasks. And it can be used with a variety of tasks, like fixing software bugs, answering customer service requests, or tracking security issues. Tickets can be a simple record of work done, like "Applied software patches on server," or detailed records with many custom fields and a long history.
How you use tickets in RT will depend on your use case and can differ from queue to queue. Whatever your approach, it's good to communicate with users so everyone understands why and how they should interact with the system. RT is a ticketing system for all sizes of organizations.
Managed hosting plans and commercial support are also available from Best Practical Solutions. We'll get into the technical features later, but for now, let's look at how RT might work:. This workflow is flexible, can be customized for your organization, and need not involve bananas.
There are some words and phrases you should understand in the context of RT before you begin. See RTGlossary for more definitions. A Ticket is the central object in RT, the thing that needs to get done. Tickets have metadata attached to them such as an owner, status, and queue - we'll get to all that in a minute. A Queue is the central administrative domain of RT; it keeps things organized.
As the name implies, it's a line of tickets waiting to be worked on, but it's also, to some extent, the ticket's category. For instance, you might have the right to create, delete, and comment on tickets in the Foo queue, but only the right to comment on tickets in the Bar queue. A ticket's history is what it sounds like: everything that's happened to a ticket. Facets of ticket history could include when the ticket was created, how it has changed, and any comments about it or replies to it.
Like real history, ticket history typically is not changed. However, new laws related to user privacy like GDPR in the EU require some organizations to evaluate their auditing policies and decide how to handle requests to remove personal user data. This can require ticket data to be modified or removed completely. Ticket updates can take one of two forms. A reply is a public remark that a requestor can see. A comment is a private note for staff not visible to the requestor.
This is useful when you want to be tactful but still convey important information, like, "This requestor is an investor, so be nice" or "This user's request mentioned his 'PC' but he really has a Mac.
Priority, how important a ticket is, is represented as numerical scale from , with 99 being the highest priority. By setting a final priority, you can make a ticket's priority increase or decrease as its due date draws closer. The difference between 20, 50, and 75 may vary from organization to organization, but there should be an organizational policy or every ticket will get rated 99 by anxious users. Change to that directory and run the following command: tar xzvf rt.
To see the list of options, run:. It tries to guess which of www-data, www, apache or nobody your webserver will run as, but you can override that behavior. Similarly, if you were coming from 4. Any upgrade steps given in version-specific UPGRADING files should be run after the rest of the steps below; however, please read the relevant documentation before beginning the upgrade, so as to be aware of important changes.
RT stores the arguments given to. Check for missing dependencies by running: make testdeps 4 If the script reports any missing dependencies, install them by hand, or run the following command as a user who has permission to install perl modules on your system: make fixdeps Some modules require user input or environment variables to install correctly, so it may be necessary to install them manually.
Some modules also require external source libraries, so you may need to install additional packages. Ticket relationship graphing requires the graphviz library which you should install using your distribution's package manager. Once completed, you should now have a working RT instance running with the standalone rt-server.
Press Ctrl-C to stop it, and proceed to Step 7 to configure a recommended deployment environment for production. If you don't have a current backup, upgrading your database could accidentally damage it and lose data, or worse. First, stop your webserver. You may also wish to put incoming email into a hold queue, to avoid temporary delivery failure messages if your upgrade is expected to take several hours. Next, install new binaries, config files and libraries by running: make upgrade This will also prompt you to upgrade your database by running: make upgrade-database You should back up your database before running this command.
When you run it, you will be prompted for your previous version of RT such as 4. If 'make upgrade-database' completes without error, your upgrade has been successful; you should now run any commands that were supplied in version-specific UPGRADING documentation. You should then restart your webserver. Depending on the size and composition of your database, some upgrade steps may run for a long time. You may also need extra disk space or other resources while running upgrade steps.
FirstInactiveStatus Returns the first inactive status that the ticket could transition to, according to its current Queue's lifecycle. TimeWorkedAsString Returns the amount of time worked on this ticket as a text string.
TimeLeftAsString Returns the amount of time left on this ticket as a text string. TimeEstimatedAsString Returns the amount of time estimated on this ticket as a text string. Comment Comment on this ticket. Correspond Correspond on this ticket. Performs no access control checks. Merged Returns list of tickets' ids that's been merged into this ticket.
Rights to Set Owner The current user can set or change the Owner field in the following cases: ReassignTicket unconditionally grants the right to set the owner to any user who has OwnTicket.
This method accepts the following parameters as a paramshash: NewOwnerObj Optional; an RT::User object representing the proposed new owner of the ticket. Type Optional; the type of set owner operation.
Take A convenince method to set the ticket's owner to the current user Untake Convenience method to set the owner to 'nobody' if the current user is the owner.
Steal A convenience method to change the owner of the current ticket to the current user. Delete Takes no arguments. Useful when we're sending replies. Should be false until you enter the code that runs TransactionBatch scrips Accepts an optional argument to indicate that TransactionBatch Scrips should no longer be run on this object. TransactionBatch Returns an array reference of all transactions created on this ticket during this ticket object's lifetime or since last application of a batch, or undef if there were none.
Only works when the UseTransactionBatch config option is set to true. ApplyTransactionBatch Applies scrips on the current batch of transactions and shinks it. Transactions Returns an RT::Transactions object of all transactions on this ticket TransactionCustomFields Returns the custom fields that transactions on tickets will have. ACLEquivalenceObjects This method returns a list of objects for which a user's rights also apply to this ticket.
In the database, id is stored as int EffectiveId Returns the current value of EffectiveId. In the database, EffectiveId is stored as int Queue Returns the current value of Queue. In the database, Queue is stored as int Type Returns the current value of Type. In the database, Type is stored as varchar Owner Returns the current value of Owner. In the database, Owner is stored as int Subject Returns the current value of Subject. In the database, Subject is stored as varchar InitialPriority Returns the current value of InitialPriority.
FinalPriority Returns the current value of FinalPriority. Priority Returns the current value of Priority. In the database, Priority is stored as int TimeEstimated Returns the current value of TimeEstimated.
TimeWorked Returns the current value of TimeWorked. In the database, TimeWorked is stored as int Status Returns the current value of Status. In the database, Status is stored as varchar TimeLeft Returns the current value of TimeLeft. In the database, TimeLeft is stored as int Told Returns the current value of Told.
In the database, Told is stored as datetime. Starts Returns the current value of Starts. In the database, Starts is stored as datetime. Started Returns the current value of Started.
In the database, Started is stored as datetime. Due Returns the current value of Due. In the database, Due is stored as datetime.
0コメント