RT 4.4.0rc3 - Error when listing assets

Hello!

I had an RT 4.2.12 on Debian testing ‘stretch’. I made the database
upgrade from 4.2.12 to 4.4.0rc3. I got no errors. The system is ‘up and
running’ so far, but then I got this error.

error: Can’t call method “Valid” on an undefined value at
/usr/local/share/request-tracker4/html/Asset/Elements/SelectStatus line 66.
context:

62: if ( not $ARGS{DefaultValue} ){
63: $ARGS{DefaultValue} = 0;
64: $ARGS{Default} ||= $DECODED_ARGS->{Status} ||
$lifecycle->DefaultOnCreate;
65: }
66: $ARGS{Statuses} = [ $AssetObj ? $lifecycle->Transitions("") :
$lifecycle->Valid ];
67: }
68: </%init>
69: <%args>
70: $AssetObj => undef

code stack:
/usr/local/share/request-tracker4/html/Asset/Elements/SelectStatus:66
/usr/share/request-tracker4/html/Asset/Elements/AssetSearchBasics:58
/usr/share/request-tracker4/html/Widgets/TitleBox:56
/usr/share/request-tracker4/html/Asset/Elements/AssetSearchBasics:84
/usr/share/request-tracker4/html/Asset/Search/index.html:78
/usr/share/request-tracker4/html/Widgets/TitleBox:56
/usr/share/request-tracker4/html/Asset/Search/index.html:92
/usr/share/request-tracker4/libexec/…/lib/RT/Interface/Web.pm:696
/usr/share/request-tracker4/libexec/…/lib/RT/Interface/Web.pm:375
/usr/share/request-tracker4/html/autohandler:53

Changed the code a little bit to see what is in the $lifecycle variable.

my $lifecycle = ($CatalogObj || “RT::Catalog”)->LifecycleObj;
if ( defined $lifecycle ) {
use Data::Dumper;
$RT::Logger->info( ‘$lifecycle:’.Dumper($lifecycle) );
} else {
$RT::Logger->info( ‘$lifecycle not defined’);
}
if ( not $ARGS{DefaultValue} ){
$ARGS{DefaultValue} = 0;
$ARGS{Default} ||= $DECODED_ARGS->{Status} || $lifecycle->DefaultOnCreate;
}
$ARGS{Statuses} = [ $AssetObj ? $lifecycle->Transitions("") :
$lifecycle->Valid ];

I got this result in syslog:
Jan 20 13:03:01 rt42x-jessie RT: [4052] No active catalogs.
Jan 20 13:03:01 rt42x-jessie RT: [4052] No active catalogs.
Jan 20 13:03:01 rt42x-jessie RT: [4052] $lifecycle not defined

Googled the error and found a BP forum thread about asset extension not
working. At that time, the database was not initialized. This time I
hope it is initialized, but how can I be sure?

From rt/Admin/Tools/Configuration.html file, it looks OK for me.

Upgrade from 4.2.12 to 4.4.0rc3 2016-01-18 14:10:43 5 seconds 4.4.0rc3
Upgrade from 4.2.12 to 4.3.0 2016-01-18 14:10:43 1 second 4.4.0rc3
Insert from /usr/share/request-tracker4/etc/upgrade/4.3.0/content
2016-01-18 14:10:44 0 seconds 4.4.0rc3
Upgrade from 4.3.0 to 4.3.1 2016-01-18 14:10:44 0 seconds 4.4.0rc3
Schema updates from /usr/share/request-tracker4/etc/upgrade/4.3.1
2016-01-18 14:10:44 0 seconds 4.4.0rc3
Insert from /usr/share/request-tracker4/etc/upgrade/4.3.1/content
2016-01-18 14:10:44 0 seconds 4.4.0rc3
Upgrade from 4.3.1 to 4.3.2 2016-01-18 14:10:44 0 seconds 4.4.0rc3
Insert from /usr/share/request-tracker4/etc/upgrade/4.3.2/content
2016-01-18 14:10:44 0 seconds 4.4.0rc3
Upgrade from 4.3.2 to 4.3.3 2016-01-18 14:10:44 1 second 4.4.0rc3
Schema updates from /usr/share/request-tracker4/etc/upgrade/4.3.3
2016-01-18 14:10:45 0 seconds 4.4.0rc3
Upgrade from 4.3.3 to 4.3.4 2016-01-18 14:10:45 0 seconds 4.4.0rc3
Schema updates from /usr/share/request-tracker4/etc/upgrade/4.3.4
2016-01-18 14:10:45 0 seconds 4.4.0rc3
Upgrade from 4.3.4 to 4.3.5 2016-01-18 14:10:45 0 seconds 4.4.0rc3
Insert from /usr/share/request-tracker4/etc/upgrade/4.3.5/content
2016-01-18 14:10:45 0 seconds 4.4.0rc3
Upgrade from 4.3.5 to 4.3.6 2016-01-18 14:10:45 0 seconds 4.4.0rc3
Insert from /usr/share/request-tracker4/etc/upgrade/4.3.6/content
2016-01-18 14:10:45 0 seconds 4.4.0rc3
Upgrade from 4.3.6 to 4.3.7 2016-01-18 14:10:45 1 second 4.4.0rc3
Schema updates from /usr/share/request-tracker4/etc/upgrade/4.3.7
2016-01-18 14:10:45 0 seconds 4.4.0rc3
Upgrade from 4.3.7 to 4.3.8 2016-01-18 14:10:46 0 seconds 4.4.0rc3
Schema updates from /usr/share/request-tracker4/etc/upgrade/4.3.8
2016-01-18 14:10:46 0 seconds 4.4.0rc3
Insert from /usr/share/request-tracker4/etc/upgrade/4.3.8/content
2016-01-18 14:10:46 0 seconds 4.4.0rc3
Upgrade from 4.3.8 to 4.3.9 2016-01-18 14:10:46 0 seconds 4.4.0rc3
Insert from /usr/share/request-tracker4/etc/upgrade/4.3.9/content
2016-01-18 14:10:46 0 seconds 4.4.0rc3
Upgrade from 4.3.9 to 4.3.10 2016-01-18 14:10:46 1 second 4.4.0rc3
Schema updates from /usr/share/request-tracker4/etc/upgrade/4.3.10
2016-01-18 14:10:46 0 seconds 4.4.0rc3
ACL updates from /usr/share/request-tracker4/etc/upgrade/4.3.10
2016-01-18 14:10:47 0 seconds 4.4.0rc3
Insert from /usr/share/request-tracker4/etc/upgrade/4.3.10/content
2016-01-18 14:10:47 0 seconds 4.4.0rc3
Upgrade from 4.3.10 to 4.3.11 2016-01-18 14:10:47 0 seconds 4.4.0rc3
Insert from /usr/share/request-tracker4/etc/upgrade/4.3.11/content
2016-01-18 14:10:47 0 seconds 4.4.0rc3
Upgrade from 4.3.11 to 4.3.12 2016-01-18 14:10:47 0 seconds 4.4.0rc3
Schema updates from /usr/share/request-tracker4/etc/upgrade/4.3.12
2016-01-18 14:10:47 0 seconds 4.4.0rc3
ACL updates from /usr/share/request-tracker4/etc/upgrade/4.3.12
2016-01-18 14:10:47 0 seconds 4.4.0rc3
Upgrade from 4.3.12 to 4.3.13 2016-01-18 14:10:47 1 second 4.4.0rc3
Schema updates from /usr/share/request-tracker4/etc/upgrade/4.3.13
2016-01-18 14:10:47 1 second 4.4.0rc3

