Merge branch '5.0-trunk'

Dockerfile

@@ -1,6 +1,6 @@
 # This Dockerfile is for testing only.
 
-FROM bpssysadmin/rt-base-debian:RT-5.0.4-buster-20230703
+FROM bpssysadmin/rt-base-debian:RT-5.0.5-buster-20231215
 
 ENV RT_TEST_PARALLEL 1
 ENV RT_TEST_DEVEL 1

bin/rt-crontool.in

@@ -391,11 +391,11 @@ as cron.
 
 Security:
 
-This tool allows the user to run arbitrary perl modules from within RT. If
+This tool allows the user to run arbitrary Perl modules from within RT. If
 this tool were setgid, a hostile local user could use this tool to gain
-administrative access to RT. It is incredibly important that nonprivileged
+administrative access to RT. It is incredibly important that non-privileged
 users not be allowed to run this tool. It is suggested that you create a
-non-privileged unix user with the correct group membership and RT access to
+non-privileged Unix user with the correct group membership and RT access to
 run this tool.
 
 

bin/rt-mailgate.in

@@ -328,7 +328,7 @@ Usual invocation (from MTA):
 
 =item C<--action>
 
-Specifies what happens to email sent to this alias.  The avaliable basic
+Specifies what happens to email sent to this alias.  The available basic
 actions are: C<correspond>, C<comment>.  Additional actions, such as
 C<take> or C<resolve>, may be available depending on your local
 C<@MailPlugins> configuration.
@@ -372,7 +372,7 @@ This flag tells the mail gateway to trust all SSL certificates,
 regardless of if their hostname matches the certificate, and regardless
 of CA.  This is required if you have a self-signed certificate, or some
 other certificate which is not traceable back to an certificate your
-system ultimitely trusts.
+system ultimately trusts.
 
 =item C<--extension> OPTIONAL
 

devel/tools/rt-apache

@@ -248,7 +248,7 @@ of that list which exists will be used.  See also L</--modules>.
 
 =item --port B<number>, -p
 
-Choses the port to listen on.  By default, this is parsed from the
+Chooses the port to listen on.  By default, this is parsed from the
 F<RT_SiteConfig.pm>, and falling back to 8888.
 
 =item --ssl [B<number>]

docs/UPGRADING-3.6

@@ -3,7 +3,7 @@
 As there are a large number of code changes, it is highly recommended that you
 install RT into a fresh directory, and then reinstall your customizations.
 
-The database schema has changed significantly for mysql 4.1 and above; please
+The database schema has changed significantly for MySQL 4.1 and above; please
 read UPGRADING.mysql for more details.
 
 The configuration format has been made stricter. All options MUST be set using

docs/UPGRADING-4.0

@@ -54,8 +54,8 @@ lists.
 
 =head2 Upgrading sessions on MySQL
 
-In 4.0.0rc2, RT began shipping an updated schema for the sesions table that
-specificies a character set as well as making the table InnoDB.  As part of
+In 4.0.0rc2, RT began shipping an updated schema for the sessions table that
+specifies a character set as well as making the table InnoDB.  As part of
 the upgrade process, your sessions table will be dropped and recreated with
 the new schema.
 
@@ -80,7 +80,7 @@ You can run this as
 
   /opt/rt5/etc/upgrade/upgrade-articles
 
-It will ouput a lot of data about what it is changing.  You should review this
+It will output a lot of data about what it is changing.  You should review this
 for errors.
 
 If you are running RTFM 2.0 with a release of RT, there isn't currently an
@@ -119,7 +119,7 @@ with duplicate names.  Running
 will report duplicate group names, and running it with --resolve will fix
 duplicates by appending the group id to the name.
 
-Nota Bene: As a result of differing indexes in the schema files, Postgres and
+Nota Bene: As a result of differing indexes in the schema files, PostgreSQL and
 SQLite RT databases have enforced group name uniqueness for many years at the
 database level.
 
@@ -173,7 +173,7 @@ The 3.9.2 upgrade step removed all enabled Personal Groups, but missed
 any disabled groups. We catch and clean up the disabled Personal groups
 during the 4.0.9 upgrade step.
 
