Hi list, I have a problem that I think can't be solved without writing some code. I would like some minimal guidance on how to do this in an elegant manner. I'll explain mainly the technical side of the problem but, if you are curious, you can also read the functional side at the end.
Technical aspect: I need to have a ticket field (not dynamic, a field like TicketNumber, Queue, etc.) that exposes the ticket number as something other than a pure number. For example, I would like to have it as a string such as "Ticket# 2013032210000231". I also need this field to be technically identical with the TicketNumber field so that I can add it to Ticket::Frontend::CustomerTicketSearch###SearchCSVData in hope that it will show up in the search results exported to CSV from the customer interface. Can I do this as an extension to the existing OTRS code, that would be safe across future upgrades? If so, please point me towards an example that would help me understand how to do it. *Please* understand that I don't want to change any of the files that come with OTRS. Thanks, Bogdan Functional aspect: When the CSV file produced by the search function from the customer interface is opened in Excel, the column containing the TicketNumber will have its last digit truncated. This is because the column is detected as a number and, by default, it has 16 digits (e.g. 2013032210000231). Excel is limited to 15 digits for numbers so the last digit is truncated. Opening the CSV search results in Excel is critically important for our customers. They need to use the ticket number value from Excel and input it back in OTRS. Because Excel drops that last digit, this critically important usage pattern becomes impossible. In addition, because the column is interpreted as a large number, Excel obfuscates it by representing it scientifically (exponential notation). Ideally, the column should be understood as text so that they could copy it from Excel and paste it in their customer interface. However, because of how Excel's CSV import works, this is not possible. Explored solutions: - Change SystemID to a letter. It would solve the problem but, unfortunately, OTRS insists for the SystemID to be a number - Change SystemID to a single digit. It would solve the loss of information when importing in Excel but not the exponential notation inconvenience. It would also entail major database changes to update all ticket number and I'm uncomfortable doing it right now as I can't account for all the possible negative side-effects (will do it if all else fails though). - Create a new ticket number generator. Overkill for this problem. I prefer to fall back to the previous solution.
_______________________________________________ OTRS mailing list: dev - Webpage: http://otrs.org/ Archive: http://lists.otrs.org/pipermail/dev To unsubscribe: http://lists.otrs.org/cgi-bin/listinfo/dev
