REST datasource filter set search not working

Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
edited June 25, 2020 in Questions
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:
image

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?

Β«1

Comments

  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited June 28, 2018
    10.0.25
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited June 28, 2018
    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+
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited July 6, 2018
    bump!!
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited July 6, 2018
    Anyone out there have an idea how I can get the search to work?
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited July 18, 2018
    Sodium Sodium
    Sodium Sodium
    Sodium Sodium
    Sodium Sodium

    Sodium Sodium
    Sodium Sodium
    Sodium Sodium
    Sodium Sodium
    BATMAN!



    (also, bump)
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited July 19, 2018
    Commence daily bumps until resolution.
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited July 20, 2018
    bump
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited July 23, 2018
    bump #5
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited July 24, 2018
    bump #6
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited July 25, 2018
    bump #7

    #persistentwidow
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited July 26, 2018
    bump #8


    Really, Skuid? this is getting pretty embarrassing...
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited July 27, 2018
    bump #9
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited July 30, 2018
    bump #10
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited July 30, 2018
    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.
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited July 31, 2018
    bump #11
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited August 1, 2018
    bump #12
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited August 1, 2018
    Just re-read the OP and realized that the last word before "Help?" should be 'incorrectly.'
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited August 2, 2018
    bump #13
  • Pat VachonPat Vachon πŸ’ŽπŸ’ŽπŸ’Ž
    edited June 25, 2020
    Hey Matt. I can get my REST expert to give you a hand. No charge. Lemeno
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited June 25, 2020
    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.
  • Pat VachonPat Vachon πŸ’ŽπŸ’ŽπŸ’Ž
    edited August 2, 2018
    Got it. Lemeno
  • Mark DeSimoneMark DeSimone πŸ› οΈ ο»Ώ
    edited February 4, 2020
    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.Β 
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited August 3, 2018
    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.

  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited August 3, 2018
    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!!!!


  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited August 3, 2018
    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!
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited August 3, 2018
    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.
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited June 25, 2020
    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?
  • Mark DeSimoneMark DeSimone πŸ› οΈ ο»Ώ
    edited August 3, 2018
    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.
  • Matt SonesMatt Sones πŸ’ŽπŸ’ŽπŸ’Ž
    edited August 4, 2018
    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?
  • Pat VachonPat Vachon πŸ’ŽπŸ’ŽπŸ’Ž
    edited August 3, 2018
    Rip!
Sign In or Register to comment.

Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!