REST datasource filter set search not working

bump #6

bump #7

#persistentwidow

bump #8

Really, Skuid? this is getting pretty embarrassing…

bump #9

bump #10

This thread has been marked “in progress”, but as far as I can tell, no progress has been made here.

I’m a fairly patient man, but my patience is wearing thin.

bump #11

bump #12

Just re-read the OP and realized that the last word before “Help?” should be ‘incorrectly.’

bump #13

Hey Matt. I can get my REST expert to give you a hand. No charge. Lemeno

Thanks, Pat. Maybe this is a REST issue, but the problem I’m seeing is that skuid is putting 0 in for the {{search}} merge, rather than the actual search term that I enter in the skuid table’s search bar.

I think if the merge syntax worked as expected, I wouldn’t have any REST problems.

Got it. Lemeno

Hi Matt,

I hear your frustration, and I apologize that it’s taken so long for a response to come to this topic. I also see that Pat just responded as well, which is comforting, knowing his level of expertise and experience. I will be happy to join this conversation as well to find a root cause and work towards a solution. Since your reported issue involves a few layers of complexity, at a glance I’m not sure which piece I should be most suspicious of. But it sounds like you suspect that the merge variable for {{search}} is not behaving as expected. Have you found that this is only happening when you try to use it with REST data sources?

The fact that a zero is getting inserted makes me wonder - perhaps the 0 is coming into the picture because it’s the first item (item 0, if zero-indexed) in the JSON underneath… One obvious sanity check to make - have you tried triple mustaches around search, instead of double mustaches?

Ideally I’d like to boil this down as much as possible so if there’s a product issue at work, we’ll be able to understand what’s relevant for reproducing the issues. 

Have you tried a simple test of having the {{search}} by itself in the REST query? I know it would probably throw an error, but it would be helpful to see how things behave when that merge variable is by itself. 

Mark,

Thanks for jumping in.

I’ll do my best to simplify.

First, I tried to reduce the  data source url to 
/repositories/compasscare/optimizecore/issues{{#search}}?q=title~{{search}}{{/search}}

My search bar is on a filter set on the model. When no search is entered, the request payload data url is https://api.bitbucket.org/2.0/repositories/compasscare/optimizecore/issues, as expected.

When I enter anything in the search, the data url is 
https://api.bitbucket.org/2.0/repositories/compasscare/optimizecore/issues?q=title~0
Where 0 is being entered for the {{search}} merge. Something other than 0 seems to be getting passed to the {{#search}} conditional merge syntax, though, because the contents between {{#search}} and {{/search}} are being evaluated (unless 0 counts?).

Triple mustache yields the same result.

Next, I tried to simplify the data source url further, to

/repositories/compasscare/optimizecore/issues?q=title~{{search}}

I found that the source was returning [Object object], until I put quotes around the search, which leaves me with a data source url like this:

/repositories/compasscare/optimizecore/issues?q=title~“{{search}}”

That actually worked as expected!!!


Now, the trick is to work backwards to get all the conditions back in there as needed.

When I tried a data source url like this:

/repositories/compasscare/optimizecore/issues{{#search}}?q=(content.raw~“{{search}}”+OR+title~“{{search}}”){{/search}}

I got the 0 again for {{search}}.

So, the issue clearly has something to do with the interaction between the conditional merge syntax and the regular merge syntax. 

I dropped the conditional merge syntax, and went with this
/repositories/compasscare/optimizecore/issues?q=(content.raw~“{{search}}”+OR+title~“{{search}}”)

And it worked again!

Implementing those same changes back into our larger data source url, and we’re in business… the final (WORKING :slight_smile: ) url is:

/repositories/compasscare/optimizecore/issues?q=((state={{state1}}+OR+state={{state2}}+OR+state={{state3}}+OR+state={{state4}}){{#kind}}+AND+kind={{kind}}{{/kind}}{{#user}}+AND+assignee.username=“{{user}}”{{/user}}+AND+(content.raw~“{{search}}”+OR+title~“{{search}}”))&sort={{sort}}

So, I’m good to go, in that I’ve found a workaround that gets my page where it needs to be.

That being said, it still seems like there’s some kind of product issue at play here.

Why does merge syntax like this
{{#kind}}+AND+kind={{kind}}{{/kind}}
work for a filter in the data source url, but the exact same type of syntax doesn’t work for a search term supplied through the same filter set?

If I try to drop the merge syntax for the filters, the query fails! If I include the merge syntax for the search term, the query fails!

Why is there a difference?

Thank you very much for adding these play-by-play updates. I have the same question, and I will try to do some testing with similar parameters and get back to you. One question - is there any impact if you swap out the field label and change {{search}} to something like {{searchTerm}} or {{search1}}? I’m curious about if that could be a ‘reserved’ merge variable, though I’m not aware of such a thing in Skuid.