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
