Greetings from a New RT user in Toronto

RT Users
1

Greetings Folks:

I successfully installed RT on a virtual machine and it has been a
non-stop learning marathon for 12+ hrs non stop. If you are as new as
me in RT, please reply to my message, and perhaps we can have a
conference call (at my expense) to do some sort of study group session,
so we can share knowledge.

Its easiest to learn when there are friendly tutors. FYI, I have
acquired the following knowledge the very hard way.

  1. Setup / Installation. (The hardest part)
  2. Creating Users
  3. Creating Groups
  4. Understanding Permissons
  5. Enabling watchers
  6. Configuring Fetch Mail with SSL option to a gmail account (for testing)
  7. Configuring Sendmail / Exim and smart host
  8. Purging / Shredding tickets

What I would like to learn is:

  1. Create Random Ticket numbers.
  2. Suppress “RT System Itself - Outgoing email recorded”
  3. Customization of Auto ticket reply.
  4. Assigning tickets / transferring to someone else (when not logged in
    as root)
  5. 3rd Party CRM integration basics.

Thanks in advance to all the folks here, specially the creators of RT.

Best,
Reza.

2

Hi Reza

Welcome to RT. We’re a fairly new user of the product so have recent
experience of your learning curve!

We have a bit of a workaround in place for "2. Suppress “RT System
Itself…)” lines in the History. We simply hide the entries with custom
css. In Admin > Tools > Theme > Custom CSS (Advanced), we’ve added:

div.transaction.Ticket-transaction.other {
display: none;
}

This hides all those RT System messages while leaving things like actual
message content/comments alone.

As far as “4. Assigning tickets…” goes, have you set any of your users as
“Privileged”? As far as I remember if you are logged in as a privileged
user you should be able to assign tickets to other privileged users.

Regards
ChrisOn Mon, 24 Oct 2016 at 21:50 Reza reza.toronto@gmail.com wrote:

Greetings Folks:

I successfully installed RT on a virtual machine and it has been a
non-stop learning marathon for 12+ hrs non stop. If you are as new as
me in RT, please reply to my message, and perhaps we can have a
conference call (at my expense) to do some sort of study group session,
so we can share knowledge.

Its easiest to learn when there are friendly tutors. FYI, I have
acquired the following knowledge the very hard way.

  1. Setup / Installation. (The hardest part)
  2. Creating Users
  3. Creating Groups
  4. Understanding Permissons
  5. Enabling watchers
  6. Configuring Fetch Mail with SSL option to a gmail account (for testing)
  7. Configuring Sendmail / Exim and smart host
  8. Purging / Shredding tickets

What I would like to learn is:

  1. Create Random Ticket numbers.
  2. Suppress “RT System Itself - Outgoing email recorded”
  3. Customization of Auto ticket reply.
  4. Assigning tickets / transferring to someone else (when not logged in
    as root)
  5. 3rd Party CRM integration basics.

Thanks in advance to all the folks here, specially the creators of RT.

Best,
Reza.

RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training

  • Boston - October 24-26
  • Los Angeles - Q1 2017
3

Customizing email notifications as in #3 is done through the templates. As
root, or a super user, go to Admin > Templates > Select. There you’ll find
a table with all the templates the system uses. Admin > Scripts is where
you can see which templates go to which events. The wiki (
rt-wiki.bestpractical.com) has a couple helpful pages on templates, such as
TemplateSnippets - Request Tracker Wiki

You grant users the right to transfer, own, take, and steal tickets. RT
likes you to use groups rather than granting rights on a user-by-user
basis. For instance, our system has five queues, and each queue has a
queue_staff and queue_users group. In the staff group for each queue, we
grant the rights I mentioned. This way, simply adding a user to the staff
group in their queue is enough to give them all the rights they need.

As you may have found, rights are integral to not just what users can do
with tickets, but to which tickets and queues they can view at all. Getting
to know the rights system will help a lot.On Mon, Oct 24, 2016 at 5:08 PM, Chris McClement chrisis@bosberaad.com wrote:

Hi Reza

Welcome to RT. We’re a fairly new user of the product so have recent
experience of your learning curve!

We have a bit of a workaround in place for "2. Suppress “RT System
Itself…)” lines in the History. We simply hide the entries with custom
css. In Admin > Tools > Theme > Custom CSS (Advanced), we’ve added:

div.transaction.Ticket-transaction.other {
display: none;
}

This hides all those RT System messages while leaving things like actual
message content/comments alone.

As far as “4. Assigning tickets…” goes, have you set any of your users
as “Privileged”? As far as I remember if you are logged in as a privileged
user you should be able to assign tickets to other privileged users.