-=head2 Javascript Changes
+=head2 JavaScript Changes
 
 If you have set a custom @JSFiles in RT_SiteConfig.pm, you will need to
 amend this to include the new jquery.cookie.js file added to

docs/UPGRADING-4.2

@@ -322,7 +322,7 @@ issues with blank outgoing emails.
 =head1 UPGRADING FROM 4.2.10 AND EARLIER
 
 The C<$DatabaseRequireSSL> option has never affected whether the
-database connection was performed using SSL, even under Postgres; the
+database connection was performed using SSL, even under PostgreSQL; the
 functionality can now be implemented via C<%DatabaseExtraDSN>.
 C<$DatabaseRequireSSL> has been removed, and setting it will trigger an
 informational message that setting it is ineffective.

docs/UPGRADING-5.0

@@ -54,7 +54,7 @@ change touches large RT tables like Transactions and Attachments, this
 upgrade step may take a while to run.
 
 You also will need free disk space equal to the size of these tables
-while running because MySQL, MariaDB, and Postgres will create a
+while running because MySQL, MariaDB, and PostgreSQL will create a
 temporary copy of the table while running. If you don't have sufficient
 space, it can cause this step to fail.
 
@@ -147,7 +147,7 @@ configuration option. This may also help other areas of RT in addition to
 searches.
 
 We are investigating options to improve the underlying queries. Some users have
-reported improved performance with the following indexes, at least on Postgres:
+reported improved performance with the following indexes, at least on PostgreSQL:
 
    CREATE INDEX ACL2 ON acl (objecttype, objectid);
    CREATE INDEX ACL3 ON acl (principalid, rightname, principaltype);
@@ -239,7 +239,7 @@ will migrate your existing tokens to the new core RT tables.
 =item *
 
 The extension C<RT::Extension::FormattedTransaction> was added to core. This
-adds a new RT dependency on the perl module L<Text::WordDiff>, so you will be
+adds a new RT dependency on the Perl module L<Text::WordDiff>, so you will be
 prompted to install this new module if your system doesn't have it.
 
 =item *
@@ -406,7 +406,7 @@ so batch runs only once for the outermost updates. All transactions
 performed for that batch are available from the C<TransactionBatch> method
 as expected.
 
-=item * Ambigious Owner order by option in search replaced with Owner.Name
+=item * Ambiguous Owner order by option in search replaced with Owner.Name
 
 RT 4.4.5 adds a bunch of new order by and format options for users and roles
 to the Query Builder. For example, you can order by user fields on a user
@@ -510,7 +510,7 @@ we have added the new option C<$EmailDashboardInlineCSS> to inline the
 CSS. We have found this reduces the size of the dashboard emails
 significantly and can help with rendering in some email clients.
 
-To use this new feature, you must install the optional perl module
+To use this new feature, you must install the optional Perl module
 L<CSS::Inliner>, version 4018 or later, then enable the feature in
 your RT configuration.
 

docs/authentication.pod

@@ -86,7 +86,7 @@ the matched user.
 It is often used to provide single sign-on (SSO) support via Apache modules
 such as C<mod_auth_kerb> (to talk to Active Directory).  C<$WebRemoteUserAuth> is
 widely used by organizations with existing authentication standards for web
-services that leverge web server modules for central authentication services.
+services that leverage web server modules for central authentication services.
 The flexibility of RT's C<$WebRemoteUserAuth> support means that it can be setup
 with almost any authentication system.
 

docs/charts.pod

@@ -15,7 +15,7 @@ when we converted the web chart library to Chart.js.
 =head2 C<$EnableJSChart>
 
 Starting in RT 5.0, by default charts are rendered by Chart.js,
-a javascript charting library. If you'd like to disable javascript
+a JavaScript charting library. If you'd like to disable JavaScript
 rendered charts, you can set this configuration value to false. To use
 GD charts instead of JS charts, set the C<--enable-gd> option
 when running the configure script to install RT.

docs/customizing/lifecycles.pod

@@ -16,7 +16,7 @@ The web interface allows for easy visualization and editing of lifecycles.
 =head2 Editing statuses, transitions and categories
 
 Instructions for interacting with the web UI lifecycle builder can be found on the main "modify" page.
