microsoft-search / pnp-modern-search

Home of PnP Modern Search solutions, helping you move from classic to modern SharePoint and beyond
https://microsoft-search.github.io/pnp-modern-search
Other
389 stars 341 forks source link

Value for 'HitHighlightedSummary' is not populated when the Query Template starts with '{searchTerms} AND ' #2010

Closed SjoerdV closed 2 years ago

SjoerdV commented 2 years ago

Version used Ex: 4.4.1

Describe the bug Value for 'HitHighlightedSummary' (and thus the computed 'Summary' slot) is not populated when the Query Template starts with '{searchTerms} AND '

To Reproduce Steps to reproduce the behavior:

Prepare assets

  1. Add some documents and links in a library somewhere

Configure Page (Part 1)

  1. Create a modern page, or use the homepage of a site
  2. Add a PnP searchbox webpart
  3. Add a default PnP results webpart (use the 'Details List' layout, which will have the Summary column added by default)
  4. Add this as a Query Template {searchTerms} AND Path:<URL to the DocumentLibrary>*
  5. Connect this Results webpart to the SearchBox webpart

Notice the Summary column is NOT filled, DEBUG view shows 'null' as a value

Configure Page (Part 2)

  1. Add a second PnP default results webpart (use the 'Details List' layout, which will have the Summary column added by default)
  2. Add this as a Query Template Path:<URL to the DocumentLibrary>*
  3. Connect this Results webpart to the previous SearchBox webpart (not really functional without the token in the Query Template, but just to complete the setup)

Notice the Summary column is filled, DEBUG view shows some computed value

Expected behavior I would expect it not to matter whether or not any token or this specific token is used in the Query Template. It should always deliver a filled in Summary slot and thus a filled in 'HitHighlightedSummary' search result property

Screenshots If applicable, add screenshots to help explain your problem.

Desktop (please complete the following information):

Additional context Add any other context about the problem here.

wobba commented 2 years ago

Closing as the web parts cannot control what the API return or not. You should replicate the bug and file a support ticket with Microsoft.

SjoerdV commented 2 years ago

Just found a workaround. I forgot to mention that the result webparts were also having a default value set for the searchbox connection which was set to "*" (no quotes) and the solution lies here in.

  1. let's say the Query Template is equal to {searchTerms} AND Path:<URL to the DocumentLibrary>*
  2. then set the Default value for the Results webpart connection with the Searchbox to Path:<URL to the DocumentLibrary>*, so just repeat the entire query without the {searchTerms} AND part. This will miraculously make the HitHighlightedSummary value be populated.

So it's probably an API issue indeed, but perhaps someone can use this. Don't use just a plain asterisk as a default value is my lesson here. If someone disagrees I'd like to hear it though

stevebeauge commented 2 years ago

As anyone update regarding this issue ? I can cheat using the workaround from @SjoerdV but it's not cumfortable.

And opening a ticket for every single bug in SharePoint would require hiring a full dedicated team

spinyriptide commented 10 months ago

Just found a workaround. I forgot to mention that the result webparts were also having a default value set for the searchbox connection which was set to "*" (no quotes) and the solution lies here in.

  1. let's say the Query Template is equal to {searchTerms} AND Path:<URL to the DocumentLibrary>*
  2. then set the Default value for the Results webpart connection with the Searchbox to Path:<URL to the DocumentLibrary>*, so just repeat the entire query without the {searchTerms} AND part. This will miraculously make the HitHighlightedSummary value be populated.

So it's probably an API issue indeed, but perhaps someone can use this. Don't use just a plain asterisk as a default value is my lesson here. If someone disagrees I'd like to hear it though

So this would work without the token {searchTerms}? I didn't try it yet, but this is my first thought.

spinyriptide commented 10 months ago

As anyone update regarding this issue ? I can cheat using the workaround from @SjoerdV but it's not cumfortable.

And opening a ticket for every single bug in SharePoint would require hiring a full dedicated team

lol, there are SO MANY... including the documentation. What a gnarly web they weave.