Help with Custom Field of the "User" type?

Greetings & Salutations and a Happy New Years to all in the RT Community!

I could use some advice on the following if any of you wouldn’t mind, perhaps there’s some folks who are not too hungover to lend a hand? :slight_smile:

We have LDAP/Active Directory integration and that works great.

I’d like to get the Requester’s Manager into the ticket somehow so it’s easy to see…

I created a custom field of the type “User” and I’m stuck trying to figure out how to add it to the “People” section.

I’d imagine once I update the UI Template to add a CF to People then it would just be a matter of creating a scrip to do the job of updating the CF - On Create?

Or is there a smoother way of doing this with the data model that would hook directly into the user object? (So that we don’t have to worry about updating again if the requester is changed or if the user manager gets updated and that would be updated from the LDAP Import job we have) - if the LDAP Import job runs and if the user object already has a link from Requester --to-> User–to-> CF.Manager then if the LDAP import happens couldn’t that automatically be updated if there’s a referential link? I guess I’m thinking SQL but wondering if there’s a way to do this with custom fields since I see the custom field has a choice of living in the user object and I’m wondering if that integrity already exists?

Any help you could send my way is greatly appreciated as always.

Happy 2024!

You an quite happily have custom fields attached to user objects in RT.

To display your user custom field you could use callbacks. For example there’s a callback called Modify on /Elements/ShowUser that includes a display parameter with the details that it is about to display for that user. I’ve used this before to add extra information to the user displays. As an example, you’d want code in /opt/rt5/local/html/Callbacks/YourNameHere/Elements/ShowUser/Modify that was something like this:

$User => undef
$Address => undef
$display => undef;
my $manager = $user->FirstCustomFieldValue('Manager');
if($manager) {
  $$display .= "( Looked after by $manager )";

ISTR the AD has an attribute for a user’s manager, so if you’re using that in your AD (not all organisations do of course) you could potentially pull that into your user CFs from the LDAP Import. This blog post I made about using User CFs might help. It wasn’t dealing with managers, but it might put you on the right track.

Another aproach might be to use a Custom Role, so the manager can be notified via email by scrips.

Anyway, the searching, setting and update of this role on any change is still a scrip(t)ing thing.

I made a little (very little) progress w/this.

By adding UserCF.Manager to my $LDAPMapping I’m able to get the manager on import which is fine except for how the data is returned from AD.

AD returns an entire CN for the manager so this is what I get back -

Any suggestions on how to parse the field and either put it back into this CF or another CF.

I started to look at “Call Backs”. If I want to add User CF to the ticket meta data when browsing the ticket summary (Ticket/Display.html) would this be the correct path?


I took a read on CustomizingWithCallbacks - Request Tracker Wiki but it looks like this hasn’t been updated since RT 3.8 → 4.2 days at most.

If I wanted to search all the code for what the most generic stringv that would show me all call backs on current version of RT would I be looking for: $m->callback ?

If I look in Display.html this is what I get back, but what is this actually telling me? How does this relate to the Callbacks directory for writing custom Callbacks?

[user@rt Ticket]# grep callback Display.html
% $m->callback(CallbackName => 'BeforeActionList', %ARGS, Actions => \@Actions, ARGSRef => \%ARGS, Ticket => $TicketObj);
% $m->callback( %ARGS, Ticket => $TicketObj, Transactions => $transactions, Attachments => $attachments, CallbackName => 'BeforeShowSummary' );
% $m->callback( Ticket => $TicketObj, %ARGS, Transactions => $transactions, Attachments => $attachments, CallbackName => 'BeforeShowHistory' );
% $m->callback( %ARGS,
$m->callback( TicketObj => $TicketObj, ARGSRef => \%ARGS, CallbackName => 'Initial' );
        $m->callback( CallbackName => 'BeforeProcessArguments',
        $m->callback(CallbackName => 'ProcessArguments',