RT 5.0.0 Alpha 1 Now Available

The initial alpha release of RT 5.0, the next major version of Request Tracker, is now available for testing. You can download here:

https://download.bestpractical.com/pub/rt/devel/rt-5.0.0alpha1.tar.gz
https://download.bestpractical.com/pub/rt/devel/rt-5.0.0alpha1.tar.gz.asc

SHA-256 sums

53e47171b1713339d1756e1dcbb22be811f460a61f8629f73836a21ea2d4f0ce rt-5.0.0alpha1.tar.gz
5b84d7e6cc5d9884465cbac70a2f4580b99c9f8a04d53d593ab891f3f7e10652 rt-5.0.0alpha1.tar.gz.asc

As an early testing release, we don’t yet have a detailed set of changes and release notes. Look for those as we progress toward beta. Thanks for testing!

Update: We added an important note to the upgrade documentation recommending that RT 5 be installed fresh rather than using the typical upgrade step on RT 4.x to avoid issues with older files that have been moved. Thanks to the early testers who stumbled on this issue.

10 Likes

A really nice move for 2020, congratulations for your hard work for the frontend and all the little time savers… this 5.0.0 will be a hit for sure !

1 Like

Hi Jim, Rafael, could you show us screenshots, please! Our RT team doesn’t have time to install it in the next few days, but we are very interested in the new version!

We’ve started to have a play with it on a test server.

First thing we found was that the make upgrade-database needs a lot of disc space available if you have a big database with lots of large attachments in it. We chewed through more than 27GB before it fell over through lack of disc space. The culprit was the 4.5.1->4.5.2 step that does an ALTER TABLE `Attachments` CONVERT TO CHARACTER SET utf8mb4;. Folk need to make sure that they’ve either reduced the size of their attachments table using the shredder before doing the upgrade or have a large amount of free disc space available for the process to work (on the same disc that your MySQL/MariaDB database is held in).

Next up I tried to implement the README.MariaDB instructions on our CentOS7 test machine (which has MariaDB 10.4.11). It didn’t like the option in [client-server] (said it was an unknown variable) and I ended up using bastardised version of the README.MySQL instructions using the MariaDB specific sections in the /etc/my.cnf.d/* files that Redhat/CentOS provides. Seems to work OK after that:

MariaDB [rt4]> SHOW VARIABLES WHERE Variable_name LIKE 'character\_set\_%' OR Variable_name LIKE 'collation%';
+--------------------------+--------------------+
| Variable_name            | Value              |
+--------------------------+--------------------+
| character_set_client     | utf8mb4            |
| character_set_connection | utf8mb4            |
| character_set_database   | utf8               |
| character_set_filesystem | binary             |
| character_set_results    | utf8mb4            |
| character_set_server     | utf8mb4            |
| character_set_system     | utf8               |
| collation_connection     | utf8mb4_general_ci |
| collation_database       | utf8_general_ci    |
| collation_server         | utf8mb4_general_ci |
+--------------------------+--------------------+
10 rows in set (0.001 sec)

We’ve got loads more testing to do, mostly to see what of our many local extensions and tweaks will need adjusting for RT 5.0.0. One thing we’ve noticed for example is that our “quick ticket” button arrays will need some CSS style tweaking as they’ve gone from horizontally space in RT 4.4.x to a single vertical column in RT5.0.0alpha1. Not a biggie but its that sort of stuff we’re hoping to catch.

The UI seems to be nice and clean and may help us ditch some of our local hacks (which is nice). Well done Best Practical folk - looking very promising.

3 Likes

Congrats. looks much better then the last preview i tried out. great work so far. No happy testing from my side :wink:

OK, just one hint, or better a wish.
can you add a search box for Customfields at the admin part? Searching for CF.id and/or name would be great and then, on the Applies to part, another search box for queues etc would also be fine, as we have several thousand queues and clicking all the time trough all this is no fun,

Same on the Queue Config -> Customfields, also a search box would be very useful…

Torsten

Was the extra space needed around 2x the size of the current attachments table? We have seen this with upgrades in the past and with setting up full-text indexing. MySQL appears to make a fully copy in the process of applying some kinds of changes. We often plan for 3x disk space, at least for the period while running the upgrade. Depending on the changes, the configured temp directory can also need extra space. Once the upgrade is complete, much of that space can be removed as it isn’t needed for normal operation.

Thanks very much for testing!

We didn’t check the sizes but that sounds reasonable, as we had to remove all the attachments over 10MB in size before the make upgrade-database would work OK. Whilst it was running we did see it consume many gigabytes of storage still, but they were returned as free space as soon as the upgrade had completed.

Another little issue we’ve spotted may be a problem charting dates that we’ve submitted as a proper RT5 bug.

Yes, it looks like we required 2x the size of the attachments table.

Does changing the Attachments table to utf8mb4 mean that MariaDB/MySQL will be able to do FullText searches without the AttachmentsIndex table? Does it mean it will be on by default?

The main issue the utf8mb4 change fixes for MySQL/MariaDB is inserting 4-byte characters in the database. While this includes characters in some languages, the primary use case we heard from users was some emojis would cause errors with the previous utf8 configuration. Now you can use all the emojis you want.

Using the database full text search still requires the extra table. We create a separate table because the fulltext indexes supported by the DB work on textual data. The RT attachments table can have content that isn’t textual, so we create a separate table with just textual data that will benefit from the index.

1 Like

Any expectations on an RTIR alpha to go with this or should 4.0.x continue to work?
Asking before I start spinning up a test box.

We’re hoping to have an updated RTIR for beta, so nothing to test there just yet.

A demo site is now available so you can take a look.

1 Like

Ooh. It’s even populated with a 1000 lawyer-ipsum tickets.

Hi Jim,
couldn’t remind the URL for the Translations anymore. Just did a tiny check and i would like to support a little with german translation.

Torsten

We manage the translations on the Canonical launchpad site here: https://launchpad.net/rt. Version 5.0 isn’t listed there yet, but we’ll add it when it gets closer to release. Changes to the 4.4 series get pulled forward if you want to make updates there.

If you want to work specifically on new translations that apply only to 5.0, I would suggest waiting for at least beta since things can still change, including text, labels, titles, etc.

Is there any info about an API? Will it use the currently developing REST2 or something entirely new is planned?

The current alpha release does not have REST 2 included, but we plan on adding it to core before the final 5.0.0 release.