Transaction search fails after upgrade

Jaime_Kikpole · January 2, 2021, 12:04am

I’ve just finished an RT 4.4.4 to 5.0.0 upgrade. As I test each feature (comment on a test ticket, etc.) to be sure that everything is working, I found something odd. The new feature of searching on transactions consistently fails. It gives a quantity of search results and then gives an error instead of listing them.

Here is a cropped screenshot to show what it looks like in the browser:

Screen Shot 2021-01-01 at 7.00.15 PM

This is what my Apache error log shows for that same search:

[4566] [Sat Jan  2 00:00:11 2021] [warning]: Use of uninitialized value $result_page in substitution (s///) at /usr/local/lib/perl5/site_perl/RT/Interface/Web/MenuBuilder.pm line 696. (/usr/local/lib/perl5/site_perl/RT/Interface/Web/MenuBuilder.pm:696)
[4566] [Sat Jan  2 00:00:11 2021] [error]: RT::Transaction::LastUpdated Unimplemented in RT::Record. (/usr/local/lib/perl5/site_perl/RT/Record.pm line 409) 

Stack:
  [/usr/local/lib/perl5/site_perl/DBIx/SearchBuilder/Record.pm:494]
  [/usr/local/lib/perl5/site_perl/RT/Record.pm:409]
  [/usr/local/share/rt50/html/Elements/ColumnMap:89]
  [/usr/local/share/rt50/html/Elements/CollectionAsTable/Row:151]
  [/usr/local/share/rt50/html/Elements/CollectionList:176]
  [/usr/local/share/rt50/html/Search/Results.html:78]
  [/usr/local/lib/perl5/site_perl/RT/Interface/Web.pm:710]
  [/usr/local/lib/perl5/site_perl/RT/Interface/Web.pm:389]
  [/usr/local/share/rt50/html/autohandler:53] (/usr/local/lib/perl5/site_perl/RT/Interface/Web/Handler.pm:209)

The old fashioned ticket search appears to be working fine. So does searching for articles and commenting on a ticket. I’m really not sure what I might be missing. Any suggestions?

knation · January 2, 2021, 12:53am

Hmm seems the code is missing some RT5 stuff. Does your footer say you’re on version 5? Do you have any extensions or customizations that would effect search reeults?

Jaime_Kikpole · January 2, 2021, 12:56am

The footer says 5.0.0.

The only customization I had previously was settings in RT_SiteConfig.pm and the calendar extension. I’ve removed the calendar extension and commented out the lines in RT_SiteConfig.pm that relate to it.

I installed it from FreeBSD’s packages system. So it is possible I missed a step on the manual setup. But I think I got it all. If a Perl module/library wasn’t loaded, is there a way to check for that?

Jaime_Kikpole · January 2, 2021, 1:01am

I don’t know if this helps, but it is another error I found.

# apachectl configtest

Performing sanity check on apache24 configuration:

[5787] [Sat Jan 2 00:59:48 2021] [warning]: Running with the internal HTML converter can result in performance issues with some HTML. Install one of the following utilities with your package manager to improve performance with an external tool: w3m, elinks, links, html2text, lynx (/usr/local/lib/perl5/site_perl/RT/Interface/Email.pm:1484)

Syntax OK

It’s worth noting that I have both links and lynx installed, despite what this error message claims.

Jaime_Kikpole · January 2, 2021, 5:03pm

This error (about HTML interpreters) appears to be because RT isn’t “seeing” the installs of links or lynx. I installed w3m, since the documentation in RT_Config.pm seemed to suggest that was the most preferred option, but that didn’t help. I ended up putting Set($HTMLFormatter, "/usr/local/bin/w3m"); into RT_SiteConfig.pm in order to make that error go away.

I also tried to make RT work in FastCGI (I’ve been using mod_perl since RT 1.0.3) to see if that would help. The package I installed in FreeBSD (pkg install rt50) seemed to have been made for FastCGI by default (per pkg info rt50). For some reason I still had a working RT instance with mod_perl 2.x, though. Unfortunately, I couldn’t figure out how to make FastCGI and Apache work. I kept getting 404 errors when I tried to view https://host.address/rt.

I also tried increasing the error output via Set($LogToScreen, "error"); and Set($LogToSyslog, "error"); in RT_SiteConfig.pm. This didn’t produce any change in diagnostic output in either the browser or the Apache error log.

I’m out of ideas and kind of grasping at straws now. Basically everything above (except trying to increase diagnostic output) was an educated guess. I’d really appreciate any suggestions, if you have them.

knation · January 2, 2021, 6:39pm

What search are you performing?

[error]: RT::Transaction::LastUpdated Unimplemented in RT::Record

It makes sense that a transaction doesn’t have that LastUpdated method, so maybe the search found an edge case bug?

Jaime_Kikpole · January 2, 2021, 6:57pm

I was searching for any transactions with ticket number less than 10. See screenshots below.

Just in case older tickets were lacking data (this RT instance is just shy of 20 years old), I ran a search for transactions of tickets over the last few days. Same results.

Screen Shot 2021-01-02 at 1.56.58 PM

knation · January 2, 2021, 7:02pm

Alright yeah the format for your search results is off, I assume you copied it from a ticket search?

You have:
__LastUpdatedRelative__
When it should be:
__TicketLastUpdatedRelative__

Jaime_Kikpole · January 2, 2021, 8:16pm

That gets rid of the error. The data doesn’t show up correctly, though. Here is a screenshot of the first few lines.

Tickets with transactions in the last few days:

Transaction ID < 10

Under the circumstances, you have a decent assumption, but it isn’t true in this case. I just started a new transaction search from the menu bar and added conditions to the search. Nothing more.

Screen Shot 2021-01-02 at 3.13.30 PM

After following your advice and getting good results, I went back to that menu to start a new search. The only condition I added was transaction id<20. The error message occurred again.

Is it possible that customizing the columns to be displayed at some point could impact this? Maybe something in a configuration that I’m forgetting about?

Jaime_Kikpole · January 2, 2021, 8:25pm

Sure enough… I found a setting for search options in my account’s preferences. The offending field is in there. Is it possible that this is applying to transactions as well as tickets?

Edit: After a quick test (added “Type” to the list of fields to display in my settings and ran another search), it showed that this is in fact the case. Any suggestions? I have a small handful of users of the web UI at the moment, so I could just talk to everyone. But this seems like a possible bug in code and/or UX.

Edit 2: Just in case this might be a glitch on my account alone, I restored the default settings on the “Show Columns” setting. Then I ran a transaction search and the issue was still there. Maybe this is just an issue on my instance / installation of RT, but I don’t have the ability to check that. This is my only install.

knation · January 2, 2021, 8:51pm

That seems to be a lack of feature as opposed to a bug. Looking at the dropdown to see the format options for the transaction results the realtive last updated format isn’t an option

Jaime_Kikpole · January 3, 2021, 2:20am

So are most people just working around this in silence? Or is there something different about my installation?

knation · January 3, 2021, 2:53am

You can try setting a value for:

TransactionDefaultSearchResultFormat

That should allow you to hopefully keep your ticket search result preferences then, just use valid options for the transactions results!

It does seem that there should be a default value for the transaction search results that is different than the ticket search results

Jaime_Kikpole · January 3, 2021, 8:18pm

I checked the effective configuration through the web UI. As shown below, it is set to a value other than the one that seems to be in effect.

vinz · March 25, 2021, 7:59am

Had the same issue and noticed that for some users the transaction search format was ok. Went to /Prefs/SearchOptions.html and clicked “Restore Default Preferences” -> this fixed the issue for me.

Seems like a bug with the search preferences putting nonsensical options into transaction search.