Filtering records based on station

Hi,

I ran into a weird situation. I’m currently working on a kanban board app, which meant to show only those tasks that were assigned to the station you’re currently working on. This would be for use-cases, when operators don’t have personal Tulip accounts, so assigning tasks for a specific user is not an option.
When i create a dropdown menu input field, in which the creator of the task can select the station, it only has the option to save it as a “station” type object variable, from which I cannot get the station’s name as a string.
Also tables don’t have the option for a station type column, therefore I cannot save the variable as a “station”, but I also cannot extract it’s name parameter at the dropdown selector.
So my question would be, if only the "App info / this station’s station name is saveable as a text (so I cannot use the *Stations table’s ID field either), how would you filter these tasks?

Thanks in advance,
Bence

I found a solution, but it really is a dirty workaround.
If the dropdown menu’s datasource is a table aggregation of the *Stations table’s ID’s unique values, the attached variable can be text type, so practically comparable to “this station’s” name.

Hey @kobe -

I think you hit on the trickiest part of this equation, and that is getting list of all of my stations in my instance to populated a dropdown. You approach using an aggregation to pull unique values from a table that has each station populated is the way I would approach this problem too.

Relying on Station Name over the Station object type I find to be a fair bit more flexible for stuff like CSV import, but comes with the limitation that duplicate station names cannot be used.

From there, a filter can be added to your interactive table:

Now it will just show records with a matching Station Name.

Pete

I did just write a feature request to add All Stations and All Users as app info fields you can use to populate something like a dropdown.

Pete

2 Likes

Hey @Pete_Hartnett,

Thank you for your quick answer, also for the feature request.
As far as I’m concerned, it would be really useful, even though this particular problem could be solved without it.
It just doesn’t really feel clean to me, using an easily modifiable table for purposes like this.

Br,
Bence

Hey @kobe -

Yeah you’re totally right, and there is also some risk that one (or multiple) stations aren’t listed in that table. In the interim you’ve got a workaround but we will get this fixed on our side too.

Pete