Use user customfield value in scrip

Hi,
I do not know what I am missing. I am trying to use an “Out of Office” user customfield value in a scrip to send a notification about that status when someone is given a ticket when they have it set. I created a global user CF and the users can set it, but when I try to read the value in a scrip, it only succeeds for highly privileged accounts. Even though I have given Privileged users the ability to see the customfield, the do not appear to be able to read another user’s value if they are the actor. Is this a know problem with user CFs? Alternatively, does anyone have an idea about how to make that process work?

Regards,
Ken

I believe scrips run on the context of the system user (unless you load objects in a different context) so I’d expect the issue not to be related to user rights

Hi,

Thank you for your reply. I had seen that behavior but I am mystified about why the scrip is only firing for some accounts. It is pretty simple. Am I missing something:

my $Ticket = $self->TicketObj;

return(0) unless ($Transaction->IsInbound);
return(0) unless ($Transaction->Type eq 'Correspond' or $Transaction->Type eq 'Create' or $Transaction->Field eq 'Owner');

#
# The requestor made the update so check if the owner is 'Out of Office'.

# Create User Object and Load the ticket owner.
my $UserObj = RT::User->new( $RT::SystemUser );
$UserObj->Load( $Ticket->Owner );

if ($UserObj->FirstCustomFieldValue(486)) {
  # We only get here is the ticket owner has set the 'Out of Office' customfield
  # so send the auto-reply.
  return (1);
}

return (0);
type or paste code here

I’d print some of the values coming back from $UserObj->FirstCustomFieldValue(486) to confirm what you’re seeing. Also you can get the owner object like this i believe:

my $UserObj = $Ticket->OwnerObj;

I think I’d also get the CF by name rather than a hard coded ID. That may cause problems down the road, even if it isn’t necessarily directly related to the problem here.

Hi,
I have tended to the ID after I spent a long time debugging a problem caused by CFs with the same name. :frowning:
Regards,
Ken