Regards
Chris

On Mon, 24 Oct 2016 at 21:50 Reza reza.toronto@gmail.com wrote:

Greetings Folks:

I successfully installed RT on a virtual machine and it has been a
non-stop learning marathon for 12+ hrs non stop. If you are as new as
me in RT, please reply to my message, and perhaps we can have a
conference call (at my expense) to do some sort of study group session,
so we can share knowledge.

Its easiest to learn when there are friendly tutors. FYI, I have
acquired the following knowledge the very hard way.

  1. Setup / Installation. (The hardest part)
  2. Creating Users
  3. Creating Groups
  4. Understanding Permissons
  5. Enabling watchers
  6. Configuring Fetch Mail with SSL option to a gmail account (for
    testing)
  7. Configuring Sendmail / Exim and smart host
  8. Purging / Shredding tickets

What I would like to learn is:

  1. Create Random Ticket numbers.
  2. Suppress “RT System Itself - Outgoing email recorded”
  3. Customization of Auto ticket reply.
  4. Assigning tickets / transferring to someone else (when not logged in
    as root)
  5. 3rd Party CRM integration basics.

Thanks in advance to all the folks here, specially the creators of RT.

Best,
Reza.

RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training

  • Boston - October 24-26
  • Los Angeles - Q1 2017

RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training

  • Boston - October 24-26
  • Los Angeles - Q1 2017

Alex Hall
Automatic Distributors, IT department
ahall@autodist.com

4

Chris, Alex, Gentlemen:

Thank you for your generosity. Let me learn a little bit more and it
will give me the confidence to ask stupid questions. :slight_smile: Anyone in here
would like to engage in a conference call type group study / chat,
please let me know. I have a VoIP server to which all of us could
connect to easily.

Thank you!
Reza.

Alex Hall wrote on 10/24/2016 5:16 PM:

5

Many thanks to my first 3 teachers, Kenneth Crocker, Alex Hall and Chris
McClement, for guiding me to the right direction.

Ken, many thanks for your generosity for passing me a copy of your book
“Request Tracker for Beginners - A Topical Guide” ( also available on
Amazon if those of you newbie seeking knowledge )

Many thanks to the authors of “RT Essentials” published by O’Reilly.
This is also a good start for the fundamental basics for RT.

The last 24-48 hrs has been an amazing learning experience. I feel
as-if I can do Kung Fu now :slight_smile:

  1. Create Random Ticket numbers.
  2. Suppress “RT System Itself - Outgoing email recorded”
  3. Customization of Auto ticket reply.
  4. Assigning tickets / transferring to someone else (when not logged in
    as root)
  5. 3rd Party CRM integration basics.
  6. How to Customize the RT at a glance (Just added to my list for Oct
    25, 2016)

I have learned points #2, #3, #4.

Can anyone here guide me to the proper direction to accomplish #1
(Generating random ticket number versus ascending ticket numbers), and
guide me towards a fundamentally basic API example for 3rd Party CRM
integration?

The new things I’ve learned:

  1. Creating Queues
  2. Creating Memberships
  3. Understanding Group Permissions
  4. Taking ownership of a ticket
  5. Assigning tickets to someone else
  6. Basic Ticket operations (Open, Close, Delete, Forward, Stealing etc)

I’m learning that RT is not only for managing Support Tickets, but it
can also be used to followup on Sales leads etc (in the same manner as a
support ticket is handled), but I have yet to understand how it can be
used in Project Management. A combination of active / hands on
learning is needed here, in parallel to passive learning. That’s the
hardest part because I’m not a very good passive learner (learning
through reading).

I’m anticipating my status updates on this learning curve will serve as
an agenda for the new folks adapting RT.

In the mean time, I will be reading Ken’s “Request Tracker for
Beginners” guide till I pass out.

Thanks for welcoming me to the community.

Cheers!
Reza.> On Mon, 24 Oct 2016 at 21:50 Reza <reza.toronto@gmail.com mailto:reza.toronto@gmail.com> wrote:

Greetings Folks:

I successfully installed RT on a virtual machine and it has been a
non-stop learning marathon for 12+ hrs non stop.   If you are as
new as
me in RT, please reply to my message, and perhaps we can have a
conference call (at my expense) to do some sort of study group
session,
so we can share knowledge.

