RT 3.4 feature request: Custom Field callbacks

The new custom field system is great but…

I need a Select custom field that has different values based
on the queue. The obvious choice is to have different custom
fields for each queue. The problem is that for reporting
this sometimes doesn’t make sense.

For example, if we have two queues, one for Unix tickets and
one for Windows tickets, we might want to have a custom field
OS with different options for each queue. Two different CFs
could to the job, but when reporting this looks really ugly
because we have two different OS columns.

What I propose is that /Elements/EditCustomField* has a
callback mechanism such that if a callback with the same
name as the custom field exists, the callback handle all
HTML generation for that CF. Then sites could implement
customized CFs for this and other situations.

My first thought on implementation is the a $m->scomp
is added at the top of each /Elements/EditCustomField* and
if it returns content of length > 0 then no other HTML
is generated. If no content is returned then the default
action applies.

Comments?

-Todd

What I propose is that /Elements/EditCustomField* has a
callback mechanism such that if a callback with the same
name as the custom field exists, the callback handle all
HTML generation for that CF. Then sites could implement
customized CFs for this and other situations.

I’d actually recommend doing this at the API level. But I’m not
currently comfortable with changing this for 3.4.

What I propose is that /Elements/EditCustomField* has a
callback mechanism such that if a callback with the same
name as the custom field exists, the callback handle all
HTML generation for that CF. Then sites could implement
customized CFs for this and other situations.

I’d actually recommend doing this at the API level. But I’m not
currently comfortable with changing this for 3.4.

I agree, but the ease of implementation at the interface level
would be a good interim solution until the API is extended.

-Todd