Hi,
>> If I read you correctly the use for this 'calculated' field would be to
have it in reporting, so Excel can handle your CSV files easier, right?
Correct.
>> You *could* create an event module that sets a dynamic field at ticket
create time, this would work, but it requires some marginal development.
Thanks for this good suggestion. I looked at event modules a while back and
re-thinking about it now, it sounds like they could 100% solve my problem.
>> We can also try to fix it in the OTRS code, my proposal would be to
include a second ticket number field that contains a 'full' number such as
"Ticket# 2013032710001234". The other, 'old' ticket number field should
still be available so we don't 'break' workflows for people who depend on
this field in their workflows.
It would be good to have this available. Our customers would still complain
about having to strip "Ticket#" after pasting the value from Excel into the
search box from OTRS. Even so, it would be a good option to have until I
can write an event module and I would be thankful for it.
Other possible solutions, I just list them for the lucky case when they are
already on your roadmap:
- Ability to set SystemID to non-digits (requested elsewere for other
reasons, it would also solve my problem)
- Ability to specify the values from SearchCSVData as simple
expressions instead of Ticket data fields (e.g. instead of "TicketNumber",
being able to say "=TEXT($TicketNumber), 0)" would magically solve my
problem)
Thanks
On Wed, Mar 27, 2013 at 10:28 AM, Michiel Beijen
<michiel.bei...@gmail.com>wrote:
> Hi Bogdan,
>
> If I read you correctly the use for this 'calculated' field would be to
> have it in reporting, so Excel can handle your CSV files easier, right?
>
> You *could* create an event module that sets a dynamic field at ticket
> create time, this would work, but it requires some marginal development.
>
> We can also try to fix it in the OTRS code, my proposal would be to
> include a second ticket number field that contains a 'full' number such as
> "Ticket# 2013032710001234". The other, 'old' ticket number field should
> still be available so we don't 'break' workflows for people who depend on
> this field in their workflows.
>
> What do you think?
> --
> Mike
> On Tue, Mar 26, 2013 at 7:30 PM, Bogdan Iosif <bogdan.io...@gmail.com>wrote:
>
>> 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 <had...@ualberta.ca>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
>>> <bogdan.io...@gmail.com>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
>>>
>>
>>
>> _______________________________________________
>> 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
>
_______________________________________________
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
