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