Cannot display requestor or requestors attributes in rt CLI when specifying fields

Hi all,

First post so apologies in advance if I miss something. Long time user, but have only just started playing with the CLI. What I’m trying to do is setup a bash script that uses the CLI to export data from RT on a regular basis.

Environment details:

  • RT 3.8.7
  • Ubuntu x64 2.6.32-26-server
  • Apache/2.2.14
  • Perl v5.10.1 (*) built for x86_64-linux-gnu-thread-multi
  • Modules / Plugins:
    o RTFM
    o RTx::EmailCompletion
    o RT::Extension::MergeUsers
  • MySQL 5.1.41-3
    Sorry not sure what versions of these modules & plugins.

Originally I had another problem which is that I couldn’t get a bash script to execute an RT cli, pass in variables, and email the results as an attachment to a specified address but that’s now sorted… except that if I cannot get the email address associated with a ticket requestor.

To illustrate:
rt> show ticket/71900
X-Queue: helpdesk
rt>

but if I try and get the requestor email (which is me):

rt> list “id = 71900” -f id,requestor,requestors,subject
id Subject Requestors
71900 New Service Call - Default Wallpaper too large ARRAY(0x7fbf6db32a58)

rt> list “id = 71900” -f id,requestor,subject
id Subject
71900 New Service Call - Default Wallpaper too large

rt> list “id = 71900” -f id,requestors,subject
id Subject Requestors
71900 New Service Call - Default Wallpaper too large ARRAY(0x7fbf6dd46788)

So… the “requestors” field returns “ARRAY(0x…)” whereas the “requestor” field is just ignored. The term “Requestor” is used if you run:

rt list “id = 71900”

but the results are obscured because they’re too long to fit on the screen properly.

