RT 3.2.1 & RTFM 2.0.4 Failure during ticket display

Apache 1.3/FastCGI/Perl 5.8.3/Solaris 9/RT 3.2.1/RTFM 2.0.4
Just upgraded from RT 3.2.0 / RTFM 2.0.3.

I did move my old RT3 directory out of the way then did the install for 3.2.1.
After that I did the install for RTFM 2.0.4. No errors were noted and
I do have all the required perl modules include the extra 3 that RTFM
asks for.

P.S. HTML::Format does not appear to exist on CPAN per RTFM’s README.
However HTML::Formatter does exist and appears to be the same module.

When trying to look at a ticket display that has linked RTFM documents
in the comments one of them blows up with the error below. Some of the
other RTFM doc’s appear properly in the ticket before the error is
noted.

error: Can’t call method “Id” on an undefined value at
/usr/local/rt3/lib/RT/URI/fsck_com_rtfm.pm line 147.
context:

143: }
144: }
145:
146: $self->{‘object’} = $article;
147: return ($article->Id);
148: }
149:
150: =head2 IsLocal
151:

code stack: /usr/local/rt3/lib/RT/URI/fsck_com_rtfm.pm:147
/usr/local/rt3/lib/RT/URI.pm:122
/usr/local/rt3/lib/RT/Transaction_Overlay.pm:610
/usr/local/rt3/lib/RT/Transaction_Overlay.pm:515
/usr/local/rt3/share/html/Ticket/Elements/ShowTransaction:28
/usr/local/rt3/share/html/Ticket/Elements/ShowHistory:84
/usr/local/rt3/share/html/Ticket/Display.html:39
/usr/local/rt3/share/html/autohandler:199
raw error

Apache 1.3/FastCGI/Perl 5.8.3/Solaris 9/RT 3.2.1/RTFM 2.0.4
Just upgraded from RT 3.2.0 / RTFM 2.0.3.

And this was known to not be a problem with RT 3.2.0/RTFM 2.0.3?

I did move my old RT3 directory out of the way then did the install for 3.2.1.
After that I did the install for RTFM 2.0.4. No errors were noted and
I do have all the required perl modules include the extra 3 that RTFM
asks for.

P.S. HTML::Format does not appear to exist on CPAN per RTFM’s README.
However HTML::Formatter does exist and appears to be the same module.

When trying to look at a ticket display that has linked RTFM documents
in the comments one of them blows up with the error below. Some of the
other RTFM doc’s appear properly in the ticket before the error is
noted.

Can you alter sub ParseURI in /usr/local/rt3/lib/RT/URI/fsck_com_rtfm.pm
to log the URI it’s being called with?

Jesse

Apache 1.3/FastCGI/Perl 5.8.3/Solaris 9/RT 3.2.1/RTFM 2.0.4
Just upgraded from RT 3.2.0 / RTFM 2.0.3.

And this was known to not be a problem with RT 3.2.0/RTFM 2.0.3?

RT 3.2.0/RTFM 2.0.3 did not have this problem.

I did move my old RT3 directory out of the way then did the install for 3.2.1.
After that I did the install for RTFM 2.0.4. No errors were noted and
I do have all the required perl modules include the extra 3 that RTFM
asks for.

P.S. HTML::Format does not appear to exist on CPAN per RTFM’s README.
However HTML::Formatter does exist and appears to be the same module.

When trying to look at a ticket display that has linked RTFM documents
in the comments one of them blows up with the error below. Some of the
other RTFM doc’s appear properly in the ticket before the error is
noted.

Can you alter sub ParseURI in /usr/local/rt3/lib/RT/URI/fsck_com_rtfm.pm
to log the URI it’s being called with?

Yes, here is the URI

[Thu Jul 22 18:19:47 2004] [warning]: Called URI was:
fsck.com-rtfm://Onvoy/article/1
(/usr/local/rt3/lib/RT/URI/fsck_com_rtfm.pm:115)

Apache 1.3/FastCGI/Perl 5.8.3/Solaris 9/RT 3.2.1/RTFM 2.0.4
Just upgraded from RT 3.2.0 / RTFM 2.0.3.

And this was known to not be a problem with RT 3.2.0/RTFM 2.0.3?

RT 3.2.0/RTFM 2.0.3 did not have this problem.

I did move my old RT3 directory out of the way then did the install for 3.2.1.
After that I did the install for RTFM 2.0.4. No errors were noted and
I do have all the required perl modules include the extra 3 that RTFM
asks for.

P.S. HTML::Format does not appear to exist on CPAN per RTFM’s README.
However HTML::Formatter does exist and appears to be the same module.

When trying to look at a ticket display that has linked RTFM documents
in the comments one of them blows up with the error below. Some of the
other RTFM doc’s appear properly in the ticket before the error is
noted.

Can you alter sub ParseURI in /usr/local/rt3/lib/RT/URI/fsck_com_rtfm.pm
to log the URI it’s being called with?

Yes, here is the URI

[Thu Jul 22 18:19:47 2004] [warning]: Called URI was:
fsck.com-rtfm://Onvoy/article/1
(/usr/local/rt3/lib/RT/URI/fsck_com_rtfm.pm:115)

And do you have an article 1? Is your $Organization set to ‘Onvoy’?
What do valid links look like?

And do you have an article 1? Is your $Organization set to ‘Onvoy’?
What do valid links look like?

Yes RTFM article 1 does exist.

I see the problem now.

I did change our $Organization name from Onvoy to onvoy.com and that’s
what broke it.
However, I made that change back in RT 3.0.11 and have not had issues
with RTFM until this latest upgrade.
The other strange part was it displayed RTFM articles in that same
ticket that were from the old name without any problems, it only
errored out on that one reference.

Thanks much for the help.

I just tested this to be sure and yes changing your Organization name
breaks any reference links to RTFM tickets. The real problem with this
is you can’t fix it unless you go directly into the database or change
your Organization back and then remove the link.
The RTFM ticket is shown in the comments properly but the history of
the link reference and the link itself is gone and no longer
changable, any history items after the link reference are also
unviewable because the display stops after the error message.On Thu, 22 Jul 2004 15:07:17 -0500, Kent drizit@gmail.com wrote:

And do you have an article 1? Is your $Organization set to ‘Onvoy’?
What do valid links look like?

Yes RTFM article 1 does exist.

I see the problem now.

I did change our $Organization name from Onvoy to onvoy.com and that’s
what broke it.
However, I made that change back in RT 3.0.11 and have not had issues
with RTFM until this latest upgrade.
The other strange part was it displayed RTFM articles in that same
ticket that were from the old name without any problems, it only
errored out on that one reference.

Thanks much for the help.