This is not only for code consistency, but also for consistency of
output.  Encode::encode_utf8(...) is equivalent to
Encode::encode("utf8",...) which is the non-"strict" form of UTF-8.
Strict UTF-8 encoding differs in that (from `perldoc Encode`):

    ...its range is much narrower (0 ..  0x10_FFFF to cover only 21 bits
    instead of 32 or 64 bits) and some sequences are not allowed, like
    those used in surrogate pairs, the 31 non-character code points
    0xFDD0 .. 0xFDEF, the last two code points in any plane (0xXX_FFFE
    and 0xXX_FFFF), all non-shortest encodings, etc.

RT deals with interchange with databases, email, and other systems.  In
dealing with encodings, it should ensure that it does not produce byte
sequences that are invalid according to official Unicode standards.

Placing wide characters into MIME::Entity objects can lead to
double-encoding, as discovered most recently in d469cacc.  Explicitly
decode all headers as UTF-8 when retrieving them with ->get(), and
encode them as UTF-8 before updating them with ->set() or ->replace().
This also applies to headers passed to ->build().  The only exceptions
to this are fixed strings in the source (which, in the absence of "use
utf8", are always bytes).

While the majority of these headers will never have wide characters in
them, always decoding and encoding ensures the proper disipline to
guarantee that strings with the "UTF8" flag do not get placed in a
header, which can cause double-encoding.

Placing wide characters into MIME::Entity objects can lead to
double-encoding.  Always treat them as byte stores, encoding as UTF-8
and noting their character set.

In the case of Approvals/index.html, there was no need for an explicit
MIME::Entity object; ->Correspond creates one as needed from a "Content"
argument.

Old "message recorded" is confusing as it doesn't differentiate
between correspond and comment.

Since we don't offer Status in the Quick Create widget, we should just
let Create pick the on_create default from the Queue's lifecycle.

While in here, update RT::Ticket::Create to have less lying around what
to pass for Status (valid statuses haven't listed been in
RT::Queue in 4.0 or 4.2).

We started using the default from the Queue's Lifecycle in b206b50a,
which is the same commit where we stopped hardcoding 'new' in
RT::Ticket::Create.

Found in RTIR user since 3 of the 4 RTIR queues don't allow tickets
with the new status.

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.

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.

Merging a ticket into itself now displays an error ("Merge
failed. Couldn't set EffectiveId") and no logner leaves a backtrace in
the logs (due to calling both ->Rollback _and_ ->Commit)

Fixes I#26407.

Fixes I#25308.

MIME::Tools 4.x (in 1998) deprecated ->set, in preference to the more
explicit ->replace() call; ->set is no longer documented in POD, in
fact.  Switch all places which use the former to using the latter.

Fixes I#18417

Other errors are fixed in 3156d1b9, and will be resolved on merge-up
from 4.0-trunk.

RT::Interface::Web::CreateTicket munges the query parameters to pass
Customfield-42 to RT::Ticket::Create, as of be3529af.  An important
change made in this commit is that previously, transaction custom fields
were passed through with their keys unmodified -- that is, as
Object-RT::Transaction--Customfield-42.

After be3529af, the information about if the CF was a Ticket or
Transaction custom field has been lost by the time the CFs are being
iterated.  This led to attempting to add values for Transaction CFs on
Ticket objects, and vice versa -- and thus warnings in the UI of "Custom
field 42 does not apply to this object" for every applied transaction
CF.

Only attempt to add CF values to objects if they are of the correct
class.

previously, as long as user has ReassignTicket, RT::Ticket::CurrentUserCanSetOwner
would return true for both "Take" and "Steal" types no matter what the ticket's
current owner is, which is not good, as we want to use it like(in /Elements/Tabs):

    my ($can_take, $msg) = $ticket->CurrentUserCanSetOwner( Type => 'Take' );
    if ( $can_take ) {
        # show "Take" link
    }

this commit merges the logic of "check ticket's current owner too" for Take/Steal
into RT::Ticket::CurrentUserCanSetOwner.

see also #28211

A value for Sign or Encrypt of undef is an indication of "do whatever
the queue's options say."  d3341b78 resolved a bug of inserting array
references into X-RT-Sign, but in doing so lost the possibility to pass
undef into ProcessUpdateMessage, and have the queue default kick in.  In
practice, this is only relevant if the signing controls were not
submitted, but customizations may do so.

now we record the forward transaction with customized message and use a scrip
bound to it to actually send the message.
(SendForward action is newly added for it)

This commit resolves a TODO from RT::Ticket that moves code that
sets a ticket status to open to a Scrip for upgrading users. The
functionality is removed for new installs.

See issues#17474

Originally added in f7678052, the only callsites for it were removed in
c9a3dd60 and ec4507ba.  Remove the uncalled method.

Roles are in the singular declension; thus support and encourage
->Requestor for consistency.

Many classes cargo-cult similar code; push the common simple
implementation into RT::Record, and remove all straightforward alternate
definitions.

Statuses returned by RT::Lifecycle or RT::Ticket->Status are in
canonical case rather than guaranteed lower case.  When comparing
statuses, both operands should be lowercased.

The default templates embed the ticket's subject in the outgoing Subject
header -- but have no way to ensure that the subject does not contain
newlines, which could be used to insert additional headers.
Programmatically restricting templates from inserting newlines in the
header section is both difficult and overly limiting, as there are valid
reasons to do so.

Strip all newlines from Subject headers.  While this does resolves the
issue for all core RT templates, solving it more generally is
unfortunately not feasable.

When normalizing lifecycle configurations, use the original case that
they were written in for display.  This allows code which depended on
the apparent casing of $ticket->Status to still continue to function,
even while the back-end status is stored in lower-case.

For simplicity of look-up, keys of the lifecycle are stored in
lower-case, while lists of statuses are stored in their canonical case.

Prior to the merge of lifecycles (in 2ad74ba2), statuses were fully
case-sensitive.  This meant that attempts to set the status to 'OPEN'
would fail, as the case did not match the supported 'open' status.
Lifecycles made checks for _validation_ of statuses case-insensitive,
but did not spread that property to many other parts of the system --
including rights, transitions, and searching.

Canonicalize all statuses to lower-case in the database, and make the
remaining entry points into the API lower-case as well.  This also
requires checking that all statuses described in lifecycles are
correctly in lower-case.  While using perl 5.16's "fc" operator would be
more correct in this case, this is not possible on all versions of Perl
that RT currently runs on.

Make public and rename to CurrentUserCanSetOwner to make it
consistent with other CurrentUserCan method names.

Meld _IsProposedOwnerChangeValid into CurrentUserCanSetOwner to
handle all of the logic in one place and provide a single
response from CurrentUserCanSetOwner. This simplifies SetOwner
and makes CurrentUserCanSetOwner suitable for calling to test
for owner change permissions in the context of the current
ticket.

The three values for Type that RT uses internally are 'ticket',
'approval', or 'reminder'; for the most part, these are not exposed to
the user.  The exception to this is when generating approvals, as the
CreateTickets action requires the user to specify the Type of the ticket
created.  Improper casing on the "approval" type is a common, and
frustrating, mistake.

Be liberal in what case RT accepts for its core types, but consistently
use lower-case in those values when they are stored.  As external
systems may rely on case-sensitivity of non-core values for Type,
preserve the case sensitivity of those values.

Users have frequently requested the ability to change the owner on
a ticket that already has an owner. Previously RT required you to own
a ticket to change the owner, so you had to steal a ticket owned by
someone else, then set the owner. The new ReassignTicket right allows
users to change owner directly (reassign tickets).

Most of queries on Tickets has id == EffectiveId condition
that is required to skip merged tickets. Usually percentage
of merged tickets is very low, so this condition is true.
However, DBs like Pg and Oracle estimate number of returned
records very wrong. Each column is very distinct and statisticly
speaking chance that one record has the same value in id and
EffectiveId is low, but this is only true when correlation
is not accounted and it's not accounted in mentioned DBs.

We add IsMerged column with "boolean" type that reflects
id != EffectiveId. It fixes estimations of DB optimizers.
Query execution plans get better.

Instead of adding the column we could use NULLs in EffectiveId
for records where now id = EffectiveId, but this means ORed
conditions in JOIN clause for rare queries. Tests show that
such solution result in terrible perfomance degradation on
mysql in these rare situations.

1) merge shouldn't generate any transactions except merge
2) recording Time* change transaction mess numbers in history.
   As target ticket gets all transactions from both sides then
   history is already correct. Yes, numbers in the history are
   strange, for example you can have two txns saying time worked
   was changed from 0 to X and from 0 to Y, but the difference
   is what's important and is correct.

to make it easier to build stats and for consistency

use __Value to avoid ACL checks as User may not have rights
to see newly created tickets.

it was hard to understand code when it was calling
SUPER functions. Use "local" methods, just avoid
things we don't need - acl checks and a new transaction.

FromURI always sets a resolver, even on failure.  Error checking which
only looks at ->Resolver is broken and checking ->Scheme on top of that
is just patching over the bug and relying on the internals of
RT::URI::base.  FromURI returns a useful success or failure value; just
use that.