We’re happy to announce two new releases now available for testing: RT 5.0.0 beta 2 and RTIR 5.0.0 beta 1. As with earlier versions of RTIR, you must run it with a compatible version of RT. For the current test releases, RTIR 5.0.0 beta1 needs RT 5.0.0 beta2.
This is the first beta for RTIR, so if you are an RTIR user this is your chance to jump in and confirm the new versions work with your data and configurations. As with RT, we’re still working on release notes, but here are a few key things you’ll notice:
The theme is updated to work with RT’s new elevator-light and elevator-dark.
We restored the RTIR menus to the single menu rather than converting to queue-based menu items clicking into RTIR. The menu is also right next to Home now so it’s easier to find.
You can now select queue on the ticket create page like RT.
A few notes on testing the betas:
As noted previously, install RT 5 and RTIR 5 in a fresh directory, not on top of an existing /opt/rt4. Then import and upgrade your database. We changed a lot of files and installing over older RT 4 directory will result in problems. You can copy over your existing RT_SiteConfig.pm and any other files with configuration and customization.
If you have tested previous betas, it’s best to re-import your DB backup and run the full upgrade-database steps again. We add to and change the DB upgrade steps with each beta, so just updating the code from a previous beta will miss key DB upgrade steps.
We’re still working on a fix for the segmentation faults on MariaDB 10.3 and later, it’s not addressed yet in this beta2 release.
If this is the first beta you are testing, check out the previousannouncements for other notes.
We’re getting very close to final releases, so get your bug reports in soon if you want us to look before 5.0.0 goes out. Thanks to everyone for bug reports so far, it really helps!
We’ve been playing with RT5 beta 2 for a while now, and have just exposed one of our service desk folk to the test instance here. They’ve immediately noticed that they don’t see the list of knowledge base articles to pick from when replying to a ticket. They have a load of articles in a class applied to their queue (no topics in use - it’s just a flat list of stock answers for them to pick from). We’d not noticed this as third line support teams like ours don’t have stock answers so don’t use articles like this.
I’ve had a look and we have the articles in our database (which is derived from our live instance with existing tickets removed) and, if we set the configuration option HideArticleSearchOnReplyCreate to zero, we can search for and find the articles associated with their queue. But with HideArticleSearchOnReplyCreate set to one, there’s no drop down of available hot list articles.
I’ve done a bit of digging and comparing the RT5 and RT4 code, and it looks like there’s a whole section of code been removed from /opt/rt5/share/html/Articles/Elements/BeforeMessageBox that in RT4 generated the selection. Indeed with RT5 we get an empty DIV where that selection should be. I’ve made a hacked local copy of that RT5 code with bits of the RT4 code re-inserted and the article selection reappears, so that shows the articles and class are attached to the queue OK.
Is this a bug that needs reporting? Or has the way we’re supposed to use articles when replying to tickets changed in RT5? If so is there any documentation for that, as its likely to trip up other people that use articles like this for first/second line support teams.
Also I noticed that the RT::Articles library seems to have also lost the LimitHotlistClasses() method, which is used in the RT4 version of this widget. I’ve worked around that but is that something we need to be aware of moving to RT5?
Do you see the “Include Article” entry on reply? We converted the previous three article fields into one. If the number of articles for the current queue are over $DropdownMenuLimit (50 by default) the dropdown will convert to an autocomplete select box where they can start typing an article name. So if they have a bunch, it’s possible that’s what you are seeing. If they prefer to see a long dropdown, you can update that config item or add a value directly using the ModifyDropdownLimit callback.
No, there was just an empty DIV with nothing in it (I took a look with Chrome’s developer tools). My hacked local version based on the RT4 code has put the selection back in place inside that DIV. Should I raise a bug report for this? If so would you like a patch included for what I’ve done to get it back?
Hi, can you confirm that you do not have the HideArticleSearchOnReplyCreate config value set to true? There is also the ArticleOnTicketCreate config option.
We do normally have the HideArticleSearchOnReplyCreate set to 1 (true) in RT4. This is because don’t want the search option for articles but have them appear in the drop down menu for the service desk staff. I set it to 0 (false) temporarily on our test RT5 install just to check that the articles were available to queue if you searched for them and they were.
We didn’t have ArticleOnTicketCreate set under RT4 but trying it in RT5 makes no difference to the layout, probably because we aren’t creating a ticket but replying to an existing one.
Set up a quick test to see if i could force the search box or dropdown state to appear on our testbox. I set $DropdownMenuLimit to 500 to see if I could force the dropdown - nothing. I then set $DropdownMenuLimit to 1 to see if I could force the search box - nothing
Trying out RT 5 (coming from 4.4.1). The c/r hot keys are nice, how about some Javascript to make the input text body in a reply the selected input box and control-enter being the same as hitting “reply”?
This would allow replying/commenting to a ticket without needing to use a mouse in most cases.
Just checking back to this - should I be putting a bug report in or is this working as the Best Practical team expected? I don’t want to clutter your bug tracking tools if this is a major version change that has been made on purpose (we’ll just have to work around it if that is the case - one of the benefits of open source!).
Assuming this is related to the new article display on ticket create/reply, your last reply seems to be in line with how we would expect it to work. That is, set HideArticleSearchOnReplyCreate to 0 (off) and you’ll see “Include Article” on reply/comment pages. If you have more than 50 articles it will show an autocomplete box by default. You can update DropdownMenuLimit to a larger value or add a callback to set the number higher and it will display as a dropdown like you had before. Are any of the above not working?
What would you expect if we have HideArticleSearchOnReplyCreate set to 1? That’s what we normally have (in RT4) and that’s what is not showing us anything. No input widget, selection box, nothing.
Hide will hide the article input, so I expect it to disappear and not be shown. I guess the difference with regard to this option is that previously there were 3 widgets related to articles and this hid only one of them. Now that we have joined them into one, this option controls hiding/showing the single Include Article element which provides both search and dropdown.
Yes, its not just hiding the article search now, but the drop down selection as well.
As I said above I’ve hacked it back into a local copy of the code so it can be fixed (for us). Whether that fix is of interest to you depends if that’s something you’d want to fix or you view removing all article selection/searching when that setting is turned on as a feature now.
There is only one input now that displays as either autocomplete or dropdown, so there is only one thing to hide/show. To show the dropdown, you should be able to disable the Hide and increase the DropdownLimit. You shouldn’t need to hack anything in. Of course if you prefer to hide the default and hack in something yourself, you can do that too.