[rt-users] Randomizing / Masking Ticket Numbers / or Intelligently concatenating multiple numbers as ticket number.

[Alex Hall]

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:
https://docs.bestpractical.com/rt/4.4.1/RT_Config.html
> On Oct 25, 2016, at 19:51, Reza <reza.toronto at 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