[rt-users] Greetings from a New RT user in Toronto.

Alex Hall ahall at autodist.com
Tue Oct 25 16:44:16 EDT 2016

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:
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 at bayer.com>

> 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 at autodist.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20161025/d0c8067d/attachment.html>

More information about the rt-users mailing list