Re: [dev] How can I add a new, computed, data field to Ticket?

It would but be a solution but it's the same kind as the one already mentioned in initial email's "Explored solutions" section (The one shortening the SystemID leading to a TicketNumber of only 15 chars). The problem with both solutions is that the TicketNumber would remain scrambled when the CSV is opened in Excel because it would be auto formatted in scientific notation and it would also require a massive update in the database for my existing 20.000 tickets (these are the ones actually useful in searches right now and for quite a time to come). I've already found how to avoid the problem in Excel, I just need a calculated ticket data field whose value should be "=TEXT($TicketNumber, 0)". The = tells Excel to treat it as a formula and the TEXT formula does the rest. Unfortunately, I don't have the time to discover how to add this field to Ticket.pm. Frankly I don't even know if Perl supports property data fields with getters but that's another story. /Thanks for the reply On Tue, Mar 26, 2013 at 7:46 PM, Lukasz Hadyna wrote:

Hi Bogdan,

Would shortening the number to 8 digits provide an adequate solution as well? It is possible to change the Ticket Number generator in OTRS's configuration. You're currently using DateChecksum method to generate your Ticket numbers and the alternative Autoincrement creates numbers half the size.

The option to change how ticket numbers are generated can be found in Core::Ticket under Ticket::NumberGenerator.

Regards, Lukasz Hadyna

On Fri, Mar 22, 2013 at 10:24 AM, Bogdan Iosif wrote:

...

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

_______________________________________________ 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