-The modify page allows for create and deleting statuses, adding transistions between statuses with
+The modify page allows for create and deleting statuses, adding transitions between statuses with
 drag and drop arrows and changing the categories of a status (initial, active and inactive).
 
 =for html <img alt="Lifecycle UI Modify" src="../images/lifecycle-ui-modify.png">

docs/dashboards.pod

@@ -170,7 +170,7 @@ the dashboard.
 
 All members of the Accounting group should now have access to your dashboard. 
 They can now add it to their Home menu if they want. If other members can't see 
-it, make sure you have granted sufficent rights to the group (see L</"Dashboard 
+it, make sure you have granted sufficient rights to the group (see L</"Dashboard 
 Rights">).
 
 =head2 System-wide Dashboards

docs/email_management.pod

@@ -64,7 +64,7 @@ refine this behavior, RT also has the options L<RT_Config/LoopsToRTOwner>
 and L<RT_Config/StoreLoops>.
 
 Bounces usually result from some issue with a recipient address. This could
-be a typo in the email address itself, or the receipient may no longer be at
+be a typo in the email address itself, or the recipient may no longer be at
 that company so their email account is inactive. The solution for these
 cases is to fix the incorrect email address on the RT user record or remove
 the user with the inactive email address from the ticket so RT will stop

docs/extending/clickable_links.pod

@@ -28,7 +28,7 @@ This action is enabled by default.
 =back
 
 RTIR, an RT extension for CERT teams (not installed with core RT),
-shipps with several additional actions you can use: C<ip>, C<ipdecimal>,
+ships with several additional actions you can use: C<ip>, C<ipdecimal>,
 C<email>, C<domain> and C<RIPE>.
 
 =head2 Order of actions
@@ -43,7 +43,7 @@ actions always match the same pieces of text.
 
 Each action consists of regular expression and function that does text
 replacement.  When you open the history of a ticket, RT searches in the
-text with the given regular expresion for matches. If it finds a match,
+text with the given regular expression for matches. If it finds a match,
 it calls the function with the match as the argument, then replaces the
 matched text with the string returned by the function.
 
@@ -123,7 +123,7 @@ And arrayref with all of the match's capturing groups; for example if
 your regexp is C<qr{ticket\s+#(\d+)}>, then the first element will be
 full match ("ticket #XXX"), the same as in 'value' key, but the second
 element of the array will be the id of a ticket (XXX).  Using this, you
-can avoid reparsing the value in the action.  Only the first eight
+can avoid re-parsing the value in the action.  Only the first eight
 groups of your regexps are passed to action.
 
 =back

docs/extending/external_custom_fields.pod

@@ -71,7 +71,7 @@ Here's a simple static example:
   # define class inheritance
   use base qw(RT::CustomFieldValues::External);
 
-  # admin friendly description, the default valuse is the name of the class
+  # admin friendly description, the default values is the name of the class
   sub SourceDescription {
       return 'My Source';
   }

docs/extending/mail_plugins.pod

@@ -169,7 +169,7 @@ restrictions on the email gateway.
 Only the I<first> action (if there are more than one defined) is
 checked, as the process of completing the first action might affect the
 later actions; consider the case of C<take-correspond>, where the
-C<correspond> action might only be avilable to owners.
+C<correspond> action might only be available to owners.
 
 Each plugin defining this method is called in turn; as soon as one
 plugin returns true, the rest are short-circuited.  Arguments include:
@@ -234,7 +234,7 @@ object with no C<id>.
 =item TicketId
 
 The value id that was extracted from the subject; this allows a
-non-existant ticket id to be differentiated from no subject id, as both
+non-existent ticket id to be differentiated from no subject id, as both
 will present as having an unloaded C<Ticket> argument.
 
 =item Queue

docs/extending/using_forms_widgets.pod

@@ -7,7 +7,7 @@ request arguments and allow developers to avoid reinventing the wheel.
 
 Each component shows widget by default and has two methods: Process and 
 InputOnly. The first one method process arguments and return new value
-of a parametr. The second one is helper that shows only form elements
+of a parameter. The second one is helper that shows only form elements
 with minimum of required text labels.
 
 So you show a widget with:
@@ -29,7 +29,7 @@ of value between form reloads (see below).
 
 =head2 Processing
 
-Processing is required when you use L<extended features|/Extendent features>,
+Processing is required when you use L<extended features|/Extended features>,
 such as Default, Multiple or Alternative.
 
 To process arguments of a request you have to do the following:
@@ -44,7 +44,7 @@ a canonical form is different and depends on activated features, so you must
 always activate the same features during showing a widget and processing
 results.
 
-=head2 Extendent features
+=head2 Extended features
 
 =head3 Default value
 
@@ -75,8 +75,8 @@ preference record instead of updating it (default value may change later to).
 =head4 C<DefaultValue> when C<Default> is not active
 
 DefaultValue argument is still actual in the Process method even if
-C<Default> is not true. This argument defines intial value. If value
-of a key in Arguments is not defined then it's treated as intial state
+C<Default> is not true. This argument defines initial value. If value
+of a key in Arguments is not defined then it's treated as initial state
 and the method returns default value.
 
 =head3 Multiple and Alternative

docs/extensions.pod

@@ -3,7 +3,7 @@
 RT has a lot of core features, but sometimes you have a problem to solve
 that's beyond the scope of just configuration. The standard way to add
 features to RT is with an extension, or plugin -- RT uses the terms
-interchangably.
+interchangeably.
 
 =head1 Finding extensions
 

docs/full_text_indexing.pod

@@ -13,11 +13,11 @@ know how to tokenize C<latin-1>-ish languages where words are separated
 by whitespace or similar characters; as such, support for searching for
 Japanese and Chinese content is extremely limited.
 
-=head1 POSTGRES
+=head1 POSTGRESQL
 
 =head2 Creating and configuring the index
 
-Postgres 8.3 and above support full-text searching natively; to set up
+PostgreSQL 8.3 and above support full-text searching natively; to set up
 the required C<ts_vector> column, and create either a C<GiN> or C<GiST>
 index on it, run:
 
@@ -114,7 +114,7 @@ not necessarily adjacent), use C<Content LIKE '+winter +2014'>.  To find
 transactions containing the precise phrase, use C<Content LIKE '"winter
 2014">.
 
-See the mysql documentation, at
+See the MySQL documentation, at
 L<http://dev.mysql.com/doc/refman/5.6/en/fulltext-boolean.html>, for a
 list of the full capabilities.
 

docs/hacking.pod

@@ -46,7 +46,7 @@ Branches should be reviewed by another developer before being merged.
 Reviewers should make sure that the branch accomplishes what it claims
 to, and does not introduce any unwanted behavior in doing so.  Commit
 messages explain the B<why> as much as the B<what> of each commit, and
-not include extranous changes.
+not include extraneous changes.
 
 
 =head1 Code conventions
@@ -116,7 +116,7 @@ Because C<loc()> and C</l> are used to generate strings for human
 eyes, they generally must be used "close to the browser". These are
 directly in Mason templates, or in functions that return text that
 will be passed through Mason. However, in many places in RT we have
-hardcoded strings which need translations. For example, the C<$RIGHTS>
+hard-coded strings which need translations. For example, the C<$RIGHTS>
 hash in F<lib/RT/Queue.pm> maps rights' names (which must be
 translatable) to their descriptions (which also must be translatable).
 However, when we're declaring such structures, we do not want to
@@ -189,7 +189,7 @@ before running tests.  To do this in place without installing:
     make fixdeps
 
 Adjust the relevant database options as necessary if you want to test on
-Postgres, Oracle, or SQLite.  The default is MySQL/MariaDB.
+PostgreSQL, Oracle, or SQLite.  The default is MySQL/MariaDB.
 
 To run the test suite:
 

docs/initialdata.pod

@@ -203,7 +203,7 @@ C<MaxValues>.
 
 =item C<LookupType>
 
-Labeled in the CF admin page as "Applies to".  This determines whether your CF
+Labelled in the CF admin page as "Applies to".  This determines whether your CF
 is for Tickets, Transactions, Users, Groups, or Queues.  Possible values:
 
     RT::Queue-RT::Ticket                    # Tickets