[DONE] Ability to hide some databases from search/Entity # Link by default

Ideas & Features
1

Many of our databases have extremely relevant data that it’s important for a user to be able to access frequently. Some - however - are “helper” databases created only to relate two databases together, or to sync in multiple accounts to then be combined in another database. Users almost never need to find anything from these databases, and their presence in search is distracting.

For instance, if I’m looking for John Doe (Contact), I also see John Doe (Billy’s Google Contact) and John Doe (My Partner’s Google Contact) and John Doe (my other partner’s Google Contact) etc. because our accounts sync separately - and sometimes these results are returned above John Doe (Contact). I never need to link to any John Doe other than the John Doe (Contact).

I propose that there is a way - at a Database Settings level - to exclude all entities from a particular database from searches.
I suggest that the hidden database would still be visible in the search database dropdown, but results would not be returned from entities within that DB unless it was specifically selected.
The same would be true to linking entities inline, either by selecting or using “#”. Typing #John Doe would ONLY return John Does from non-hidden databases, unless I specifically selected the “Billy’s Google Contact” database within the dropdown.

This would improve both speed of use for our savvy users, and significantly decrease confusion for the less savvy.

2

Do you mean a search filter, configured at the workspace level (applies for everyone) or configured on a per-user basis (each person chooses which dbs they see in search)?

1 Like
3

Agreed 1000%. I have been meaning to make a similar feature request myself for a while now, but focusing specifically on the Reference (Rich Text linking) Search. With one of Fibery’s goals being to centralize things, even “average” users/workspaces can end up with 10s of databases (e.g. you sync Google Calendar, it adds four databases all by itself!), many of them with extremely similar data meant to relate to each other (again the aforementioned Gcal sync is a great example, but far from the only one). This creates total havoc when Referencing (linking) in free text as well as Search and is a daily drag on my workflow, both personal and business.

Personally I would like to simply see a more powerful Search that includes better built-in Filtering and configurable Defaults, and I had seen that as separate from the filtering/limiting for Link Search (Reference). However I can see how the two could potentially be combined without a lot of downside, at least at first glance.

I also want to note that, while I think it probably depends on how a given person or team use linking, relations, etc. for me the recent implementation of Relation filters was pretty much useless compared to the value this specific kind of filtering would have, namely for References in free text. For Relations there already was at least filtering by DB, and while the added rules are great to make it quicker and easier to find something within that type of Entity, if you set aside frequency of use and just consider how problematic linking is in Relations vs. References in a complex Workspace, the latter case is far, far more of an issue.

I would also venture to guess that having some default filtering could (potentially) make the link searching for in-line references faster. In other words if you have 50 databases (not an unreasonable number for many workspaces), searching for a given text across all 50 vs. just say 3-5 of them ought to be faster, at least in principle. That may not be how it actually works out in the implementation of course, but it could be a bonus.

Anyway, you’ve got my vote. :grin:

Answering for myself (and possibly billyjackson as well, based on his write-up), I think what would be ideal is a per-database filter, not a per-workspace one. Maybe an ability to set a global default but be able to override per-database. So for example if you’re in the Features database, you probably almost never need to link to a Calendar Event, or a Hiring Candidate, etc. Yet if I’m trying to Reference e.g. a person that gave feedback that is in our CRM while writing something about a Feature, I might start with that person’s name e.g. “John”, but oh dear there are 10 Johns who also applied for a job opening, as well as 20 meetings with my teammate John that are synced from recurring events over the last year, etc, etc. Both totally irrelevant to References in Features 90+% of the time. Being able to filter those out and just focus on the ~5 databases I most commonly link to (Reference) from the Features database entities is what I’m looking for and, I think, what billyjackson is (at least partly) wanting as well. And it needs to be per-database, because if I’m then in the Hiring Candidate DB, editing one of those entities, I probably don’t want to link/reference to a person who gave feedback that is in the CRM, possibly ever. :smile: The Reference filtering needs will likely vary greatly depending on the DB/Entity.

2 Likes
4

This is an excellent question. As I wrote it, I meant the former. However, you raise a good point that this could be frustrating if it were not configurable at a per-user level for larger organizations with varied needs

For global search, personally, a per-workspace solution would be completely adequate, while a per-user setting would be better, and a per-workspace default with the ability to edit per-user would be amazing.

For Inline Search/Entity Linking, I think Oshyan has expanded on things in an amazing way:

I completely agree that this would be a fantastic and robust solution. Per-User, Per Workspace, with defaults set. However, I recognize that this would likely be quite complex, and that simply the ability to - by default - exclude certain databases from all searches unless specifically selected in the dropdown would solve approximately 80% of my frustrations with 20% of the complexity.

1 Like
5

And what would you think should happen for search filtering when using mentions in documents (given that they are not part of any database)?

1 Like
6

Worst case: it’s the same as it is now, i.e. all databases, no default filter. Having per-DB filters would still be a huge improvement for my use cases.