Its easiest to learn when there are friendly tutors.  FYI, I have
acquired the following knowledge the very hard way.
1.  Setup / Installation.  (The hardest part)
2.  Creating Users
3.  Creating Groups
4.  Understanding Permissons
5.  Enabling watchers
6.  Configuring Fetch Mail with SSL option to a gmail account (for
testing)
7.  Configuring Sendmail / Exim and smart host
8.  Purging / Shredding tickets


What I would like to learn is:
1.  Create Random Ticket numbers.
2.  Suppress "RT System Itself - Outgoing email recorded"
3.  Customization of Auto ticket reply.
4.  Assigning tickets / transferring to someone else (when not
logged in
as root)
5.  3rd Party CRM integration basics.

Thanks in advance to all the folks here, specially the creators of RT.

Best,
Reza.

---------
RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017
6

Reza writes:

The last 24-48 hrs has been an amazing learning experience. I feel
as-if I can do Kung Fu now :slight_smile:

From my recent agenda of:

  1. Create Random Ticket numbers.
  2. Suppress “RT System Itself - Outgoing email recorded”
  3. Customization of Auto ticket reply.
  4. Assigning tickets / transferring to someone else (when not logged in
    as root)
  5. 3rd Party CRM integration basics.
  6. How to Customize the RT at a glance (Just added to my list for Oct
    25, 2016)

I have learned points #2, #3, #4.

Can anyone here guide me to the proper direction to accomplish #1
(Generating random ticket number versus ascending ticket numbers), and
guide me towards a fundamentally basic API example for 3rd Party CRM
integration?

In order to generate a random ticket ID, you need a random number generator, a min and max ID number allowed, and a way to determine if any given ID has already been used. You then need to replace the standard SQL that gets the current max ID and adds one to assign a new ID. I don’t know where that code is. As you fill the IDs, generating a new ID becomes harder and harder, because you will hit duplicate entries in the random generating process. You also loose the relation of ID#s to date order. Sorting a list of IDs by ID number will randomize the time that the IDs occur, requiring reports to be modified to be sorted by some other key.

Basically, you need a very strong reason to break the defaults the program uses, because there is a lot of work needed to rewrite the many things that use the defaults, and the time spent verifying that you found all the bits that need to be changed.

What is your use case?

/jeff
The information contained in this e-mail is for the exclusive use of the
intended recipient(s) and may be confidential, proprietary, and/or
legally privileged. Inadvertent disclosure of this message does not
constitute a waiver of any privilege. If you receive this message in
error, please do not directly or indirectly use, print, copy, forward,
or disclose any part of this message. Please also delete this e-mail
and all copies and notify the sender. Thank you.

7

Greetings Jeff:

Thank you for your reply.

The use case for random IDs is quite simple. Ascending / serial number
of IDs compromises confidentiality. End users would be able to guess
how busy I could be with the amount of tickets answered. Its something
I don’t want to disclose. Almost ALL ticketing systems I have seen,
have a random arbitrary numeric or alpha-numeric ID. Any other
suggestions on how to approach not displaying an obvious number to end
users?

Thanks!
Reza.

Jeffrey Pilant wrote on 10/25/2016 10:12 AM:

8

Reza writes:

The use case for random IDs is quite simple. Ascending / serial number
of IDs compromises confidentiality. End users would be able to guess
how busy I could be with the amount of tickets answered. Its something
I don’t want to disclose. Almost ALL ticketing systems I have seen,
have a random arbitrary numeric or alpha-numeric ID. Any other
suggestions on how to approach not displaying an obvious number to end
users?

I don’t think I have ever seen a random number for ticket ID.
I have seen many systems that show reports of number of tickets processed per unit of time and he average answer time.
I guess I have never encountered your need before.

Seeing a series of ticket IDs may tell them how fast tickets come in, but it will not tell them how fast they are answered.

What might be easier is to create a custom field that holds a random number (maybe a GUID?). This number could then be placed in the email subject line in place of the ticket ID. Likiewise, the email reader could read the number from the subject and look up the ID. This would touch a lot fewer places in the code, and if the recipient only ever sees the email, they don’t know the real number. Meanwhile, users of the web interface see both real number and random number.

If you allow them to see the web interface, the above will not work.

A simple possible solution is to add a random amount to the ticket sequence in the code that generates ticket numbers. You will need a much larger max ticket ID since there is so much wasted space, but the random nature will obscure the number of real tickets between two given ticket IDs.

/jeff

The information contained in this e-mail is for the exclusive use of the
intended recipient(s) and may be confidential, proprietary, and/or
legally privileged. Inadvertent disclosure of this message does not
constitute a waiver of any privilege. If you receive this message in
error, please do not directly or indirectly use, print, copy, forward,
or disclose any part of this message. Please also delete this e-mail
and all copies and notify the sender. Thank you.

