Skip to main content

I have a rest datasource pointing to bitbucket with a query like so:


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


I counldn’t figure out how to make a ‘conditional AND’ work with a datasource query. Deactivating a condition in skuid doesn’t change the url that’s being passed, so it was confusing bitbucket, so I went with the merge syntax.


I have a filter set on the model with search properties like so:


When I run the page and type anyting in the search bar, skuid is inserting 0 into the {{search}} instead of what I’m actually searching (according to the request payload data):


“https://api.bitbucket.org/2.0/repositories/compasscare/optimizecore/issues?q=((state=%22new%22+OR+state=%22open%22+OR+state=%22%22+OR+state=%22%22)+AND+(content.raw~0+OR+title~0))&sort=”"


But apparently it’s not inserting 0 into {{#search}}, becuase it’s processing the conditional merge correctly.


Help?

Implementing those same changes back into our larger data source url, and we’re in business… the final (WORKING 🙂 ) 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.

Nailed it, Mark.


A  data source url like this:


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

works just fine!

Apparently {{search}} is some kind of undocumented reserved merge syntax?

Rip!

Matt, I’ll bring this up with our documentation team and engineers, to make sure we clarify this as much as possible. Thanks again for helping us identify this issue!

Matt, just a quick follow up on this. The {{search}} merge variable is actually a standard JavaScript function, and that means the mustaches will recognize it as that. We’ll work to document this - in the meantime here are a couple information sources that help illustrate what’s happening here:
MDN Web Docs - String.prototype.search()
The search() method executes a search for a match between a regular expression and this String object.
GitHub - janl/mustache.js
mustache.js - Minimal templating with {{mustaches}} in JavaScript

Thanks for the info, Mark.

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings