[rt-users] Query result page broken after upgrade from 3.4 to3.6.3
Felix Windt
FWindt at smartcity.com
Wed Mar 14 12:46:40 EDT 2007
Sorry, I hit reply to Mark instead of Reply All.
Adjusting RT_Config.pm for the Default Search Display worked a treat and
everything is now functional.
Thanks a bunch!
-----Original Message-----
From: rt-users-bounces at lists.bestpractical.com
[mailto:rt-users-bounces at lists.bestpractical.com] On Behalf Of Borut
Mrak
Sent: Wednesday, March 14, 2007 8:42 AM
To: rt-users at lists.bestpractical.com
Subject: Re: [rt-users] Query result page broken after upgrade from 3.4
to3.6.3
Felix Windt wrote:
> Good morning all,
>
> We upgraded an inherited 3.4 system to 3.6.3 yesterday. We dumped the
> database via mysqldump and imported on the new system and then ran
> rt-update-database for the insert action for version 3.5.1. The "10
> highest priority tickets I own" and "10 newest unowned tickets"
queries
> work fine. Any other query (simple search, constructed via "in queue"
or
> anything else) constructs and runs fine - it even display the correct
> list, but the links to the tickets are missing the URL. The link
> consists of http://ticket/display... instead of
> http://subdomain.domain.tld/ticket/display.
>
> Any ideas on what this could be due to?
I had a similar problem on my Debian-supplied 3.6.1. Basically, the
global
attribute for My Tickets search was broken from the beginning. This is
what is in the supplied initialdata:
@Attributes = (
{ Name => 'Search - My Tickets',
Description => '[_1] highest priority tickets I own', # loc
Content =>
{ Format => "'<a
href=\"__WebPath__/Ticket/Display.html?id=__id__\">__id__</a>/TITLE:#',
'<a
href=\"$RT::WebPath/Ticket/Display.html?id=__id__\">__Subject__</a>/TITL
E:Subject',
Priority, QueueName, ExtendedStatus",
Query => " Owner = '__CurrentUser__' AND ( Status = 'new' OR
Status = 'open')",
OrderBy => 'Priority',
Order => 'DESC' },
},
Notice the $RT::WebPath, that's what is making the results display with
broken links. First link on the ticket ID works though.
Since it was not possible to fix it from the RT web interface, I just
took
this attribute from the whole initialdata file, modified it to use
__WebPath__ instead of $RT::WebPath, and imported it with
rt-setup-database.
In order not to break anything, I modified the id of the original
(broken)
attribute in the Attributes table so RT loaded the fixed one and when
everything worked, I deleted the broken one from the database.
There might be a better way around, but that was my way of fixing it
after
a few hours trying to understand the way RT works :) I can't wait to get
my hands on the RT book, it should make things simpler.
Since you seem to have a problem with all other searches except those on
the front page, I suggest you check the $DefaultSearchResultFormat in
RT_Config.pm. That takes care of most of the search results displays in
RT
and it just might be what you're looking for.
regards,
Borut Mrak.
_______________________________________________
http://lists.bestpractical.com/cgi-bin/mailman/listinfo/rt-users
Community help: http://wiki.bestpractical.com
Commercial support: sales at bestpractical.com
Discover RT's hidden secrets with RT Essentials from O'Reilly Media.
Buy a copy at http://rtbook.bestpractical.com
More information about the rt-users
mailing list