I’ve been requested something quite odd: a custom field that behaves
like a SERIAL column on a database. The specific request was “a custom
field that has no duplicates and it’s always kept in sequence”.
Initially I suggested using the ticket number instead, but the user
states that according to their “process” the numbering must be gapless.
They don’t mind, and would even appreciate, if the number gets generated
automatically. I explained the fact that if there were two users
creating a new ticket, the numbering would depend on “who hits submit
first” and they’re fine with that.
Any suggestions on how to approach this?
Ernesto Hernández-Novich - Linux 2.6.18 i686 - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can’t aptitude it, it isn’t useful or doesn’t exist.
GPG Key Fingerprint = 438C 49A2 A8C7 E7D7 1500 C507 96D6 A3D6 2F4C 85E3
Ernesto,
What you are talking about is a Queue-specific reference number. Not
hard to do. For every queue that needs this, define the CF with an
appropriate name for a specific Queue (I believe in 3.8.1 you can define
Queue-level CF’s that do NOT have to be on a ticket. Maybe a name like
“Queue Reference Number” would work). Then, you define a CF to be used
for All tickets in that Queue (like “Ticket Reference Number”). You then
write a Queue-level script that examines a transaction and if the type
is a create, and it is for one of the Queues that needs this CF, then
pull the CF for THAT “Queue” and add 1 to it and then put that new
number back in the “Queue-level” CF and also insert it into the new
ticket in that queue. Hope this helps.
Kenn
LBNLOn 9/22/2008 7:14 AM, Ernesto Hernandez-Novich wrote:
I’ve been requested something quite odd: a custom field that behaves
like a SERIAL column on a database. The specific request was “a custom
field that has no duplicates and it’s always kept in sequence”.
Initially I suggested using the ticket number instead, but the user
states that according to their “process” the numbering must be gapless.
They don’t mind, and would even appreciate, if the number gets generated
automatically. I explained the fact that if there were two users
creating a new ticket, the numbering would depend on “who hits submit
first” and they’re fine with that.
Any suggestions on how to approach this?
Ernesto,
Oh, I forgot. Be sure to make the Privileges for those CF's to be
“SeeCustomField” only, since only RT will be changing them.
Kenn
LBNLOn 9/22/2008 7:14 AM, Ernesto Hernandez-Novich wrote:
I’ve been requested something quite odd: a custom field that behaves
like a SERIAL column on a database. The specific request was “a custom
field that has no duplicates and it’s always kept in sequence”.
Initially I suggested using the ticket number instead, but the user
states that according to their “process” the numbering must be gapless.
They don’t mind, and would even appreciate, if the number gets generated
automatically. I explained the fact that if there were two users
creating a new ticket, the numbering would depend on “who hits submit
first” and they’re fine with that.
Any suggestions on how to approach this?
What you are talking about is a Queue-specific reference number. Not
hard to do. For every queue that needs this, define the CF with an
appropriate name for a specific Queue (I believe in 3.8.1 you can define
Queue-level CF’s that do NOT have to be on a ticket.
I’m using 3.6 and can’t upgrade to 3.8 for the time being.
I’ve used ‘my-seq’ and ‘my-val’ as CFs. The former is supposed to hold
the last used value while the latter holds the value for the current
ticket. I created both CFs as applying to Tickets; if I understand
correctly ‘my-seq’ should be a “per queue” CF but I can’t find a way to
do that in 3.6
You then write a Queue-level script that examines a transaction and if the type
is a create, and it is for one of the Queues that needs this CF, then
pull the CF for THAT “Queue” and add 1 to it and then put that new
number back in the “Queue-level” CF and also insert it into the new
ticket in that queue. Hope this helps.
I wrote a scrip that reads my-seq, increments it and then stores it in
both fields. When I create a new ticket, both fields end up with the
same value, the problem being that ‘my-seq’ behaves like it’s undefined
for every ticket, so all my tickets end up with 1 stored in my-seq and
my-val. I think ‘my-seq’ is different for every ticket, instead of being
a singleton.
Ideas or suggestions?
Ernesto Hernández-Novich - Linux 2.6.18 i686 - Unix: Live free or die!
Geek by nature, Linux by choice, Debian of course.
If you can’t aptitude it, it isn’t useful or doesn’t exist.
GPG Key Fingerprint = 438C 49A2 A8C7 E7D7 1500 C507 96D6 A3D6 2F4C 85E3
Ernesto,
When creating a Ticket CF, one of the steps is to choose which Queues
to “Apply” it to. If it is Global, then you navigate to
Configuration->Global->Custom Fields and in that screen each CF you
check will be Global, meaning it is applied to ALL queues. I can’t
comment on how you use them or your code, as I haven’t seen it. But
that’s how to apply a CF.
Kenn
LBNLOn 11/17/2008 2:17 PM, Ernesto Hernandez-Novich wrote:
On Mon, 2008-09-22 at 10:20 -0700, Kenneth Crocker wrote:
What you are talking about is a Queue-specific reference number. Not
hard to do. For every queue that needs this, define the CF with an
appropriate name for a specific Queue (I believe in 3.8.1 you can define
Queue-level CF’s that do NOT have to be on a ticket.
I’m using 3.6 and can’t upgrade to 3.8 for the time being.
I’ve used ‘my-seq’ and ‘my-val’ as CFs. The former is supposed to hold
the last used value while the latter holds the value for the current
ticket. I created both CFs as applying to Tickets; if I understand
correctly ‘my-seq’ should be a “per queue” CF but I can’t find a way to
do that in 3.6
You then write a Queue-level script that examines a transaction and if the type
is a create, and it is for one of the Queues that needs this CF, then
pull the CF for THAT “Queue” and add 1 to it and then put that new
number back in the “Queue-level” CF and also insert it into the new
ticket in that queue. Hope this helps.
I wrote a scrip that reads my-seq, increments it and then stores it in
both fields. When I create a new ticket, both fields end up with the
same value, the problem being that ‘my-seq’ behaves like it’s undefined
for every ticket, so all my tickets end up with 1 stored in my-seq and
my-val. I think ‘my-seq’ is different for every ticket, instead of being
a singleton.
Ideas or suggestions?