RT pages without links

RT Developers
1

Asked on rt-users but apparently no one there can help.

I recently moved our copy of RT 3.8.7 from Fedora 8 to Fedora 19. I
would have preferred to concurrently upgrade to the latest RT but had
some problems converting the data base. So in the interest of time, I
took the simpler approach of just copying the entire installation.

It works, mostly. In fact, the only problem I see is that ticket lists
on the dashboards are not links. Comparing the old and new installations
(both are running though DNS leads users to the new one), I see almost
exactly the same page layout and content. There are two obvious differences.

  1. Font selections are different. This is not critical and the new fonts
    are usable. It’s clearly an Apache difference.

  2. On the default home page, the tickets listed under "highest priority"
    and “newest unowned” are not active links. Comparing the page source for
    old and new installations, it is obvious that the href tags are simply
    not present on the new output. Other items, like the queue summary, do
    have working links as they did before.

Digging through the source code, I quickly got lost. I can see where the
collection-as-table class is specified but not where the associated
variables are added. It seems likely to me that something in F19 is
confusing RT but thus far I haven’t found what. If I could see where the
variable information was added to the output, I suspect I’d see some
kind of test that is now getting a different answer and that that test
would lead me to the solution.

So, if anyone can tell me the cause of my problem right away, that would
be much appreciated. But, if not, then a clue on where to look in the
source code might help almost as much.
Dave Close

2

I wrote:

I recently moved our copy of RT 3.8.7 from Fedora 8 to Fedora 19. I
would have preferred to concurrently upgrade to the latest RT but
had some problems converting the data base. So in the interest of
time, I took the simpler approach of just copying the entire
installation.

It works, mostly. In fact, the only problem I see is that ticket
lists on the dashboards are not links. Comparing the old and new
installations (both are running though DNS leads users to the new
one), I see almost exactly the same page layout and content. There
are two obvious differences.

  1. Font selections are different. This is not critical and the new
    fonts are usable. It’s clearly an Apache difference.

  2. On the default home page, the tickets listed under “highest
    priority” and “newest unowned” are not active links. Comparing the
    page source for old and new installations, it is obvious that the
    href tags are simply not present on the new output. Other items, like
    the queue summary, do have working links as they did before.

Digging through the source code, I quickly got lost. I can see where
the collection-as-table class is specified but not where the
associated variables are added. It seems likely to me that something
in F19 is confusing RT but thus far I haven’t found what. If I could
see where the variable information was added to the output, I suspect
I’d see some kind of test that is now getting a different answer and
that that test would lead me to the solution.

So, if anyone can tell me the cause of my problem right away, that
would be much appreciated. But, if not, then a clue on where to look
in the source code might help almost as much.

I’m surprised and disappointed that no one seems able to help with this
issue. Did I omit something important when describing the problem?
Dave Close

3

Robert Nesius wrote:

Are you using the system perl? If so, I’d try installing the
version of perl that was on your old machine with perlbrew, update
its modules as necessary, and have RT run over that perl.

Yes, I am using the system Perl. I suspect your idea is exactly what I
was missing. Thanks.

Surprisingly, at least to me, I hadn’t heard of perlbrew. I think that’s
a great idea and I’m getting it installed now. But since RT doesn’t run
as an “application” but simply as a series of Apache pages and CGI
scripts, I’m wondering how to get it to use the older Perl. I don’t want
Apache to use the old version for other pages. Any ideas?

Maybe this will be as simple as changing the shabang lines. But I
haven’t tried it yet so maybe someone can save me a little time.

I wrote:

I recently moved our copy of RT 3.8.7 from Fedora 8 to Fedora 19.
I would have preferred to concurrently upgrade to the latest RT
but had some problems converting the data base. So in the interest
of time, I took the simpler approach of just copying the entire
installation.

It works, mostly. In fact, the only problem I see is that ticket
lists on the dashboards are not links. Comparing the old and new
installations (both are running though DNS leads users to the new
one), I see almost exactly the same page layout and content. There
are two obvious differences.

  1. Font selections are different. This is not critical and the new
    fonts are usable. It’s clearly an Apache difference.

  2. On the default home page, the tickets listed under “highest
    priority” and “newest unowned” are not active links. Comparing the
    page source for old and new installations, it is obvious that the
    href tags are simply not present on the new output. Other items,
    like the queue summary, do have working links as they did before.

Digging through the source code, I quickly got lost. I can see
where the collection-as-table class is specified but not where the
associated variables are added. It seems likely to me that
something in F19 is confusing RT but thus far I haven’t found what.
If I could see where the variable information was added to the
output, I suspect I’d see some kind of test that is now getting a
different answer and that that test would lead me to the solution.

So, if anyone can tell me the cause of my problem right away, that
would be much appreciated. But, if not, then a clue on where to
look in the source code might help almost as much.

I’m surprised and disappointed that no one seems able to help with
this issue. Did I omit something important when describing the
problem?
Dave Close

4

Robert Nesius wrote:

Are you using the system perl? If so, I’d try installing the
version of perl that was on your old machine with perlbrew, update
its modules as necessary, and have RT run over that perl.

Yes, I am using the system Perl. I suspect your idea is exactly what I
was missing. Thanks.

