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:[email protected]] Sent: Wednesday, January 26, 2011 09:19 PM To: [email protected] <[email protected]> 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 [email protected] 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 [email protected] 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.
