In the past the search bar in a list style layout would return results from an inline list in the corresponding details screen. I’m not seeing any results in the search if I’m searching for text… Oddly enough the search works with numbers.
Has anything changed recently which would cause this to happen? Has anyone else noticed this issue?
I’ve never known values in an inline list on a detail screen to be searchable when searching the main list, unless you use a lookup column (for a single relation) or a joined list (for a multiple relation) and display that lookup or joined list on the screen.
I could be wrong, or I’m not fully understanding how you have everything set up, but maybe Mark can shed some light on it.
At least for the name, I would probably display it using a regular text component instead of an inline list and point it to a lookup column sourced from a single relation. You could do the same with the number, unless you expect to have multiple results, then you would still need a multiple relation, but would probably need the joined list of numbers displayed on the screen. Again, I could be way off base here and would need more information about how your data and screens are set up.
The good news: We’re currently transitioning all apps to the New Computation Model (which Pages uses already), and the app where you say the search is working is on the new model, whereas the one where it doesn’t work is on the old one. Soon all apps will be on the new model.
The bad news: The New Computation Model’s behavior here is wrong - it shouldn’t search into the Inline List content, like @Jeff_Hager says. And in fact it doesn’t: if you remove the filter on that Inline List you still can’t search for any of the other list items. We’ll fix that bug and then all apps will be back to the old model’s behavior.
Interesting. So I guess you are saying you fixed the bug in the old one recently because it worked that way for almost 2 yrs.
Why not be able to search for Inline List Content if it’s a lookup column in the attached row? I would argue the new model has it right… at least my users used it in that way
I am using a lookup column. Take a look at the first app I shared (Search Is Good)… it works when the Inline List Title is using a lookup column. That’s how it’s always worked… do you believe it’s been a bug the whole time?
I’m not sure I followed Mark’s comment about removing the filter. I just copied the “working” app and I didn’t see a filter. Maybe he meant that it’s looking at the lookup values??? I proved as such by removing the Group lookup column and I could no longer search by group.
Anyway…as I understand the search, the value has to be visible on the detail screen. That’s the only way I’ve ever known it to work. I’m guessing that’s the normal procedure so people can’t deduce underlying data, that’s not displayed, by using search to “figure out” what that underlying data is. Even though you have a lookup, you aren’t displaying that lookup value on the screen, so it shouldn’t be used for the search. What some people have done in the past is display the values that they want to be searchable (but not visible) using a rich text component with some HTML or CSS to make the text color match the background, or I think some people have wrapped the text in CSS to make it non-display, but still technically on the screen. Either way should work and will make the search work against the value in the lookup column. That’s one reason I mentioned actually displaying the values instead of displaying inline lists. The Group value could just be a text component that points to the group lookup value. The Number value could be an action text component that points to the number lookup value, but with an action that to show the detail screen of the relation. Then search should work normally because you are actually displaying the lookup values on the screen.
That’s a good security point, and I can confirm the last time I check it works like you said. What I usually do is adding the supposed text (usually a template column joining all the info that should be searchable, then hide that using a condition that will never be true). I’m fairly certain I didn’t use CSS for that, maybe Glide just need the component to “load” the value, not a text that is visible then made invisible through CSS.