Add filter for "closed" entities in all searches (and/or other indicator of entity status)

The more I actually use Fibery day-to-day, the more tasks I complete, and the more “closed” entities I end up with. Yet they all still show up in my searches. This really limits the usefulness of search at times, whether in the Ctrl-K pop-up or in-line entity linking (this is even more of an issue due to Narrow texts in entity search pop-up make correct selection difficult.

I’m not sure the best way to handle this. I know the “status” is a feature of the Workflow Extension. It seems important enough and often used enough that perhaps it deserves its own option in the search dialog, and one which could be persistent, i.e. I don’t have to check it on every search. It could instead be in Preferences for each user somewhere, I guess, but with an optional override on the search window (i.e. the setting controls the default state).

Of course given the power and flexibility of Fibery, one could also imagine value in more general filtering based on the state of given fields, and being able to persist that. Honestly this seems like potential overkill to me though, or at least hard to imagine how to easily implement it (actually I just had some ideas, ask me for details if it seems important enough to discuss further).

At the least I think starting with an ability to enable default filtering out of “closed” (or user-selectable status?) entities would be very helpful.

Btw I know this has been talked about before elsewhere, but I couldn’t find a separate topic for it.

1 Like

The more I think about this as I am using Fibery, the more I think it might be good to be a global setting of some kind. For example I’d also like to have this filtering for back-links! And having to add filter controls to search and backlinks, and maybe other places may be non-ideal, or at least may be down the road for implementation. I have a thought as to how it might work though, still being customizable and flexible, but without making the UI too complex. These are just ideas, of course.

So what if you put the visibility setting for entities of a given status within the Workflow Extension settings? There are at least two ways this could be handled, I think. One potentially more powerful or “clean” (or maybe easier to implement?) than the other, but less “discoverable”.

First, you could simply add visibility control to the Workflow Extension settings panel. This could take the form of a more rigid and simple toggle “hide “Completed” entities from searches”, and maybe a separate toggle for “Hide completed entities from backlinks”. OR more powerfully, have a multi-select field there to select from the actual workflow options above, so you’d have one multi-select field “Hide these Statuses from Searches by Default” and another “Hide these Statuses from Backlinks”, and you could select “Closed”, but also any other status you want. If multi-select is hard to implement for this, it could be a single select. If more power is desired…

You could instead implement the same/similar within each Status Option (Alt-Click to reach settings from within a given Entity). So within e.g. “Closed” you’d have the existing options, Color and Icon, and then toggles for “Visible by default in searches” and “Visible in backlinks”. I thought this might be more powerful, but now I think about it, the multi-select above should accomplish the same thing, and may be the better approach unless it’s not possible, or you need to have more controls for different areas where you want to control entity visibility by status.

In either case, on any Search pop-up, perhaps have a toggle “Disable all filters”. This would work well as long as the preferred and most common filter state was set on each Workflow Extension for each Type, which I think is a good way to handle it. Then if you really need to access an old, closed entity, you can, it’s a little more inconvenient, but more importantly the most common use case is much more convenient, and also configurable on a per-type basis.

1 Like

I can think of an analogous use case that I have: filtering on approval status.
We often have items that undergo a workflow of draft, reviewed, approved. Limiting to only approved items would be great.

(to be honest, it ties in with version history as well, which i think has been discussed elsewhere, but that’s another story :slight_smile:)

2 Likes

This kind of touches on something I’ve made a request on (outside the forum): to be able to display certain fields in search results, like with fields you select to show in the collection.


Depending on the type, certain fields would be incredibly useful to see inside search results.

3 Likes

Ah interesting, yeah I can see the potential value in it. Especially when we are (hopefully) able to search in any field contents.

So I guess it would work the same, a toggle would be added to every Field “Show in search results” or something? The main challenge might be in the design of the Search box(es), especially for in-line search. The Quick Search popup has more room as it is…

1 Like

Agree 100%! I would expect in most good search tools in advanced Work Mgmt apps that you’d get an array of bespoke filters, layers, etc. of search, that you should be able to save as well and return to. “Closed” items have a certain property in Fibery, which is great as this is another area it has a leg up on the other “Big Three” of Notion/Air Table/Coda as none of those recognize that out of the box.

So it would follow that you should be able to filter those out as well to get proper visibility into your data.

Nice request, it is a needed feature!

1 Like

I just used one of my precious votes on this. I would like to stress that what I’d like to see is even something very simple, when you hit “ctrl” + “k” show state of entities, even just giving them a strikethrough if they’re closed, which is what happens in references, where you don’t currently see the other attributes you get when you #link in Rich Text. Specifically:

  • In Comments and Rich Text, you see assignee, state, Type Abbreviation Badge and if the Entity is closed, it’s in strikethrough. Very useful!

  • In References, you see only Type Abbreviation Badge, and strikethrough if it’s closed.

I would be happy simply with strikethrough, like in references, when searching within the global search dialog. @Oshyan’s original title of this request is good, but I’d like to see at times closed items as well. @Oshyan would you be willing to edit and expand the title of this to reflect some of the other comments we have made here?

I will also think about posting a very specific individual request about just showing strikethrough, or not, in that search dialog.

@Polina_Zenevich or @mdubakov would be very glad to get your response about whether if something like simply showing strikethrough or now in that dialog would be possible. It would help us a ton as we have increasing amount of stuff in Fibery that is older, much of it is closed, etc. And it’s hard to see those when searching right now. With the increased amount of entities by the day, this makes search increasingly time consuming as we often choose something we thought was open, but you can only see if it’s closed after you select it.

Thanks!

1 Like

These are good thoughts on the problem. I’ve updated my title above, trying not to be too prescriptive with how this gets addressed. I’ll try to outline what I see as the ideal solution here. And maybe it can be rolled-out in stages, depending on what is easiest to implement (I have no idea what that might be, unfortunately).

  1. Visually indicate “closed” status items clearly in search results (e.g. grayed-out, strikethrough, etc.)
  2. Add more full entity status indicator to search results, e.g. status icon (this would give additional info beyond just strikethrough for closed, but it’s important to strongly distinguish closed, hence it is #1 in the list)
  3. Add a filter option on the search dialog to show/hide “closed” status entities (maybe just a little toggle to the right of the current search box, since it conceptually doesn’t fit with the current “type” filters)

I would really like all three of these, but personally #3 would likely be the most useful for me if only one can be added. This is because over a long time of use ultimately the “closed” entities will outnumber the open ones, so even with a clear indicator of closed status you’d still end up having to scroll a ton to find what you want.

1 Like

I sometimes also find myself looking for a way to exclude by default some objects from search (commits for instance) because they pollute the search results. It would be easy to include them back using the list on the right if needed.

Yeah, I might benefit from that too. However I’m not sure if it’s a separate feature request, e.g. “Individual user preference for search defaults”.

You’re right, I’ll open a separate request!

1 Like

By the way this is a great, great point. It would be even better to simply exclude close entities as you’re right, there are starting to be too many tasks/work entities in my Fibery that even if the closed were gray, you have to get around them. Dev Tasks for example that start with “Refactor…” or something like “Update…” etc.

Really hoping to see some of these basic improvements in search soon, it’s such an essential part of the day-to-day when you use Fibery extensively!

1 Like

Yes, all the more true when you have good, fast search like in Fibery! Ironically in some other apps with slower or less useful search, you might often just navigate manually to something, or even scroll a list or use browser Ctrl-F :grinning_face_with_smiling_eyes: It is in part because Fibery’s search is already pretty good that this problem starts to become as significant as it is.

1 Like

And hey, yes this is true, very true! I have noticed that when typing in the search bar, the results just pop up.

That said, I seem to continue to notice not great speed around other aspects of Fibery, such as page loading. And this is a bit off topic, but one huge quality of life improvement I’d like is the ability to tab over to the Type when creating an inline entity with the “#” command. You can do that when you create from scratch via “ctrl” + “K,” but not when you are writing inline. So I lose my flow on the keyboard by having to grab the mouse and navigate to the Type I want to create inline. I already discussed this here:

in that quote and throughout the thread. Thoughts on whether this warrants a new request? Curious of other power users such as @Chr1sG or @Matt_Blais or @rothnic could use this? Or importantly, did you understand my explanation of the problem :slight_smile:

Since you asked, I can say that I have noticed some UX frustrations when creating/linking to entities from rich text/documents, but I don’t do it often enough for it to be a high-priority issue for me personally.

1 Like

Like Chris, I am aware of this issue and agree with your proposal, but I don’t deal with it often enough myself for it to be a big frustration or top priority (i.e. I can’t/won’t vote for it :joy:).

I’m not sure whether it needs its own post, Polina said it’s in the backlog, so that’s good. But the fact that topic is marked “fixed”, but is not yet closed (so that it’s not available for voting), is a little confusing. @mdubakov any thoughts on this? Do you want to mark that one closed and a new feature request can be opened to track this?