When RT emails you something using a template (for instance the AdminComment template), there is a link in the email that should take you to the ticket number that is referenced in the email. When I
click on this, a browser pops up asking me to login, and when I do, all I get is ‘RT error -> No ticket specified.’ Then, if I try to search for that specific ticket number using the search button,
the ticket correctly loads.
If, when you click on the link in the email, RT starts to load on a browser that is already logged onto RT, the ticket will come up correctly as well. Has anyone else run into this?
If, when you click on the link in the email, RT starts to load on a
browser that is already logged onto RT, the ticket will come up
correctly as well. Has anyone else run into this?
Everyone, probably. The login is a POST, and the ticket number
in the URL (GET) is ignored. That’s a CGI.pm “feature”, AFAIK.
You’ve already discovered the workaround (although I find that
after I login, I can put the cursor in the Location: bar, hit
enter, and get the ticket.)
-Rich
Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus! http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------
|# Hi all,
|#
|# When RT emails you something using a template (for instance the AdminComment template), there is a link in the email that should take you to the ticket number that is referenced in the email. When I
|# click on this, a browser pops up asking me to login, and when I do, all I get is ‘RT error → No ticket specified.’ Then, if I try to search for that specific ticket number using the search button,
|# the ticket correctly loads.
|# If, when you click on the link in the email, RT starts to load on a browser that is already logged onto RT, the ticket will come up correctly as well. Has anyone else run into this?
|#
Edit the global Transaction template. There are " " (spaces)
between the < and > for the Ticket-URL which need removing.
Mine looks like…
Ticket URL: <{$RT::WebURL}Ticket/Display.html?id={$Ticket->id}>
Tim Rosmus trosmus@nwnexus.net
Postmaster / USENET / DNS
Northwest Nexus Inc.
Spaces outside a URL won’t have any effect on anything at all, except
the ease at which the URL can be cut and pasted (which is, I suspect,
why those spaces were there in the first place.)
The <> is a convention for humans.
-Rich
Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus! http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------
|# >
|# > Edit the global Transaction template. There are " " (spaces)
|# > between the < and > for the Ticket-URL which need removing.
|# > Mine looks like…
|# >
|# > Ticket URL: <{$RT::WebURL}Ticket/Display.html?id={$Ticket->id}>
|#
|# Spaces outside a URL won’t have any effect on anything at all, except
|# the ease at which the URL can be cut and pasted (which is, I suspect,
|# why those spaces were there in the first place.)
|#
Well I may have worded it wrong. I had the same problem with
the original setting, i.e. browser saying no such ticket. The
original was…
Everyone, probably. The login is a POST, and the ticket number
in the URL (GET) is ignored. That’s a CGI.pm “feature”, AFAIK.
You’ve already discovered the workaround (although I find that
after I login, I can put the cursor in the Location: bar, hit
enter, and get the ticket.)
I don’t know about that Rich. It works fine for me wether I’m logged in
or not.
If I’m logged in, RT goes right to the ticket.
If I’m not, I get stopped at the login screen, but when I log in, the
ticket specified is the first thing that opens.
Russ Johnson
Dimension 7/Stargate Online
Random thought #11 (Collect all 17)
“Every year, back comes Spring, with nasty little birds yapping their
fool heads off and the ground all mucked up with plants.” - Dorothy Parker
It seems like this is only an issue if you use fastcgi instead of mod_pearl. I have a separate box running mod_perl and it is ok, but the issue is with the one using fastcgi.From: Russ Johnson [mailto:russj@dimstar.net]
Sent: Thursday, October 03, 2002 4:33 PM
To: rt-users
Subject: Re: [rt-users] link does not work when sent as email
Rich Lafferty wrote:
Everyone, probably. The login is a POST, and the ticket number
in the URL (GET) is ignored. That’s a CGI.pm “feature”, AFAIK.
You’ve already discovered the workaround (although I find that
after I login, I can put the cursor in the Location: bar, hit
enter, and get the ticket.)
I don’t know about that Rich. It works fine for me wether I’m logged in
or not.
If I’m logged in, RT goes right to the ticket.
If I’m not, I get stopped at the login screen, but when I log in, the
ticket specified is the first thing that opens.
Russ Johnson
Dimension 7/Stargate Online
Random thought #11 (Collect all 17)
“Every year, back comes Spring, with nasty little birds yapping their
fool heads off and the ground all mucked up with plants.” - Dorothy Parker
You worded it fine, but that doesn’t solve the problem. Logging in first
solves the problem.
-Rich
Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus! http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------
It seems like this is only an issue if you use fastcgi instead of
mod_perl. I have a separate box running mod_perl and it is ok, but
the issue is with the one using fastcgi.
Oh, good catch. rolls up his sleeves
-Rich
Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus! http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------
It seems like this is only an issue if you use fastcgi instead of
mod_perl. I have a separate box running mod_perl and it is ok, but
the issue is with the one using fastcgi.
Oh, good catch. rolls up his sleeves
Thanks for pointing out the fastcgi part – it was a straightforward
fix. Against 2.0.14:
-------8<------- cut here -------8<-------
— rt2-orig/bin/mason_handler.fcgi Thu Oct 3 21:12:16 2002
+++ rt2-esmith/bin/mason_handler.fcgi Thu Oct 3 22:03:44 2002
@@ -127,6 +127,14 @@
my (%args, $cookie);
foreach my $key ( $cgi->param ) {
-------8<------- cut here -------8<-------
(Yes, we could’ve handled params and url_params all at once, but
then that routine wouldn’t come from ApacheHandler.pm anymore.)
-Rich
Rich Lafferty --------------±----------------------------------------------
Ottawa, Ontario, Canada | Save the Pacific Northwest Tree Octopus! http://www.lafferty.ca/ | Save The Pacific Northwest Tree Octopus
rich@lafferty.ca -----------±----------------------------------------------