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
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 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.com<http://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.
[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
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$startmonth"CallReport.txt" mutt -s "Monthly Queue Results" -a /tmp/$startyear$startmonth"M