Re: [rt-users] cannot display requestor or requestors attributes in rt CLI when specifying fields
On Thu, Jan 27, 2011 at 01:19:05PM +1100, Chris Herrmann wrote: 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 :) 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-b...@bestpractical.com including a reference to this thread. Cheers, Dominic. -- Dominic Hargreaves, Systems Development and Support Team Computing Services, University of Oxford signature.asc Description: Digital signature
[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 ticketch...@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
Re: [rt-users] cannot display requestor or requestors attributes in rt CLI when specifying fields
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.herrm...@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 ticketch...@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
jnar...@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.
Re: [rt-users] cannot display requestor or requestors attributes in rt CLI when specifying fields
On Fri, Jan 14, 2011 at 03:49:23PM +1100, Chris Herrmann wrote:
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-b...@bestpractical.com for this :)
and there is no way to get Requestors.Name currently ... patches are welcome ;)
[rt-users] 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 Date: Wed Jan 12 08:21:05 2011 From: chrisdotherrrmannatfaredgedotcomdotau X-Queue: helpdesk Subject: [rt #ticket/71900] New Service Call - Default Wallpaper too large 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$startmonthCallReport.txt mutt -s Monthly Queue Results -a /tmp/$startyear$startmonthMontlyCallReport.txt --
