The upgrade steps remove the hotlist configuration from your RT database by removing that column from the Articles table. To prevent articles in a class from appearing for a queue, you can unapply the class from that queue. ![]() With this simplified interface, the "hotlist" feature is no longer needed as all articles in classes applied to a given queue are available in the dropdown/autocomplete field. This dropdown converts to an autocomplete box when the dropdown contains more than $DropdownMenuLimit items. The articles interface on tickets has been simplified, now showing only a dropdown for selecting articles. The variables which alter the set of HTML elements allowed in HTML scrubbing have moved they have been renamed, and are now found under RT::Interface::Web::Scrubber. ![]() If you prefer to keep all configuration in files and disable editing in the web UI, set this option to 0: Set($ShowEditSystemConfig, 0) Changes made via the web UI take precedence over file-based options if both are set. File-based configuration options are still loaded. System configuration options can now be changed by SuperUsers via the web UI. If you don't have sufficient space, it can cause this step to fail. You also will need free disk space equal to the size of these tables while running because MySQL, MariaDB, and Postgres will create a temporary copy of the table while running. Because this change touches large RT tables like Transactions and Attachments, this upgrade step may take a while to run. The Id field in some tables is changed from INT to BIGINT to accommodate large RT systems that may hit the maximum number of ids. See README.MySQL and README.MariaDB for details. Database Changesįor MySQL and MariaDB, the default character set has been updated to utf8mb4 to accommodate more unicode characters including emojis. See docs/writing_extensions.pod for more information. If you have changes made directly to the RT code, it's a good time to look at the hooks RT provides for custom code in extensions or in the local directory. Installing a fresh code base will also allow you to evaluate your local modifications and configuration changes as you migrate to 5.0. These old files will still be detected by RT in some cases and will cause issues. We moved some things to new locations and old files are not removed as part of the upgrade process. We recommend this approach because of the large number of changes to the code base for this major release. Then import your existing database and run the database upgrade steps using make upgrade-database. Instead, do a fresh install into /opt/rt5 (or your custom location) for the code portion of the upgrade. Upgrading to RT 5 over an existing RT 4 installation (/opt/rt4) is not recommended and will almost certainly cause issues. Alternatively, you could import a backup of your database as rt5 to conform to the new default, although this isn't required. If you are upgrading, you will likely want to specify that your database is still named rt4 or even rt3. ![]() RT now defaults to a database name of rt5 and an installation root of /opt/rt5. See devel/docs/UPGRADING-5.0 for internals changes relevant to extension writers, including deprecated code. Read this section carefully before you upgrade and look for changes to features you currently use. The following lists some of the notable changes, especially those that might require you to change a configuration option or other setting due to a change in RT. The 5.0 release is a major upgrade and as such there are more changes than in a minor bugfix release (e.g., 4.4.0 to 4.4.1) and some of these changes are backward-incompatible.
0 Comments
Leave a Reply. |