You’re welcome.

Surprisingly, at least to me, I hadn’t heard of perlbrew. I think that’s
a great idea and I’m getting it installed now. But since RT doesn’t run
as an “application” but simply as a series of Apache pages and CGI
scripts, I’m wondering how to get it to use the older Perl. I don’t want
Apache to use the old version for other pages. Any ideas?

I have apache invoke RT via fastcgi. Somewhere in the fastcgi/apache2
configs I define which perl to use I think.

I generally avoid using modperl because perl-based web-apps don’t always
agree on what they want in their perl environment. That also starts to
brush into similar config-issues as what you’re experiencing with perl. If
you use your distro’s apache2 then chances are your modperl is running
against the system perlenv as well. It’s possible to provision your own
modperl built against your own perl and configure the distro-provided
apache2 to use it. I actually did that once and found it to be a bit of a
hassle. I’ve found using the distro-provided apache2 and provisioning my
own perls to be the best compromise between stability and convenience.

It’s been awhile since I set up my RT env but I can dig in the configs
tomorrow if you still need a hand.

-Rob

5

I recently moved our copy of RT 3.8.7 from Fedora 8 to Fedora 19. I
would have preferred to concurrently upgrade to the latest RT but had
some problems converting the data base. So in the interest of time, I
took the simpler approach of just copying the entire installation.

It works, mostly. In fact, the only problem I see is that ticket lists
on the dashboards are not links. Comparing the old and new installations
(both are running though DNS leads users to the new one), I see almost
exactly the same page layout and content. There are two obvious differences.

  1. Font selections are different. This is not critical and the new fonts
    are usable. It’s clearly an Apache difference.

  2. On the default home page, the tickets listed under "highest priority"
    and “newest unowned” are not active links. Comparing the page source for
    old and new installations, it is obvious that the href tags are simply
    not present on the new output. Other items, like the queue summary, do
    have working links as they did before.

Digging through the source code, I quickly got lost. I can see where the
collection-as-table class is specified but not where the associated
variables are added. It seems likely to me that something in F19 is
confusing RT but thus far I haven’t found what. If I could see where the
variable information was added to the output, I suspect I’d see some
kind of test that is now getting a different answer and that that test
would lead me to the solution.

So, if anyone can tell me the cause of my problem right away, that would
be much appreciated. But, if not, then a clue on where to look in the
source code might help almost as much.
Dave Close

6

Hi Dave

Not sure how many users are still in 3.8.x, let alone on Fedora, let alone went through a Fedora upgrade, let alone copied the installation over. In other words, you might be targeting a very small audience. Just a guess.

I’m personally on Ubuntu and RT 4.2.0, but I’ll take a stab anyway.

I wondered about your approach of “just copying the entire installation” – Does that mean you moved a tar copy of the RT directory tree over (and did a database dump and restore to the new F19 box)?

At the very least, I’d recommend downloading RT source and running the config and make testdeps to ensure you have all the proper Perl modules installed.

Typically I install from scratch on the new box so I can be sure everything is built properly (e.g. missing dependencies, perhaps something is in a different place now, etc), and then copy over the RT_SiteConfig.pm and any customized code.

On another note: I think in general it’s frowned upon to post to both the development and user lists.

I wrote:

I recently moved our copy of RT 3.8.7 from Fedora 8 to Fedora 19. I
would have preferred to concurrently upgrade to the latest RT but had
some problems converting the data base. So in the interest of time, I
took the simpler approach of just copying the entire installation.

It works, mostly. In fact, the only problem I see is that ticket lists
on the dashboards are not links. Comparing the old and new
installations (both are running though DNS leads users to the new
one), I see almost exactly the same page layout and content. There are
two obvious differences.

  1. Font selections are different. This is not critical and the new
    fonts are usable. It’s clearly an Apache difference.

  2. On the default home page, the tickets listed under “highest
    priority” and “newest unowned” are not active links. Comparing the
    page source for old and new installations, it is obvious that the href
    tags are simply not present on the new output. Other items, like the
    queue summary, do have working links as they did before.

Digging through the source code, I quickly got lost. I can see where
the collection-as-table class is specified but not where the
associated variables are added. It seems likely to me that something
in F19 is confusing RT but thus far I haven’t found what. If I could
see where the variable information was added to the output, I suspect
I’d see some kind of test that is now getting a different answer and
that that test would lead me to the solution.

So, if anyone can tell me the cause of my problem right away, that
would be much appreciated. But, if not, then a clue on where to look
in the source code might help almost as much.

I’m surprised and disappointed that no one seems able to help with this issue. Did I omit something important when describing the problem?
Dave Close

7

Brent Parish wrote:

On another note: I think in general it’s frowned upon to post to both
the development and user lists.

I agree with your sentiment. In this case, I had posted the original
note to both lists, first to users ten days ago and then to devel three
days ago. So I could have sent the same follow-up separately to both
lists but that didn’t seem helpful. That would have meant that some
people got the follow-up twice. But I also generally avoid the practice.
Sorry for any offense.
Dave Close, Thales Avionics, Irvine California USA.
cell +1 949 394 2124, dave.close@us.thalesgroup.com