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.comwrote:
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.comwrote:
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.cawrote:
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.comwrote:
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#
201303221231.
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
