While migrating our existing RT customisation from V3.6.5 to
(currently) V4.0.1 and adding some enhancements, I’ve encountered a
problem: I need to be able to search for, and display, the gecos values
from user entries (primarily for ticket owners and requestors), which in
existing customisation will hold our centrally allocated username for the
user, if one exists and can be matched to the user. [The RT username may
(but won’t always) contain it, so I can’t just use the username.]
Since it wasn’t offered by the search builder menus, I tried using the
advanced search page to modify known-valid queries like
Requestor.EmailAddress LIKE 'jml4@hermes.cam.ac.uk'
created via the menus into e.g. Owner.Gecos LIKE ‘jml4’. That failed
initially, until I noticed entries in the log reporting “Invalid watcher
subfield: ‘Gecos’ at /opt/rt4/sbin/…/lib/RT/Tickets.pm line 905.”. That
prompted me to add gecos to the definition of FIELD_METADATA in a local
copy of Tickets.pm.
That allowed the “.gecos” to be passed through to the search and it found
a plausible-looking set of results, but I couldn’t find any way to get the
gecos value included in the search results. I found mailing list
discussions suggesting that I needed to create
local/html/Elements/RT__Ticket/ColumnMap, based on the original RT
versions but with some definitions added (based on existing entries).
However, that didn’t solve the problem. I also found the %FIELD_METADATA
definition in Tickets.pm which looked like it may be relevant, but not
making what seemed like the obvious change there made no difference to the
results.
Any suggestions of where else I may need to make changes, or pointers to
existing instructions, would be very helpful. I suspect I may be fairly
close to getting it working, but with one or more critical pieces of the
puzzle still missing.
John Line
John Line - web development, University of Cambridge Computing Service
That allowed the “.gecos” to be passed through to the search and it
found a plausible-looking set of results, but I couldn’t find any
way to get the gecos value included in the search results. I found
mailing list discussions suggesting that I needed to create
local/html/Elements/RT__Ticket/ColumnMap, based on the original RT
versions but with some definitions added (based on existing
entries). However, that didn’t solve the problem. I also found the
%FIELD_METADATA definition in Tickets.pm which looked like it may be
relevant, but not making what seemed like the obvious change there
made no difference to the results.
Any suggestions of where else I may need to make changes, or
pointers to existing instructions, would be very helpful. I suspect
I may be fairly close to getting it working, but with one or more
critical pieces of the puzzle still missing.
You don’t want to make whole local copies of ColumnMap, you want to
use the callback in there to blow in a RequestorGecos key that returns
the relevant data. Similarly, you can use the callback in
Elements/BuildFormatString to add that RequestorGecos column so users
can select it. You can always test a field you added via ColumnMap by
using the advanced editor and editing the format before you deal with
adding it to the list of strings.
-kevin
That allowed the “.gecos” to be passed through to the search and it
found a plausible-looking set of results, but I couldn’t find any
way to get the gecos value included in the search results. I found
mailing list discussions suggesting that I needed to create
local/html/Elements/RT__Ticket/ColumnMap, based on the original RT
versions but with some definitions added (based on existing
entries). However, that didn’t solve the problem. I also found the
%FIELD_METADATA definition in Tickets.pm which looked like it may be
relevant, but not making what seemed like the obvious change there
made no difference to the results.
Any suggestions of where else I may need to make changes, or
pointers to existing instructions, would be very helpful. I suspect
I may be fairly close to getting it working, but with one or more
critical pieces of the puzzle still missing.
You don’t want to make whole local copies of ColumnMap, you want to
use the callback in there to blow in a RequestorGecos key that returns
the relevant data. Similarly, you can use the callback in
Elements/BuildFormatString to add that RequestorGecos column so users
can select it. You can always test a field you added via ColumnMap by
using the advanced editor and editing the format before you deal with
adding it to the list of strings.
Thank you for those suggestions.
I hadn’t noticed that there were relevant callbacks that I should use,
rather than making local copies of those files, and I’ll change to the
suggested approach - much better. It sounds like I’m close to doing what’s
needed, as I thought, and just need to track down the details I’m missing
or have currently got wrong.
John
John Line - web development, University of Cambridge Computing Service