When comparing the canonicalized values, one must bear in mind that
->Content is not just the Content column in the database; instead, it
falls back to the LongContent, in addition to doing explicit formatting
for IP range custom fields.

Compare the 'Content' key to what is actually in the 'Content' column,
using $self->_Value().  This does not fix IP custom field updates, as
the input Content has still not been split into Content and LargeContent
as the database stores it.

These tests are based on the RTIR initialdata file which identified the
problem and fail on 4.2-trunk because of warnings generated during the
initialdata load of t/api/initialdata.t

I suspect we want to enhance our initialdata sample with any further
Handle::InsertData hacking (or docs/initialdata.pod updates).

Switching directly from Queue to ObjectId is not correct, as it fails to
provide the ObjectType/LookupType hint.

Conflicts:
	etc/RT_Config.pm.in
	etc/RT_SiteConfig.pm
	sbin/rt-test-dependencies.in
	share/html/Admin/Elements/EditRights

	share/html/Search/Bulk.html

    Bulk CF update moved to ProcessRecordBulkCustomFields in
    RT::Interface::Web in 4.2; move the change to there.  It also
    requires protecting the new "update a single value" (added in
    bcb8f0f6) case to skip if HasEntry.  Finally, drop the Repeated
    check, as the Repeated column was removed in d28b0a67.

As noted in ec5943dd, we have to do this so _ClassAccessible works
properly in the importer.  Now that we're serializing RT::ObjectScrip,
we have to be sure to build attributes on it.

This was left off in the confusion of the scripts-on-multiple-queues
merge which ran in parallel to the serializer merge.

Partially resolves #29949; note that it does not address the case of
ObjectScrips when in a non-clone context.

f0137c97 deleted ShowTitleBarCommands but commits which were merged
later (0d8eacf3 and 775f4bd1) used them for newly refactored code,
causing Reply/Comment/Forward to pop up all over the Approvals display,
and generating links that either loop back to the approvals page or
otherwise don't work.

The previous commit removed an outer if block and pushed it into the
boolean check of the elsif, leaving it weirdly indented.  This left
shifts everything as a separate commit to make reading the previous code
change clearer.

The 4.2 equivalent ShowActions should be compatible for the places
that want to suppress Reply/Comment/Forward.

This makes the code change, leaves whitespace terrible.

Show Outgoing Email goes to /Approvals/ShowEmailRecord.html which
doesn't exist.  Additionally, Reply/Comment/Forward are broken (although
shouldn't be visible, fixed in a later commit).

This also shows up in RTIR where links point to
/RTIR/ShowEmailRecord.html and /RTIR/Attachments/

Fixes issues 29800 and lays groundwork for a fix in RTIR for 29775.

While you could list /Ticket/Update.html and /Ticket/Crypt.html for the
6 *Path variables passed in %ARGS, it's nicer if you can just say "use
everything from /Ticket/, like you used to in 4.0".

Broken when moving to relative-by-default paths in 8274e2b6.

Since /Elements/ShowHistory isn't directly callable and the JS helper doesn't
pass extra arguments, there are currently no ways to pass a malicious
PathPrefix in from user supplied data.

To set an example for future code, transition away from the 'Queue'
argument, in preference to LookupType and ObjectId.  This helps clarify
the type of custom field that is expected to be returned.
Simultaneously, switch to using IncludeGlobal where the code would
benefit from such.

This throughly exercises the new codepath.  It leaves the existing
t/customfields/api.t untouched, though it may be sensible to merge them
in the future.

While it is tempting to officially deprecate these, they are in use in
core RT and in extensions, and introducing new deprecations during a
stable series is unwise.  Suffice to document them as deprecated, and
migrate exsting uses away from the, though not produce deprecation
warnings.

The join from CustomFields to ObjectCustomFields is guaranteed to be
distinct, by dint of the fat that either it is global, or it matches the
objectid we desire; as such, we can eliminate a cumbersome DISTINCT by
informing DBIx::SearchBuilder of this property at JOIN time.

Previously, in order to respect global CFs, callers were forced to
explicitly attempt to LoadByName with a queue, and then attempt again
with Queue => 0 if it failed.

Provide an option, defaulting to off, to first search queue CFs,
followed by global CFs.

For backwards compatibility, LoadByName has always maintained the
property that it may return a disabled custom field -- though it does so
only if there are no matching enabled fields.

Provide an option to control this behavior; the default is maintained as
it was previously, for backwards compatibility.

Note that previously, the only OrderBy was the Disabled flag -- this
means that if there were two non-disabled custom fields with the same
name, which one was returned was possibily non-deterministic.  This
commit places a predictable ordering on the resolution; namely, lower
SortOrder and lower id take precedence.

This opens the door for using LoadByName for custom fields not on
Transactions, Tickets, or Queues.  Callers specify a LookupType and
ObjectId, from which the class to load (if not RT::Queue) can be
inferred.  Consequently, using LoadByName for User (or Asset) custom
fields no longer requires writing an alternate and parallel
implementation of LoadByName.

We will use the LookupType as a default in the next commit, and thus
need to have it prior to when we resolve the object (currently Queue).

The existing logic in the "if" statement serves to skip the block in
precisely one situation -- the passed Queue is numeric, and there
already exists a ContextObject.  In such situation, it is not necessary
to attempt to load the Queue -- but it is not harmful, either.  In fact,
it may allow a better warning in cases where a numeric but non-existant
Queue is passed in.  It also clarifies the logic immeasurably.

A Queue value of 0 represents a global CF, but will not load a
queue successfully. Explicitly exclude 0 from the queue load and
context object setting. Although 57e10bf9 will now prevent this,
it logs a warning that is inappropriate when using the documented
API for the method.

For cases where an invalid Queue value is passed as an arg,
either a name or id of a non-existent queue or even 0, previously
the emtpy queue object would still be set as the context object
even though the load failed. This caused the search to add a
Limit on a LookupType of RT::Queue, which won't find any
custom fields.

Check the return code to avoid setting the empty queue object and
to warn so there is some help in the logs to track down a possible
typo in the queue name/id.

If other modules load CGI before we install the updated version, they
will get the in-core version, and trigger spurious deprecation warnings.
Quash deprecation warnings before loading to quiet this warning.

Perl 5.22 will remove CGI.pm from core; using the installed-from-core
version in perl 5.20 produces warnings.  On perl 5.20 and above,
increase the dependency to one that was never provded in core, to force
an install from CPAN.

Fixes I#29053.