Upgrading from RT 4.4.4 to 4.4.5 on our test server worked fine (FreeBSD using ports/pkg) but in production we got to browser: “An internal RT error has occurred. Your administrator can find more details in RT’s log files.”
and logged was:
[error]: Not an ARRAY reference at /usr/local/share/rt44/html/Elements/Tabs line 608.
Stack:
Any ideas how to troubleshoot what might be at the root of this mystery?
Thanks in advance… .
Ben
606 my $recents = $tickets->child( recent => title => loc(‘Recently Viewed’));
That seems odd since on a clean 4.4.5 RT it isn’t the same:
%# BEGIN BPS TAGGED BLOCK {{{
%#
%# COPYRIGHT:
%#
%# This software is Copyright (c) 1996-2021 Best Practical Solutions, LLC
%# <sales@bestpractical.com>
%#
%# (Except where explicitly superseded by other copyright notices)
%#
%#
%# LICENSE:
%#
%# This work is made available to you under the terms of Version 2 of
%# the GNU General Public License. A copy of that license should have
%# been provided with this software, but in any event can be snarfed
%# from www.gnu.org.
%#
%# This work is distributed in the hope that it will be useful, but
%# WITHOUT ANY WARRANTY; without even the implied warranty of
%# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
show original
oh sorry - that was lines 606-608 from the older version RT 4.4.4!
On 4.4.5 on our test server, I see the same exact file as you linked there (from github) so the line 608 has:
604 $dashes->child( edit => title => loc('Update This Menu'), path => 'Prefs/DashboardsInMenu.html' );
605 $dashes->child( more => title => loc('All Dashboards'), path => 'Dashboards/index.html' );
606 my $dashboard = RT::Dashboard->new( $session{CurrentUser} );
607 if ( $dashboard->CurrentUserCanCreateAny ) {
608 $dashes->child('dashboard_create' => title => loc('New Dashboard'), path => "/Dashboards/Modify.html?Create=1" );
609 }
Did you clear the mason cache/restart the web server? It seems odd as there is no reference to an array on 608 there
had restarted web server, had not yet tried clearing the mason cache. . . can try that tonight!
i didn’t bother waiting for our maintenance window! clearing the mason cache (/var/run/rt44/mason_data/obj/* on FreeBSD port) did the trick! thank you so much! this had become a real thorn in my side!