But in my ideal world? Workspace-wide default Reference filtering with individual DB override. You can use basically the same UI elements to manage it in both places. In an individual DB, it’d just be a left/right toggle, with Left (“off”) being “Workspace Default” (maybe with a link to that settings area in the Workspace), and Right being “Customize for this Database”, enabling a DB multi-selector. I think that would pretty much take care of it. I don’t know how challenging that filtering is on the back-end, but the UI elements for all this already exist, and we know per-database Search Filtering also exists.

1 Like
7

This is exactly what we are going to implement in the next 2 weeks (but no special syntax, these database will be just hidden from search)
https://the.fibery.io/@public/Public_Roadmap/Roadmap_Item/Exclude-a-Database-from-search-results-177

2 Likes
8

Hi all,

Just came across this and here is the use case that I had written up and was about to post:

Please note: I would like to have some ability to define which spaces will show this search and which don’t, not just a blanket “show/hide” option.

Ability to limit search visibility of a database entity. What I mean is limiting where an entity (database entry) appears in the search when I press #.

  1. Global: Appears everywhere
  2. Specific spaces: Select spaces where it should appear
  3. Same space only: Only in the same space
  4. Link only: Only way to link to it is using the URL and a link

We have by now almost 100 databases and a lot of spaces that we navigate across. As a small team, we touch on many places and I prefer structured information rather than tables and tables to lists. Simple example is a glossary: I’d rather make it a database than just a table on a page as it allows me to sort/group/filter and embed info. Now obviously, I wouldn’t want a term to appear in the search every time I enter #…

On top of that, there are many entities that are just relevant in one or few spaces. For example:

  1. User Stories generally should only be linked to in the product management space
  2. Features or Screens, however might be referred to across product management, user research and design, etc.
  3. Clients should only be visible in some spaces
  4. Product Releases should hue visible everywhere as they are a central piece for everybody’s planning

As you can imagine, the linking search field has become very cumbersome for us despite the heuristics you apply. Being able to define visibility on a database would solve this massively.

Thanks!

3 Likes
9

Very well laid-out examples and approach! I like your options Global, Selected Spaces, Same Space Only, and Link Only (the latter being seldom useful for me, but still interesting). :clap::clap::clap:

10

Checking in on this. Did it ever get implemented?

2 Likes
11

I was looking for exactly this. I have some databases which are populated with data from other systems which I then just use to do some calculations and aggregation on. While I would like the users to be able to see tables with these records, the users don’t really need to find or reference individual records form these particular databases. It would be amazing to be able to exclude them from the search.

@mdubakov is there an update on this?

I see from the roadmap item that there might be a workaround through the API (by removing from indexing). Is it safe to use that or should I wait for this feature to be implemented?

1 Like
12

It’s save to use :slight_smile:

We’ve created buttons so you can easily include/exclude from search.

image

When the button is done, we check/uncheck a field so we know it’s include/excluded.

Script for exclude

const fibery = context.getService('fibery');

for (const entity of args.currentEntities) {
    const SpaceDatabase = entity["SpaceDatabase"];
    await fibery.executeSingleCommand({
        command: "fibery.schema/batch",
        args: {
            commands: [{
                command: "schema.type/set-meta",
                args: {
                    name: SpaceDatabase,
                    key: "search/disabled",
                    value: true,
                }
            }]
        }
    });
};

Script to include again

const fibery = context.getService('fibery');

for (const entity of args.currentEntities) {
    const SpaceDatabase = entity["SpaceDatabase"];
    await fibery.executeSingleCommand({
        command: "fibery.schema/batch",
        args: {
            commands: [{
                command: "schema.type/set-meta",
                args: {
                    name: SpaceDatabase,
                    key: "search/disabled",
                    value: false,
                }
            }]
        }
    });
};

Make sure you index manually when you’re done!

https://[yourworkspacename].fibery.io/api/search/reindex

3 Likes
13

Amazing. Thank you for sharing this awesome work. This is actually a great mock-up of what the setting page might look like (replacing the buttons with checkboxes)! It would be great to have a bit more granular control on where the records appear (in global search, entity references …)

One question: once excluded from the index, does that affect relation fields linked to those databases? I don’t need records from those databases showing up in the global search or be available for referencing in rich text/documents. However, we may still need to establish relationships to them from other entities.

14

When trying to link entities via a to-many relation field on entity view, Fibery does use the same search engine as for general search, so if you exclude a db, you will struggle to find things you might need (unless they already show up as ‘recent items’).
This could lead to you accidentally creating new entities if it appears as though one with the name you are looking for does not exist :frowning:

Hiding databases from search is typically most useful for things like a database used as global single select options (the to-one relations use a different UI component than what is used for search) or where you have ‘helper databases’ to support automations/formulas etc.

1 Like
15

Thanks @Chr1sG . I had one more questions: does hiding databases from search affect API queries? The items that I want to hide the most are written and updated through the graphQL API and so as long as that side is unaffected, I think this might work out for me.

I find the access templates interface to be a really great prototype for how search could be customized developing on the function:

1 Like