For ID based dashboard filters, provide a search widget for the target record's name

[salsakran]

When a dashboard creator wires up a foreign key ID as the dimension to be filtered on, we current ask people to input the actual ID.

This is often not widely known and it would be much more useful to search for Acme Co instead of entering the company ID.

⬇️ Please click the 👍 reaction instead of leaving a +1 or 👍 comment

[salsakran]

I believe @mazameli 's design has the UI elements spec'd already.

[mazameli]

I couldn't find where or if I did this somewhere in Sketch previously, but this is what I was thinking. Sameer, WDYT about displaying the ID subtly on the right in the dropdown list and in the selected state? I'm thinking you could of course also search by the ID in case you happen to know it, too (e.g. if I work in Support and I'm using a category filter to look up a specific Customer ID from a support ticket), in which case the ID part of the dropdown would be bold instead.

[tlrobinson]

Makes sense from a UX perspective.

From an implementation standpoint I imagine the performance will depend a lot on the database, number of rows, whether an index is present on the name column, whether we want to only support starts-with or also contains, case sensitivity, etc.

[federicokeen]

Killer feature, can't wait to see it live!

[salsakran]

I'd say we should start with starts-with or whatever is easiest to get out the door.

[tlrobinson]

A couple things to think through:

• What conditions need to be met for this functionality be enabled for a particular ID widget? e.x.
  • if it's wired to a PK which belongs to (or FK which points to?) a table which also has an entity name field?
  • Only on tables with fewer than a certain number of rows?
  • Only if the entity name has an index? (can we tell that?)
  • What if a widget is wired to two different PKs?
  • Can an admin disable this functionality on a per-field/table/db basis if we guess wrong?
• Is it actual typeahead or triggered by hitting enter? There might performance implications of typeahead.
  • In particular, with typeahead we'd want to debounce/throttle requests. How long should the delay be? Minimum number of letters to search for?
  • After the first request we could cache the results and filter them down on the client.
• It might be a good idea to implement query cancelling (Allow users to cancel a query execution at the database #2399) first so a user doesn't accidentally issue dozens of pending queries to a db? Maybe disable by default for dbs which don't support canceling queries?
• Would there still be a way to enter a raw id?
• This same widget could be used in the query builder for filters on PK/FKs. Should we do that?

[salsakran]

What conditions need to be met for this functionality be enabled for a particular ID widget?
it's wired to a PK or FK to a table that has an entity name.
It's very unlikely the entity name will be indexed

What if a widget is wired to two different PKs?
Let's just use the first PK for now. If the user has drastically different Tables wired up they should be mostly equivalent or this is kind of a silly thing to do.

Can an admin disable this functionality?
I like the idea of having a master per-table control to "enable Smart Naming" that also affects #2657

Is it actual typeahead or triggered by hitting enter?
Let's do enter for v1. Agreed that actual typeahead on a big table would be batshit crazy performance-wise

Would there still be a way to enter a raw id?
I'd vote no.

This same widget could be used in the query builder for filters on PK/FKs. Should we do that?
If we do that, we should probably also allow raw ids. =/

An addendum, I think we should try to be smart here and cache the valid values if possible.

[vkovalskiy]

So what is the actual state of this? Can we use entity names somehow instead of IDs in those filters? I think that forcing the uses to paste IDs everytime is a pretty awkward approach...

[jornh]

@vkovalskiy if I'm not completely mistaken it looks like it's being actively worked on in PR #4241 linked to just a few lines above your comment - so still WIP ...

[mazameli]

Yep, #4241 is coming along nicely and will be part of version 0.29 if everything goes according to plan.