| Stefan Ritt wrote: |
|
| Barend wrote: |
|
I have tried to use the "Ticket ID" approach and with each new entry this Ticket ID is indeed increased automatically...
But when the last Entry (with the highest Ticket ID i.e. ID-0009) is move to another Logbook, the Ticket ID in the next new entry will be "ID-0009" again (based upon the last previous entry "ID-0008").
So this appraoch will also re-produce duplicate Ticket IDs.
Is it possible to have the Ticket ID preset with value based upon the Date & Time of the entry? Instead of holding a Date/Time format, use a calculated numeric format?
This way, each new entry will have a truely unique Ticket ID.
Thanks & Regards, Barend
|
Why do you move the last ticket in a logbook at all? The move functionality was more meant as an archive option, where you can archive old entries on an annual basis or so. If you just want to "close" a ticket for example, an attribute "Status" with options "open" and "close" will do it. Together with a quick filter you can easily show only open entries in an logbook that way.
Stefan
|
In the documentation:
>In addition to the #'s one may specify format specifiers which are passed to the strftime function. This allows to create tags wich contain the current year, month >and so on. Once the date part of the attribute changes, the index restarts from one. The statement
>Subst Number = XYZ-%Y-%b-###
>results in automatically created attributes
"Number"
of the form
>XYZ-2005-Oct-001
>XYZ-2005-Oct-002
>XYZ-2005-Oct-003
A little playing around with the %[Alpha character] s of strftime probably will generate a format that will suit your requirement - to the second if needs be.
For example I've checked that
Preset Ticket = T%y%m%d%H%M%S#
Generates a ticket number T1302061705141 at that particular moment.
Unfortuately for this to work, you have to have the "#" suffix, which will add a trailling "1" at the end of every ticket (unless you generate two new entries within a second of each other). There are plenty of ways to format all this available in strftime, and unless you keep changing the clock on your computer (which I am guilty of), the ticket numbers can be as unique as you care to make them, and sequentially increasing.
Having said that, I share the view with Stefan that the problem is moving a thread or entry to another logbook rather too early. Personally I keep a thread in the current log book for at least a month after it is "closed" before I move it, although partly that's because sometimes these threads come back to life. Although also because I ran into the same issue (moving the latest entry and finding the ID duplicated), and, realising the problem, then took the "wait" option to solve it.. |