If I use “from” instead (because this is what the “show ticket/71900” calls it… I get the same result as if I’d used “requestor”. In fact if I use any random non-reserved word in there it’s ignored, which leads me to suspect that “requestor” is not actually what I’m looking for. I originally used “requestors” because this is what the export spreadsheet function from the GUI calls the field - and indeed if you export a spreadsheet from a list of tickets in the GUI it correctly exports the email address of the requestor (but ignores the settings relating to which fields to export - it exports every field in it’s own order that does not match the order of the column headings, but that’s a separate issue…).

I’ve also tried things like “requestors.email” but this returns:

rt> list “id = 71900” -f id,requestors.email,subject
rt: list: No valid field list in ‘-f id,requestors.email,subject’.
rt: For help, run ‘rt help list’.
rt: For help, run ‘rt help ticket’.
rt>
If I try to use the CC or AdminCC fields from the cli they experience the same issue.

Does anyone have any ideas on things I could try? Alternatively, is there some nifty way that RT can be configured to produce a friendly CSV style file and email it on a regular schedule including custom field data? If anyone’s interested what I’ve got so far is attached below.

I started looking at doing this direct from a database but my head started hurting - for example there’s no simple way of returning the current requestor - you have to traverse all relevant transactions and work it out that way (and if there is > 1 requestor make a decision about which one to choose). So if you have a db script that will do this then I’ll gratefully look & test it but I probably won’t venture down the path of writing it myself just now…

Regards,

Chris Herrmann
Far Edge Technology

p. 02 84251400
m. 0403 393309
http://www.faredge.com.au

startmonth=date +%m; export startmonth
startyear=date +%Y; export startyear
endyear=$startyear; export endyear
friendlymonth=date +%b
reportperiod=$friendlymonth" "$startyear
if [ $startmonth = 12 ];then
endyear=$(($startyear+1))
endmonth=1
else
endyear=$startyear
endmonth=$(($startmonth+1))
fi
export endyear
startdate=1/$startmonth/$startyear ; export startdate
enddate=1/$endmonth/$endyear ; export enddate
touch blankreport #doing this because Mutt expects data to be in the message

RTUSER=reportinguser; export RTUSER
RTSERVER=http://myrtserver/; export RTSERVER
RTPASSWD=reportinguserpass; export RTPASSWD
rt list “queue = ‘myrtqueue’ and created > ‘$startdate’ and created < ‘$enddate’ and (status !=‘rejected’ AND status != ‘deleted’)” -f id,subject,requestor,created,CF-firstname,CF-surname,CF-phone,CF-addressline1,CF-addressline2,CF-state,CF-postcode,CF-typeofdevice,CF-dateofpurchase,CF-ReceiptNo,CF-tickettype > /tmp/$startyear$startmonth"CallReport.txt"
mutt -s “Monthly Queue Results” -a /tmp/$startyear$startmonth"MontlyCallReport.txt" – chrisdotherrrmannatfaredgedotcomdotau < blankreport
rm -f blankreport
rm -f /tmp/$startyear$startmonth"MonthlyCallReport.txt"

Originally I had another problem which is that I couldn’t get a bash
script to execute an RT cli, pass in variables, and email the results
as an attachment to a specified address but that’s now sorted…
except that if I cannot get the email address associated with a ticket
requestor.

It’s a bug. Quick patch:

diff --git a/share/html/REST/1.0/Forms/ticket/default b/share/html/REST/1.0/Forms/ticket/default
index 0d403b2…280ab55 100755
— a/share/html/REST/1.0/Forms/ticket/default
+++ b/share/html/REST/1.0/Forms/ticket/default
@@ -202,7 +202,7 @@ if (!keys(%data)) {

 foreach $key (@people) {
     next unless (!%$fields || (exists $fields->{lc $key}));
  •    push @data, [ $key => [ $ticket->$key->MemberEmailAddresses ] ];
    
  •    push @data, [ $key => $ticket->$key->MemberEmailAddressesAsString ];
    

    }

    $time = new RT::Date ($session{CurrentUser});

Feel free to open a bug to rt-bugs@bestpractical.com for this :slight_smile:

and there is no way to get Requestors.Name currently … patches are welcome :wink:

Hi Emmanuel,

Thanks, the patch doesn’t apply:

root@sirius:/usr/share/request-tracker3.8# patch -p2 < /tmp/thepatch
patching file html/REST/1.0/Forms/ticket/default
patch: **** malformed patch at line 14: $time = new RT::Date ($session{Curr entUser});

root@sirius:/tmp# cat thepatch
diff --git a/share/html/REST/1.0/Forms/ticket/default b/share/html/REST/1.0/Forms/ticket/default
index 0d403b2…280ab55 100755
— a/share/html/REST/1.0/Forms/ticket/default
+++ b/share/html/REST/1.0/Forms/ticket/default
@@ -202,7 +202,7 @@ if (!keys(%data)) {

 foreach $key (@people) {
     next unless (!%$fields || (exists $fields->{lc $key}));
  •    push @data, [ $key => [ $ticket->$key->MemberEmailAddresses ] ];
    
  •    push @data, [ $key =>
    
  • $ticket->$key->MemberEmailAddressesAsString ];
    }

    $time = new RT::Date ($session{CurrentUser});

root@sirius:/tmp#

This occurs twice in that file (approx. line 202 & line 310). The other matching text you’ve flagged there narrows it down to the block @ line 202…

Ok, found it:

205: push @data, [ $key => [ $ticket->$key->MemberEmailAddresses ] ];

To

    push @data, [ $key =>  $ticket->$key->MemberEmailAddresses  ];

and it’s now working… yay! I need to check a few other things in our staging environment first, and then will deploy to prod.

Dominic: Yes, agree but I need a way of making this work right now, so for the moment I’ll update our internal documentation around deploying upgrades for RT and a note to check this functionality. We have several other systems that depend upon RT (like billing for example) so we don’t tend to upgrade RT very often, only when we’re looking for some significant new functionality.

What’s the protocol for me to post this up as a suggestion for this fix to become incorporated back into the main 3.8 code base so that future releases will include it? (assuming that this isn’t going to break some other piece of critical functionality!).

Something weird I did notice (unrelated I think):

rt> list “id = 68667” -f id,requestors,subject
id Subject Requestors
68667 My testing ticket chris@noemail.com

Notice that the order of the requestors & subject field is reversed? The headings in the results are the right way around though. It’s not critical but curious as to why.

Regards,

Chris Herrmann
Far Edge Technology

p. 02 84251400
m. 0403 393309
http://www.faredge.com.au

I can’t tell, for certain, but it looks like there might be some cut-n-paste resultant extra newlines in your patch file, for example, between Curr and entUser.

That might just my mail server + client, though.From: Chris Herrmann [mailto:chris.herrmann@faredge.com.au]
Sent: Wednesday, January 26, 2011 09:19 PM
To: rt-users@lists.bestpractical.com rt-users@lists.bestpractical.com
Subject: [rt-users] cannot display requestor or requestors attributes in rt CLI when specifying fields

Hi Emmanuel,

Thanks, the patch doesn’t apply:

root@sirius:/usr/share/request-tracker3.8# patch -p2 < /tmp/thepatch
patching file html/REST/1.0/Forms/ticket/default
patch: **** malformed patch at line 14: $time = new RT::Date ($session{Curr entUser});

root@sirius:/tmp# cat thepatch
diff --git a/share/html/REST/1.0/Forms/ticket/default b/share/html/REST/1.0/Forms/ticket/default
index 0d403b2…280ab55 100755
— a/share/html/REST/1.0/Forms/ticket/default
+++ b/share/html/REST/1.0/Forms/ticket/default
@@ -202,7 +202,7 @@ if (!keys(%data)) {

 foreach $key (@people) {
     next unless (!%$fields || (exists $fields->{lc $key}));
  •    push @data, [ $key => [ $ticket->$key->MemberEmailAddresses ] ];
    
  •    push @data, [ $key =>
    
  • $ticket->$key->MemberEmailAddressesAsString ];
    }

    $time = new RT::Date ($session{CurrentUser});

root@sirius:/tmp#

This occurs twice in that file (approx. line 202 & line 310). The other matching text you’ve flagged there narrows it down to the block @ line 202…

Ok, found it:

205: push @data, [ $key => [ $ticket->$key->MemberEmailAddresses ] ];

To

    push @data, [ $key =>  $ticket->$key->MemberEmailAddresses  ];

and it’s now working… yay! I need to check a few other things in our staging environment first, and then will deploy to prod.

Dominic: Yes, agree but I need a way of making this work right now, so for the moment I’ll update our internal documentation around deploying upgrades for RT and a note to check this functionality. We have several other systems that depend upon RT (like billing for example) so we don’t tend to upgrade RT very often, only when we’re looking for some significant new functionality.

What’s the protocol for me to post this up as a suggestion for this fix to become incorporated back into the main 3.8 code base so that future releases will include it? (assuming that this isn’t going to break some other piece of critical functionality!).

Something weird I did notice (unrelated I think):

rt> list “id = 68667” -f id,requestors,subject
id Subject Requestors
68667 My testing ticket chris@noemail.com

Notice that the order of the requestors & subject field is reversed? The headings in the results are the right way around though. It’s not critical but curious as to why.

Regards,

Chris Herrmann
Far Edge Technology

p. 02 84251400
m. 0403 393309
http://www.faredge.com.au

Josh Narins
Director of Application Development

SeniorBridge
845 Third Ave
7th Floor
New York, NY 10022
Tel: (212) 994-6194
Fax: (212) 994-4260
Mobile: (917) 488-6248
jnarins@seniorbridge.com
seniorbridge.comhttp://www.seniorbridge.com/

[http://www.seniorbridge.com/images/seniorbridgedisclaimerTAG.gif]

SeniorBridge Statement of Confidentiality: The contents of this email message are intended for the exclusive use of the addressee(s) and may contain confidential or privileged information. Any dissemination, distribution or copying of this email by an unintended or mistaken recipient is strictly prohibited. In said event, kindly reply to the sender and destroy all entries of this message and any attachments from your system. Thank you.

Dominic: Yes, agree but I need a way of making this work right now, so for the moment I’ll update our internal documentation around deploying upgrades for RT and a note to check this functionality. We have several other systems that depend upon RT (like billing for example) so we don’t tend to upgrade RT very often, only when we’re looking for some significant new functionality.

Fair enough :slight_smile:

What’s the protocol for me to post this up as a suggestion for this fix to become incorporated back into the main 3.8 code base so that future releases will include it? (assuming that this isn’t going to break some other piece of critical functionality!).

I would write an email to rt-bugs@bestpractical.com including a
reference to this thread.

Cheers,
Dominic.

Dominic Hargreaves, Systems Development and Support Team
Computing Services, University of Oxford

signature.asc (197 Bytes)