[rt-users] cannot display requestor or requestors attributes in rt CLI when specifying fields

[Josh Narins]



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 at faredge.com.au]
Sent: Wednesday, January 26, 2011 09:19 PM
To: rt-users at lists.bestpractical.com <rt-users at 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 at 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 at 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 at 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 at 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 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bestpractical.com/pipermail/rt-users/attachments/20110126/4023b430/attachment.htm>