Query result page broken after upgrade from 3.4 to 3.6.3

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?

Felix Windt

Felix Windt wrote:

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?

Check that $WebBaseURL in your RT_SiteConfig.pm is set correctly.

Haakon Nilsen

It is set correctly. The working queries access the same variable and
work fine.

Felix Windt
Network Administrator
Smart City, Las Vegas

(702) 943-6059 Help Desk
(702) 943-6011 Fax
(702) 943-9373 Direct
(702) 308-9342 CellFrom: Haakon Nilsen [mailto:haakon@ii.uib.no]
Sent: Wednesday, March 14, 2007 5:56 AM
To: Felix Windt
Cc: rt-users@lists.bestpractical.com
Subject: Re: [rt-users] Query result page broken after upgrade from 3.4
to 3.6.3

Felix Windt wrote:

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?

Check that $WebBaseURL in your RT_SiteConfig.pm is set correctly.

Haakon Nilsen

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/TITLE:#’,
’<a
href=”$RT::WebPath/Ticket/Display.html?id=id">Subject/TITLE: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 :slight_smile: 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.

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!

[mailto:rt-users-bounces@lists.bestpractical.com] On Behalf Of Borut
MrakSent: Wednesday, March 14, 2007 8:42 AM
To: rt-users@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/TITLE:#’,
’<a
href=”$RT::WebPath/Ticket/Display.html?id=id">Subject/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 :slight_smile: 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@bestpractical.com

Discover RT’s hidden secrets with RT Essentials from O’Reilly Media.
Buy a copy at http://rtbook.bestpractical.com

Felix Windt wrote:

Adjusting RT_Config.pm for the Default Search Display worked a treat and
everything is now functional.

You should leave RT_Config.pm alone and make your modifications in
RT_SiteConfig.pm.

regards,
Borut Mrak.