9

I’m just taking a shot in the dark, not knowing the code base well, but
what about this. You keep the actual number, but add things before and
after it. For instance:
1207b6988c77
where the ID is 988. Your filter is a letter followed by a number, then
your ID, then a letter. You can add random numbers before and after this to
as much length as you want. The random digit after the first letter will
make it far less obvious where the actual ID is, since the ID would change
for a new ticket, as would the random digit. You might even be able to
avoid reuse by tracking the letters and digit used, giving you 26263
patterns before you’d have to start over. Not true random, but maybe it’s
enough for your purposes and would be less of a process to implement?
Again, this is just a thought from someone who doesn’t know the code well
at all.On Tue, Oct 25, 2016 at 2:43 PM, Jeffrey Pilant jeffrey.pilant@bayer.com wrote:

Reza writes:

The use case for random IDs is quite simple. Ascending / serial number
of IDs compromises confidentiality. End users would be able to guess
how busy I could be with the amount of tickets answered. Its something
I don’t want to disclose. Almost ALL ticketing systems I have seen,
have a random arbitrary numeric or alpha-numeric ID. Any other
suggestions on how to approach not displaying an obvious number to end
users?

I don’t think I have ever seen a random number for ticket ID.
I have seen many systems that show reports of number of tickets processed
per unit of time and he average answer time.
I guess I have never encountered your need before.

Seeing a series of ticket IDs may tell them how fast tickets come in, but
it will not tell them how fast they are answered.

What might be easier is to create a custom field that holds a random
number (maybe a GUID?). This number could then be placed in the email
subject line in place of the ticket ID. Likiewise, the email reader could
read the number from the subject and look up the ID. This would touch a
lot fewer places in the code, and if the recipient only ever sees the
email, they don’t know the real number. Meanwhile, users of the web
interface see both real number and random number.

If you allow them to see the web interface, the above will not work.

A simple possible solution is to add a random amount to the ticket
sequence in the code that generates ticket numbers. You will need a much
larger max ticket ID since there is so much wasted space, but the random
nature will obscure the number of real tickets between two given ticket IDs.

/jeff

The information contained in this e-mail is for the exclusive use of the
intended recipient(s) and may be confidential, proprietary, and/or
legally privileged. Inadvertent disclosure of this message does not
constitute a waiver of any privilege. If you receive this message in
error, please do not directly or indirectly use, print, copy, forward,
or disclose any part of this message. Please also delete this e-mail
and all copies and notify the sender. Thank you.

RT 4.4 and RTIR training sessions, and a new workshop day!
https://bestpractical.com/training

  • Boston - October 24-26
  • Los Angeles - Q1 2017

Alex Hall
Automatic Distributors, IT department
ahall@autodist.com

10

Thank you for your detailed response Jeff.

Thinking out of the box, a Random Number is not necessary if we can mask
it from email responses. In my specific case, I do not want non-staff
to access RT. Only support agents.

Is some sort of ID number absolutely necessary in the subject field and
can this be removed? I guess a more technical question is how RT tracks
the email thread? Is it through the headers, or a basic primitive
Subject field comparison ?

Then again… I’m thinking… a ticket number is so much easier if its
relayed to support agents by caller if they decide to simply call for
support.

Thoughts, ideas and suggestions welcome.

Best,
Reza.

Jeffrey Pilant wrote on 10/25/2016 2:43 PM:

11

To my knowledge, yes, mail is routed through use of the subject line. When you create a queue, you give it a tag that is used in email subjects, and that is combined with the ticket ID to form the basis for how RT knows which queue/ticket a given message goes to. However, you can customize the regular expression RT uses, I believe, which fits with my suggestion from earlier today. You may be able to tune the expression to pull the true ID out of the randomized string, making your only coding task that of generating the random characters in the first place. See the $EmailSubjectTagRegex variable on this page:
RT Config - RT 4.4.1 Documentation - Best Practical> On Oct 25, 2016, at 19:51, Reza reza.toronto@gmail.com wrote:

Thank you for your detailed response Jeff.

Thinking out of the box, a Random Number is not necessary if we can mask it from email responses. In my specific case, I do not want non-staff to access RT. Only support agents.

Is some sort of ID number absolutely necessary in the subject field and can this be removed? I guess a more technical question is how RT tracks the email thread? Is it through the headers, or a basic primitive Subject field comparison ?

Then again… I’m thinking… a ticket number is so much easier if its relayed to support agents by caller if they decide to simply call for support.

Thoughts, ideas and suggestions welcome.

