Search
One of the most challenging aspects of adding search was deciding how to scope the search. Sometimes, you might want to search all of your open projects. Sometimes, you may want to include archived projects. Other times, you may want to just search within a single project. So, depending on the page that you’re on, search will function slightly differently.
If you’re on a project page, the search will limit the results to just that project. However, there’s always a link to expand your search to all projects. Otherwise, if you’re on a global page like the dashboard or account management, Sifter will search all of your open projects. From the results page, you can choose to expand the search to include archived projects.
In addition to being a search box, it’s also an issue shortcut. If you type in an issue number, the issue number exists, and you have access to it, you’ll automatically be taken to the issue page.
Results and Filtering
The search results pages have some selected filtering options that will vary depending on whether you’re searching one project or multiple projects. For instance, since categories can be customized for each project, it didn’t make sense to enable filtering by category when you search all projects.
Additionally, when you’re searching multiple projects, each search result will include a link to the project just below the issue subject. Naturally, if you’re searching within a project, this link isn’t there because it would be redundant.
Technical Bits
While I plan on writing a more in depth blog post about the design and technical aspects, I wanted to share a little bit for the developers out there. We’re using Sphinx and Thinking Sphinx. We’re taking advantage of delta indexing so that search results are immediately available, re-indexing every couple of hours via a cron job, and keeping an eye on the search daemon with Monit.