Though we've been focusing lately on more feature work, 'tis the season for bugstravaganzas. And while these aren't quite the same as finding gold coins in your shoe, we do hope they bring a little delight and relief to you today!
We just released fixes for these bugs:
- Search: When the option to show Glossary snippets in search results is enabled, search phrases with certain special characters (such as \) were throwing a 500 error. This was due to an error in our search handling to account for certain restricted characters in glossary terms themselves. We've updated our search logic so that searches with special characters will still properly complete or show a no results found message even with glossary snippets enabled.
- Manage articles: For some of our oldest customers, articles dating from 2014 and 2015 that haven't been updated since their original creation don't have a stored Last Modified Date. When Manage Articles displayed those articles, it was displaying the current date as the Last Modified for these articles, which is about as inaccurate as one can get. We've updated it so if no Last Modified Date exists, the date is displayed as blank instead of today's date.
- Reporting Dashboard: URL redirect article views are not tracked, so they don't ever show up in the Popular Articles report. We've now also removed them from the Published articles with 0 views report, since they won't ever get removed from that report.
- Contact Form: If you selected the multiple email addresses send option, but later switched back to single email address, the contact form submissions were going to the first email address in the multiple email address list. We've updated this so they properly go to the designated single email address.
- Versions: If you had a version Made Visible to Groups and were viewing it in the live knowledge base, clicking the Edit in App link in the future would open the active version in the editor, not the version you were looking at. We've updated this so that it will properly open the version you were viewing in the editor, instead!
- Reader management: If a reader locked their account due to multiple failed password attempts, once an admin unlocked their account, if they had a single additional failed password attempt, their account would appear to be locked in admin. We've fixed this so that once the admin unlocks their account, a reader will have the same full number of failed password attempts before their account is re-locked (and before the admin view displays a warning that the account is locked).
