10.0.25

Looks like conditional merge syntax works just fine for filtered conditions. I added this to the query…

{{#kind}}+AND+kind={{kind}}{{/kind}}

Filtering “kind” to “bug” with a select filter in runtime has the desired result, with the payload data url

+AND+kind=%22bug%22+

bump!!

Anyone out there have an idea how I can get the search to work?

Sodium Sodium
Sodium Sodium
Sodium Sodium
Sodium Sodium

Sodium Sodium
Sodium Sodium
Sodium Sodium
Sodium Sodium
BATMAN!



(also, bump)

Commence daily bumps until resolution.

bump

bump #5

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!