Best,
Reza.

Jeffrey Pilant wrote on 10/25/2016 2:43 PM:

Reza writes:

The use case for random IDs is quite simple. Ascending / serial number
of IDs compromises confidentiality. End users would be able to guess
how busy I could be with the amount of tickets answered. Its something
I don’t want to disclose. Almost ALL ticketing systems I have seen,
have a random arbitrary numeric or alpha-numeric ID. Any other
suggestions on how to approach not displaying an obvious number to end
users?
I don’t think I have ever seen a random number for ticket ID.
I have seen many systems that show reports of number of tickets processed per unit of time and he average answer time.
I guess I have never encountered your need before.

Seeing a series of ticket IDs may tell them how fast tickets come in, but it will not tell them how fast they are answered.

What might be easier is to create a custom field that holds a random number (maybe a GUID?). This number could then be placed in the email subject line in place of the ticket ID. Likiewise, the email reader could read the number from the subject and look up the ID. This would touch a lot fewer places in the code, and if the recipient only ever sees the email, they don’t know the real number. Meanwhile, users of the web interface see both real number and random number.

If you allow them to see the web interface, the above will not work.

A simple possible solution is to add a random amount to the ticket sequence in the code that generates ticket numbers. You will need a much larger max ticket ID since there is so much wasted space, but the random nature will obscure the number of real tickets between two given ticket IDs.

/jeff

The information contained in this e-mail is for the exclusive use of the
intended recipient(s) and may be confidential, proprietary, and/or
legally privileged. Inadvertent disclosure of this message does not
constitute a waiver of any privilege. If you receive this message in
error, please do not directly or indirectly use, print, copy, forward,
or disclose any part of this message. Please also delete this e-mail
and all copies and notify the sender. Thank you.

RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training

  • Boston - October 24-26
  • Los Angeles - Q1 2017
12

Greetings Jeff:

Thank you for your reply.

The use case for random IDs is quite simple. Ascending / serial
number of IDs compromises confidentiality. End users would be able to
guess how busy I could be with the amount of tickets answered. Its
something I don’t want to disclose. Almost ALL ticketing systems I
have seen, have a random arbitrary numeric or alpha-numeric ID. Any
other suggestions on how to approach not displaying an obvious number
to end users?

Thanks!
Reza.

The increasing ticket number is baked into the Ticket table definition:
id int(11) NOT NULL AUTO_INCREMENT,

There’s probably bits of code that assume this works this way.

Jeff

13

Reza writes:

Thinking out of the box, a Random Number is not necessary if we can mask
it from email responses. In my specific case, I do not want non-staff
to access RT. Only support agents.

Is some sort of ID number absolutely necessary in the subject field and
can this be removed? I guess a more technical question is how RT tracks
the email thread? Is it through the headers, or a basic primitive
Subject field comparison ?

Then again… I’m thinking… a ticket number is so much easier if its
relayed to support agents by caller if they decide to simply call for
support.

If you set up RT to only let privileged users add content, then even of non-staff see the numbers and email address, they will get bounced messages if they try to use it.

As far as I know, the ticket number is required in the subject line. However, if you modify the mail reader and sender to encrypt that number, you could make it harder to tell what it is.

Your use case mentioned confidentiality as a need compromised by ascending numbers. I am not sure how that can occur. Can you explain in more detail?

Alex Hall writes:

To my knowledge, yes, mail is routed through use of the subject line.
When you create a queue, you give it a tag that is used in email subjects,
and that is combined with the ticket ID to form the basis for how RT knows
which queue/ticket a given message goes to.

My understanding is that the subject holds the hostname and the ticket id. No queue name at all. If you manage to direct it to a queue, it will redirect to the queue the ticket is in instead, if it is the wrong queue.

Jeff Voskamp writes:

The increasing ticket number is baked into the Ticket table definition:
id int(11) NOT NULL AUTO_INCREMENT,

There’s probably bits of code that assume this works this way.

Actually, there is not. If you create a ticket number in the DB that skips a bunch of numbers, it will happily ignore all those skipped entries. This is actually a good thing as it can be used to merge other data bases of tickets into the system without screwing up the main system beyond jumping the sequence number.

/jeff

The information contained in this e-mail is for the exclusive use of the
intended recipient(s) and may be confidential, proprietary, and/or
legally privileged. Inadvertent disclosure of this message does not
constitute a waiver of any privilege. If you receive this message in
error, please do not directly or indirectly use, print, copy, forward,
or disclose any part of this message. Please also delete this e-mail
and all copies and notify the sender. Thank you.