Skip to main content
Nintex Community Menu Bar
Question

REST datasource filter set search not working

  • July 11, 2024
  • 33 replies
  • 3 views
  • Translate

Did this topic help you find an answer to your question?
Show first post

33 replies

Forum|alt.badge.img+18
  • Author
  • 2192 replies
  • July 11, 2024

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.

Translate

Forum|alt.badge.img+18
  • Author
  • 2192 replies
  • July 11, 2024

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?

Translate

Forum|alt.badge.img+9
  • Nintex Employee
  • 890 replies
  • July 11, 2024

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.

Translate

Forum|alt.badge.img+18
  • Author
  • 2192 replies
  • July 11, 2024

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?

Translate

Forum|alt.badge.img+20

Rip!

Translate

Forum|alt.badge.img+9
  • Nintex Employee
  • 890 replies
  • July 11, 2024

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!

Translate

Forum|alt.badge.img+9
  • Nintex Employee
  • 890 replies
  • July 11, 2024

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

Translate

Forum|alt.badge.img+18
  • Author
  • 2192 replies
  • July 11, 2024

Thanks for the info, Mark.

Translate

Reply


Cookie policy

We use cookies to enhance and personalize your experience. If you accept you agree to our full cookie policy. Learn more about our cookies.

 
Cookie Settings