I had an RT 4.2.12 on Debian testing ‘stretch’. I made the database upgrade
from 4.2.12 to 4.4.0rc3. I got no errors. The system is ‘up and running’ so
far, but then I got this error.

error: Can’t call method “Valid” on an undefined value at
/usr/local/share/request-tracker4/html/Asset/Elements/SelectStatus line 66.

[…]

From rt/Admin/Tools/Configuration.html file, it looks OK for me.

Upgrade from 4.2.12 to 4.4.0rc3 2016-01-18 14:10:43 5 seconds 4.4.0rc3
Upgrade from 4.2.12 to 4.3.0 2016-01-18 14:10:43 1 second 4.4.0rc3
Insert from /usr/share/request-tracker4/etc/upgrade/4.3.0/content

From this, it looks like you overwrote the Debian packaged version
of RT with 4.4 by hand, since there is no Debian package of RT 4.4 yet
(unless one was created outside Debian that I don’t know about). There
are also some unexplained local files (in /usr/local).

This approach is very unlikely to work smoothly. If you want to run RT
4.4 before those packages are available, you will need to install
manually into a separate directory (eg /opt/rt4.4).

Dominic.

Please don’t reply off-list.

2016-01-20 13:52 keltez�ssel, Dominic Hargreaves �rta:

I had an RT 4.2.12 on Debian testing ‘stretch’. I made the database upgrade
from 4.2.12 to 4.4.0rc3. I got no errors. The system is ‘up and running’ so
far, but then I got this error.

error: Can’t call method “Valid” on an undefined value at
/usr/local/share/request-tracker4/html/Asset/Elements/SelectStatus line 66.

[…]

From rt/Admin/Tools/Configuration.html file, it looks OK for me.

Upgrade from 4.2.12 to 4.4.0rc3 2016-01-18 14:10:43 5 seconds 4.4.0rc3
Upgrade from 4.2.12 to 4.3.0 2016-01-18 14:10:43 1 second 4.4.0rc3
Insert from /usr/share/request-tracker4/etc/upgrade/4.3.0/content

From this, it looks like you overwrote the Debian packaged version
of RT with 4.4 by hand, since there is no Debian package of RT 4.4 yet.
Yes, you are right about that.

There
are also some unexplained local files (in /usr/local).
You see /usr/local/share/request-tracker4/html/Asset/Elements/SelectStatus
because I made my modifications in that file instead of the original
/usr/share/request-tracker4/html/Asset/Elements/SelectStatus
This is to preserve the original content in case I want to revert to it.

This approach is very unlikely to work smoothly. If you want to run RT
4.4 before those packages are available, you will need to install
manually into a separate directory (eg /opt/rt4.4).

Depending on what causes the error you may right. If the error is caused by
a wrong/not updated file then it is my fault.

You’ve just said that you overwrote the Debian files with others.
This is just wrong, even if you managed to make it (mostly) work.
It’s just not something that anyone can reasonably provide support on.

If there is something that the database upgrade scripts didn’t do right then
the location of the files are irrelevant.

This does not alter what I said above.

Dominic.

2016-01-20 15:43 keltez�ssel, Dominic Hargreaves �rta:

Please don’t reply off-list.

Sorry, It was not by intention.

If there is something that the database upgrade scripts didn’t do right then
the location of the files are irrelevant.

This does not alter what I said above.
Yes.

I managed to fix the error by applying the full lifecycle hash from the
RT_Config.pm|in file.

Actually I did it earlier (before I wrot the letter about the error) but
somehow I forgot to ‘compile’ it to Debian’s RT_SiteConfig.pm file from
the RT_SiteConfig.d path. On the other hand I was convinced that I
compiled, ant is should work now. :frowning:

BR,
Atus