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

[Reza]

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