Assume:
- Ticket #1 is in the Queue Q1
- Custom Field #1, named Foo, applies to all queues
- Foo’s value for Ticket #1 is ‘Global’
A query results listing that includes CustomField.{Foo} will properly
show ‘Global’ for the value of Foo.
Change the assumptions:
- Ticket #1 is in the Queue Q1
- Custom Field #1, named Foo, applies only to Q1
- Foo’s value for Ticket #1 is ‘Specific’
A query results listing that includes CustomField.{Foo} will properly
show ‘Specific’ for the value of Foo.
Now, change the assumptions once more:
- Ticket #1 is in the Queue Q1
- Custom Field #1, named Foo, applies to all queues
- Custom Field #2, also named Foo, applies only to Q1
- Foo’s (#1) value for Ticket #1 is ‘Global’
- Foo’s (#2) value for Ticket #1 is ‘Specific’
A query results listing that includes CustomField.{Foo} will show
‘Global’ for the value of Foo.
Where is it determined which CF value to show? I’m obviously asking
because I want the queue-specific one shown, not the global one. I’m
pretty comfortable roaming around the source, but once I get to the
query and query results level, I just kind of get lost. I suspect much
of it happens in some non-RT module (DBI or DBIx::SearchBuilder?) but I
can’t help thinking that the CustomField stuff is very RT-specific, and
so has to be handled somewhere inside of RT.
Thanks!
Regards,
joe
Joe Casadonte
joe.casadonte@oracle.com
========== ==========
== The statements and opinions expressed here are my own and do not ==
== necessarily represent those of Oracle Corporation. ==
========== ==========
Joe,
Hypothetical situations could involve endless debate, especially if
they are based on an unrealistic scenario. Not to offend nor sound too
incredulous, but why would anyone name ANY custom fields the same names
for different applications/uses? Why not just prefix the “queue-based”
Custom field with the queue name “xxxxxx-Foo”? Sure would stop a lot of
confusion and you wouldn’t need to be asking the question.
Kenn
LBNLOn 2/29/2008 10:14 AM, Joe Casadonte wrote:
Assume:
- Ticket #1 is in the Queue Q1
- Custom Field #1, named Foo, applies to all queues
- Foo’s value for Ticket #1 is ‘Global’
A query results listing that includes CustomField.{Foo} will properly
show ‘Global’ for the value of Foo.
Change the assumptions:
- Ticket #1 is in the Queue Q1
- Custom Field #1, named Foo, applies only to Q1
- Foo’s value for Ticket #1 is ‘Specific’
A query results listing that includes CustomField.{Foo} will properly
show ‘Specific’ for the value of Foo.
Now, change the assumptions once more:
- Ticket #1 is in the Queue Q1
- Custom Field #1, named Foo, applies to all queues
- Custom Field #2, also named Foo, applies only to Q1
- Foo’s (#1) value for Ticket #1 is ‘Global’
- Foo’s (#2) value for Ticket #1 is ‘Specific’
A query results listing that includes CustomField.{Foo} will show
‘Global’ for the value of Foo.
Where is it determined which CF value to show? I’m obviously asking
because I want the queue-specific one shown, not the global one. I’m
pretty comfortable roaming around the source, but once I get to the
query and query results level, I just kind of get lost. I suspect much
of it happens in some non-RT module (DBI or DBIx::SearchBuilder?) but I
can’t help thinking that the CustomField stuff is very RT-specific, and
so has to be handled somewhere inside of RT.
Thanks!
Hypothetical situations could involve endless debate, especially if
they are based on an unrealistic scenario. Not to offend nor sound too
incredulous, but why would anyone name ANY custom fields the same names
for different applications/uses? Why not just prefix the “queue-based”
Custom field with the queue name “xxxxxx-Foo”? Sure would stop a lot of
confusion and you wouldn’t need to be asking the question.
It’s actually for a very practical purpose – having a commonly named
CF, with queue-specific values. In my case, I have a SubCategory CF,
which exists in each queue, but each queue has its own values. It works
great, really.
The hitch is: I want to be able to choose the SubCategory CF via the
list box in the Tickets search form as one of the output columns. The
only way to do that without first choosing a queue is to have a global
CF with the same name (and I’ve already taken care of hiding the global
field from view on ticket creation and viewing the ticket).
I can get around the need for all of this by going to the Advanced tab
and typing in “CustomField.{SubCategory}” as one of the results column,
but I don’t want to have to explain over and over again how to do that
to my user base.
Once I get this last piece working, I’ll be writing it up for the Wiki.
Regards,
joe
Joe Casadonte
joe.casadonte@oracle.com
========== ==========
== The statements and opinions expressed here are my own and do not ==
== necessarily represent those of Oracle Corporation. ==
========== ==========
Joe,
You know, I do have a few Custom Fields that serve the same purpose,
but would have different values per queue. I didn’t know we had
sub-categories that worked. I’d love to see your results. Thanks.
Kenn
LBNLOn 2/29/2008 11:21 AM, Joe Casadonte wrote:
On 2/29/2008 1:50 PM, Kenneth Crocker wrote:
Hypothetical situations could involve endless debate, especially
if they are based on an unrealistic scenario. Not to offend nor sound
too incredulous, but why would anyone name ANY custom fields the same
names for different applications/uses? Why not just prefix the
“queue-based” Custom field with the queue name “xxxxxx-Foo”? Sure
would stop a lot of confusion and you wouldn’t need to be asking the
question.
It’s actually for a very practical purpose – having a commonly named
CF, with queue-specific values. In my case, I have a SubCategory CF,
which exists in each queue, but each queue has its own values. It works
great, really.
The hitch is: I want to be able to choose the SubCategory CF via the
list box in the Tickets search form as one of the output columns. The
only way to do that without first choosing a queue is to have a global
CF with the same name (and I’ve already taken care of hiding the global
field from view on ticket creation and viewing the ticket).
I can get around the need for all of this by going to the Advanced tab
and typing in “CustomField.{SubCategory}” as one of the results column,
but I don’t want to have to explain over and over again how to do that
to my user base.
Once I get this last piece working, I’ll be writing it up for the Wiki.
You know, I do have a few Custom Fields that serve the same purpose,
but would have different values per queue. I didn’t know we had
sub-categories that worked. I’d love to see your results. Thanks.
For those interested, I have this (sub-categories) working to a large
extent. I even have them enabled for Quick Create (what a PITA that
was, as I don’t know JavaScript). I still need to handle them on the
Basics tab when editing a ticket, and then I’ll write up a big How-To
and post it to the wiki. In the end, there’s only small bits of code
added here and there, but it was a long road getting there…
Regards,
joe
Joe Casadonte
joe.casadonte@oracle.com
========== ==========
== The statements and opinions expressed here are my own and do not ==
== necessarily represent those of Oracle Corporation. ==
========== ==========