Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: Request Tracker: Users

(Very) Low-level CF question

 

 

Request Tracker users RSS feed   Index | Next | Previous | View Threaded


joe.casadonte at oracle

Feb 29, 2008, 10:14 AM

Post #1 of 5 (1096 views)
Permalink
(Very) Low-level CF question

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 [at] oracle

========== ==========
== The statements and opinions expressed here are my own and do not ==
== necessarily represent those of Oracle Corporation. ==
========== ==========
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales [at] bestpractical


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


KFCrocker at lbl

Feb 29, 2008, 10:50 AM

Post #2 of 5 (1010 views)
Permalink
Re: (Very) Low-level CF question [In reply to]

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
LBNL

On 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!
>
>

_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales [at] bestpractical


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


joe.casadonte at oracle

Feb 29, 2008, 11:21 AM

Post #3 of 5 (1017 views)
Permalink
Re: (Very) Low-level CF question [In reply to]

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.

--
Regards,


joe
Joe Casadonte
joe.casadonte [at] oracle

========== ==========
== The statements and opinions expressed here are my own and do not ==
== necessarily represent those of Oracle Corporation. ==
========== ==========
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales [at] bestpractical


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


KFCrocker at lbl

Feb 29, 2008, 11:54 AM

Post #4 of 5 (1003 views)
Permalink
Re: (Very) Low-level CF question [In reply to]

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
LBNL

On 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.
>

_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales [at] bestpractical


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com


joe.casadonte at oracle

Mar 3, 2008, 10:21 AM

Post #5 of 5 (1005 views)
Permalink
Re: Sub-Categories (was: Re: (Very) Low-level CF question) [In reply to]

On 2/29/2008 2:54 PM, Kenneth Crocker wrote:

> 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 [at] oracle

========== ==========
== The statements and opinions expressed here are my own and do not ==
== necessarily represent those of Oracle Corporation. ==
========== ==========
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users

Community help: http://wiki.bestpractical.com
Commercial support: sales [at] bestpractical


Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Request Tracker users RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact Gossamer Threads
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.