Mailing List Archive

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
>

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
https://rt-wiki.bestpractical.com/wiki/TemplateSnippets

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

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. :) 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:
> 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
> <http://rt-wiki.bestpractical.com>) has a couple helpful pages on
> templates, such as
> https://rt-wiki.bestpractical.com/wiki/TemplateSnippets
>
> 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 <mailto: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
> <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
> <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
> <https://bestpractical.com/training>
> * Boston - October 24-26
> * Los Angeles - Q1 2017
>
>
>
>
> --
> Alex Hall
> Automatic Distributors, IT department
> ahall@autodist.com <mailto:ahall@autodist.com>

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 :)

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?

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
>

Reza writes:
>The last 24-48 hrs has been an amazing learning experience. I feel
>as-if I can do Kung Fu now :)
>
> 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.
________________________________________________________________________
---------
RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017

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:
> Reza writes:
>> The last 24-48 hrs has been an amazing learning experience. I feel
>> as-if I can do Kung Fu now :)
>>
>> 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.
> ________________________________________________________________________
> ---------
> 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

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

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 26*26*3
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

On 25/10/16 12:18 PM, Reza wrote:
> 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
---------
RT 4.4 and RTIR training sessions, and a new workshop day! https://bestpractical.com/training
* Boston - October 24-26
* Los Angeles - Q1 2017