GitLab

Without the Queue, it searches too widely and throws a lot of warnings
and errors.

Accidentally made make snapshot not work anymore

There are several variable interpolation strings we should fix, but this
is a quick first start before it ends up on 3.0-trunk and then on
launchpad.

This clones RT's incant (minus the configuration for the hardcoded 5).
I admit that this is largely so my shell aliases that work on RT also
work on RTIR so that I can run the test suite quickly.

Otherwise, example.com or email addresses anywhere in the history of a
ticket in the General queue ends up with links off to
/RTIR/Tools/Lookup.html.  Normal users have no idea why those links are
there and they're frankly ugly and cluttering outside the RTIR workflow.

A ticket in the Incidents queue is of type Incident, so there is that
small change in the incident if.  TicketType can also return undef so we have to
guard.

We use the ticket type to skip doing other replacements.

The portlets on the RTIR homepage now have a little more flexibility
without requiring mason overlays.

Allows us to explode nicely when people try to install on RT 4.2.x

Needed updated license_tag from 4.0/copyright-2014

All this does is force mysql to sort (possibly filesort) and we really
don't care about the order when we're going to use it to feed an update
or delete.

When MySQL optimizes our UPDATE where id in (SELECT) it doesn't know
that the tables are linked, so it ends up walking and examining lots and
lots of rows.  Including the ObjectType column means that mysql can
easily examine 1 row using our existing ObjectCustomFieldValues2 index
and update immediately.

There is no longer a need to add upgrade specific indexes for OCFVs (the
transaction indexes still improve performance).

RT::Ticket->SubjectTag was implemented about 2 weeks after RTIR was
udpated to use SubjectTags.  Unfortunately, RTIR wasn't fixed to use it
until now.

Also include a new test file.

here is the old code:

$BaseQuery ||= RT::IR->Query( Queue => $Queue );
$Query     ||= RT::IR->ActiveQuery( Queue => $Queue );

if both $BaseQuery and $Query are empty before, they will be set to
RT::IR->Query(...) and RT::IR->ActiveQuery(...) here, respectively.

but ->ActiveQuery already includes ->Query, so the finaly query will be for
example(combined by BaseQuery AND Query):

( ( Queue = 'Incidents' ) ) AND ( ( Queue = 'Incidents' ) AND Status = 'open' )

so we don't need to set $BaseQuery in this case.

you can reproduce it by accessing "/RTIR/Search/Results.html?Queue=Incidents"
and then clicking the "Edit Search" menu

When 7131a78b changed RTIR over to the new Googleish search API, it lost
an important feature.  You could no longer type 7 into the RTIR Simple
Search and jump to 7.  You would be forced into a search for an Incident
with the id of 7, and presented with a results list of 1 (if this was an
incident).  If you were trying to jump to anything but an Incident, you
got an empty search result.

This updates the tests that were written for new features with tests
that ensure this feature works.

Copied core's convention of accepting #1 and 1 so that copy/paste from
email subjects is less confusing.

The confusing Incident search behavior of a list of 1 item also revealed
that RTIR's Search Results do not support core's
$SearchResultsAutoRedirect configuration option.

When introduced in 591dfd01, this option limited the
Transactions/Attachments we were going to FTS on, which makes sense.

For performance reasons, it was removed from the Custom Field searches
prior to 2.4.4 in 88077233.  However, that commit didn't fix the docs,
and it didn't consider that Lookups now act weirdly based on what you're
searching for.

In [rtir #14427] I lay out the history and possible fixes.  For 3.0.0,
documentation is the best solution.

As discovered by sunnavy when he went spelunking to determine why
t/walk-web.t started running so many extra tests (7a630ac1), we were
stuffing a bunch of extra query params into the query string,
depending on whether we did that from the hash or passed args (things
like Object and Description).

I rewrote his patch a bit to use the same Field list as search_arguments

We lose saved search state badly in RTIR, but it's not a regression
caused by this code, see [rtir #25241]