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,
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.
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.
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.
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.
Do you have an approximate date on this feature release?
It came up once again with a Machine Monitoring topic, where this workaround doesn’t fit, because I need to filter specifically for a selected “Machine” name, not a Station, which - as far as i can tell - works the same way, when I try to extract the name.
Hey @kobe -
Just poked the product manager for this part of the product to understand when it might get picked up and worked on. Quarterly we run ‘Quick win’ sprints for feature requests like this one. Reached out to understand if this one will make the cut for that next sprint. We generally prioritize asks based on the frequency they come up, and this one was a new ask, so it might not make the cut for the next quick wins sprit.
Thanks for the patience,