|
Hello everyone, First of all, thank you for creating and maintaining FreeITSM. We are currently evaluating and using it internally and are very impressed with the overall functionality and clean interface. I have a question regarding search capabilities within the Tickets module. Currently, the ticket search appears to support searching by:
For our daily work, it would be extremely valuable to have a full-text search that can search across:
In addition, it would be even more useful if attachments could be indexed and searched as well, for example:
Many important details are often stored within attachments, and being able to search for keywords inside those documents would significantly improve knowledge discovery, incident analysis, and finding previous solutions. My questions are:
I believe this would be a very valuable feature, especially for organizations with a growing ticket history and large amounts of documentation attached to tickets. Thank you in advance for any guidance and for the great work on FreeITSM. Best regards, |
Replies: 8 comments
|
Hi Daniel This is a really interesting idea and I shall give it some thought. Much of it looks quite straightforward however I would say now that full text search/indexing of ticket contents + attachments is a different beast and so I will have to see what can be done natively with mysql and php and what will require an integration with some other kind of indexing tool. Thanks for the feedback and for your support! Watch this space! |
|
Hi, I have been doing some planning and here is my proposal which I believe will give you what you need: https://github.com/edmozley/freeitsm/wiki/Full-Text-Search I will keep you updated as I begin to implement. Thanks! Ed |
|
Hi, thank you for the quick update! That looks very promising already. Appreciate your fast response on this! Daniel |
|
Hi, Thanks again for this - the first half of this feature is now on main. What you can do now: searching inside tickets. The search window in the inbox has a new Anywhere in the ticket field that looks through every message and every note, not just the subject. Results show a snippet of the text that matched and tell you where it was found - the subject, a message, or a note. So, of your three questions:
To try it Pull the latest main. One thing worth doing - I've made a diagnostic tool to check a database configuration issue which is a pre-requisite for this feauture. Run System → Debug Tools → D007 - Search corpus health once, straight after setting up. It takes about a second. The one that caught me out: there's a limit on how long a word can be, and WAMP ships it set to 10 characters. That silently makes words like authentication, configuration and workstation completely unfindable while shorter words work fine. It looked exactly like a broken feature. D007 spots it and tells you the one line to change. If you're on Docker or a stock MySQL you'll almost certainly be fine, but it costs a second to be sure. Still to do
If you want the detail Searching inside tickets - how to use it Do let me know how you get on, particularly if a search comes back empty when you expected something! Ed |
|
I have one additional question: Will the full-text search also be accessible via the keyboard shortcut CTRL + K? |
|
Hi Daniel @dschipfel , A big update on this one. Three of your four questions are now done, and the fourth is the only thing left. Search now keeps itself up to dateThis is the most important change. Previously the index only updated when someone ran a script by hand, so anything raised since the last run could not be found. That is worse than having no search at all, because you trust it and stop looking. Tickets, replies and notes are now indexed the moment they happen, whether they come from an analyst, the self service portal or by email. A ticket sent to the trash drops out of the index straight away. Finding this turned up a genuine bug worth mentioning, since it may affect you elsewhere: a ticket raised in the portal or arriving by email never announced that it had been created. Only analyst raised tickets did. That means a workflow triggered on "ticket created" has never fired for emailed or portal tickets. That is now fixed, so if you have such a rule configured it will start working. Worth checking what you have before you update. Ctrl+K searches ticket contentYes, and it is in. Press Ctrl+K, type a phrase, and tickets whose messages or notes contain it appear under Found inside tickets. They are listed after the name matches and capped deliberately. The palette is for jumping to a thing, so typing a hostname still takes you straight to that machine rather than burying it under message snippets. Knowledge articles are searchable by their textArticles could previously only be found by guessing a word in the title. Now the whole article is searched, shown under Found inside articles. Drafts are included, since you should be able to find your own unfinished work, and an article in the recycle bin drops out until you restore it. That covers the "knowledge articles" part of your third question. A new screen: System > SearchShows what the index holds, how much of your data is in it, and when it last changed. There is a Rebuild index button so you never need a command line, and it rebuilds in slices with a progress bar so a large installation cannot time out halfway. It also reports the shortest word your database will search for. That single number explains most cases of search mysteriously finding nothing, and it is the setting I mentioned last time that ships wrong on WAMP. Still to do: attachmentsAttachment text is the one item from your original post still outstanding, and it remains the hard part. Reading text out of arbitrary documents needs an optional extra service, and scanned PDFs contain no text at all, only an image, so they need OCR. It is designed but not built. Getting the updatePull the latest main and run System > Database Verification. Then open System > Search and press Rebuild index once to pick up everything you already have. After that it looks after itself. Documentation: Hope you find it useful! Ed |
|
This is now complete. Thanks to everyone who weighed in, and particularly for pushing on the Ctrl+K question, which changed where a lot of this ended up. What you getSearch inside tickets. Message bodies, notes and subjects are all indexed, so a phrase buried in the fourth reply of a two year old ticket is findable. Indexing happens as things are written, not on a schedule, so a ticket raised a second ago is searchable now. Search inside knowledge articles, by their content rather than just their title. Drafts included, because you should be able to find your own unfinished work. Search inside attachments. The contents of a document somebody emailed in are searchable alongside the ticket text. Ctrl+K. Press Ctrl+K (or ⌘K) anywhere and content matches appear under their own headings, Found inside tickets and Found inside articles, kept separate from the name and reference matches so a hostname still takes you straight to that machine rather than burying it under message snippets. System → Search shows what the index holds, lists every attachment by outcome, and has a Rebuild index button that works in slices so a large installation cannot time out half way. Attachments: what works with no extra software at allRead by FreeITSM itself, nothing to install:
The modern Office formats are a zip of XML underneath, so reading them needs no library, just care with the archive. A file is read once and its text stored, so rebuilding the index costs no file reads. Attachments: what needs Apache TikaPDFs are deliberately not parsed in PHP. A half working PDF reader does not fail loudly, it produces plausible nonsense, indexes it and reports success, so you would have a search that appears to cover your documents and silently cannot find them. It would also be parsing hostile input in the process holding your database credentials. The line is drawn on security, not convenience. Connect Apache Tika and these become searchable:
That last row is the interesting one. A scanned document contains no text at all, it is a picture of a page, and so is the photo somebody took of an error message on a machine that was not on the network. Character recognition turns both into words you can search for. Setting it upOne container: docker run -d --name tika --restart unless-stopped \
-p 127.0.0.1:9998:9998 apache/tika:latest-fullThen paste Two details that matter more than they look:
Switching it on automatically queues everything that could not be read before, so existing attachments are picked up without a rebuild. Because PDFs and scans take far longer to read than a Word file, they are done in the background. Tickets → Settings → Indexing decides when: on a schedule, or a few at a time while people are using FreeITSM. Both are on by default, so it works whether or not you run scheduled tasks. Your documents do not leave your buildingThe usual way to add document reading is to upload each file to somebody else's API and pay per page. Tika runs on hardware you control, FreeITSM talks to the address you give it and nowhere else, and your contracts, HR paperwork and scanned delivery notes stay where you put them. It tells you what it could not readNothing reads everything. Some files are corrupt, some exceed the 20 MB limit, some are formats nobody has taught it about. Rather than letting those quietly not appear, System → Search lists every attachment it could not read, by name, with its ticket and the reason. A search with a silent hole in it teaches you to trust something you should not. Documentation
What it does not do yet
Closing this as complete. If you hit anything odd, please open an issue rather than replying here, so it gets tracked properly. |
|
Thanks for the update and for implementing this feature. We still need some time to test it thoroughly in our environment and evaluate how it performs in day-to-day use. Once we've completed our testing and gathered enough feedback from our users, we'll get back to you with our findings and any suggestions we may have. Looking forward to seeing how it works in practice. Thanks again for your continued work on FreeITSM! |
This is now complete. Thanks to everyone who weighed in, and particularly for pushing on the Ctrl+K question, which changed where a lot of this ended up.
What you get
Search inside tickets. Message bodies, notes and subjects are all indexed, so a phrase buried in the fourth reply of a two year old ticket is findable. Indexing happens as things are written, not on a schedule, so a ticket raised a second ago is searchable now.
Search inside knowledge articles, by their content rather than just their title. Drafts included, because you should be able to find your own unfinished work.
Search inside attachments. The contents of a document somebody emailed in are searchable alongside the ticket…