Filter by all fields is relatively hard to do, since search works in a different data storage (Elastic) and it does not index all fields. To make it work, we have to index ALL fields and I am not sure this is viable. We can index some fields, like State, Assignments, and 10 other popular fields and add filters for them. This is relatively easy to do, but still not super easy.
2 Likes
Thanks for the details, this is very good to know to set expectation (i.e. we should not expect all fields ever, or at least not soon). 
That said I do think indexing popular/common fields would be quite nice and helpful to filter on them.
I also don’t want to lose sight of the importance of filtering closed issues in particular. Even if a more general/flexible “filter by common field values” feature were added, I think you’d need some way to preserve last-used or set defaults or something so that e.g. Closed could always be filtered (by default) for those who want that (me and it seems a number of others). That’s why I was unsure if my new post above constituted a different request… Both can be with the same, broader “filter by fields” feature, but “filter closed” could also be implemented on its own. Fibery’s philosophy of flexibility suggests the general implementation, of course. But again keeping in mind the need for good (or customizable) defaults.
Another thought that comes to mind is to wonder why you can filter the contents of a Table or List by any arbitrary field, but you cannot do that with Search. OK, so Search is on indexed content, that makes sense. But it returns a list. You send that list to the “filter table” function and filter it after search perhaps? There is probably some technical reason this does not work, but it makes some sense to me. 
1 Like
One of the big issues I’ve been having is that I can’t search normal text fields which means I have to resort to adding a lot of information into the name via formula as a workaround. Having an expanded search that would index all free text fields would be a great addition.
Further to @Oshyan last comment, I wonder if the filtering of more structured fields like date, single select and workflows could be added on later in the process to refine records returned by elasticsearch. I’m sure it doesn’t work that way but thought I ask.
2 Likes
Oh, one more thing that would be nice to filter on: views. I love that Views can show up in Fibery search (they don’t in ClickUp and it sucks!). But when you have a lot of Views, a lot of Entities, or both (usually the case), it is not so fast to search and jump to the view. At least not as fast as it could be. A simple filter not just for Databases but to limit scope to Views would be 
.
1 Like
Thank you! I am really hoping this can be implemented. I feel like of Fibery gets greater adoption a lot of teams who are used to using comments extensively will need it, too. I am not aware of any Dev Tool that does not leverage comments as a foundation of how you communicate and update around work in motion.
Thanks again!
And just to add my 2 cents to the conversation about what to index in search, I would be happy to have the areas that involve more user-created content that you might forget where it is and could be helped by search:
- Text boxes, what you’re referring to here:
-
Comments (obviously)
-
References
-
Attachments
I think adding the more complex filters to search would be much less useful now than indexing more content.
Thanks again!
1 Like
Can’t really agree there. I already find searching turns up more semi-related things than I would like (they’re related in a technical sense, they have the right word[s], but in the wrong place). Adding in comment indexing would significantly exacerbate that without a way to turn it off.
I’m now working with a team who will be importing nearly 40,000 records all into a single database, so filtering by DB does not help narrow that down. Being able to specify what fields are being searched would be very helpful in this kind of situation and as mentioned it would also go some way to addressing your other request: Seeing “Closed” Entities grayed out in Search Dialog
But I recognize that your particular workflow really would benefit from comments indexing. I guess my teams just don’t work as much that way, which is interesting. Or maybe it’s the type of work being done. 
I think it is not a case of one versus the other. I think indexing all user text content is quite important but totally agree with @Oshyan that as the databases grow, not having ability to filter based on other fields can be very frustrating and can impede your work. I know there are clever work arounds, like jamming everything into the name fields so you can search, but I really hate that approach because you are essentially duplicating information that is already perfectly captured in the system.
I think having a powerful and flexible search implementation alone is critical but it can actually lay the foundation for many other features. For example, I think this could be key to the issue of limiting relations to a subset of data when creating new entities (see this, this and this). And I assume Fibery has most of the pieces figured out since this type of filtering is already possible in views.
I know fibery team is working on a lot of important features right now, so I feel bad for asking for new things. However, I think search is actually foundational to long term success of any of these tools, but it seems to be often something that is added on after the fact and a piecemeal fashion. Most tools are looking at letting you create things with least amount of friction, but when it comes to finding them later, your mileage may vary (not saying that is the case with fibery, just general observation).
3 Likes
What you wrote above @cannibalflea is a really astute way to look at this. To be clear, I’d like to see filters as well as more content indexed, in particular comments as you know. A comprehensive approach to building search would take care of this. And you are right, most tools give lip service to this need. Of the major rival players, Air Table, Coda, and Notion have basically “bolted on” search functionality. So indeed, as you use these tools for a longer time, you can become stuck trying to find your content. I’m sure there is a real opportunity for one of these players - and hopefully it’s Fibery - to differentiate with a top quality search function.
Thanks!
3 Likes