Category

• Question
• Bug
• Enhancement

Expected or Desired Behavior

When preview is enabled, clicking on a pdf file should display its preview

Observed Behavior

When clicking on the tile, an error appears in a dialog:

Steps to Reproduce

1. Add a search result web part in a page.
2. Set its query to FileType:pdf (ensure there are some pdf indexed)
3. Save the page and click on a tile.
4. The error appears

It's instead showing the title of the current site with {{}} around it.

Related to tiles.html which uses JSON.stringify instead of passing in explicit properties

I have a doubt,
Can we get Property Pane values in the Library Component.

Please see screenshot for example:

Steps I took:

1. • Downloaded zip file
2. • Added to VSCode
3. • npm install
4. • gulp serve
5. • added to page

Category

• Question
• Bug
• Enhancement

Version used : 3.7.0

As you probably already known, when persisting the value of a Date column on a list/library SharePoint internally converts the date to UTC format. This means that for some time zones, the date part of the stored DateTime object can in some case be different from what is displayed in the UI for some users (depending on the site time zone and their personal overrides)

As an example, if a site is configured to use an UTC+3 timezone, a date inserted as "2019-01-01 (00:00)" will actually be stored as "2018-12-31 (21:00)".

When performing a Date based search on a Date managed property (example "Date00:2019-01-01) the search rest api by default assumes that the date is provided as an UTC date. This causes some issue for users working in non-UTC time zones: in the above example, no result is found if an users search for 2019-01-01. Obviously this cause a lot of confusion.

Looking at how the various search api operates I notice that this behavior can be changed by specifying an additional parameter called "TimeZoneId" in the search request. Apparently this parameter isn't documented on MSDN, but I noticed it was used in another GitHub project - PnP-PowerShell. I was successfully able to replay with Fiddler one of the call to the _api/search/postQuery endpoint made by the Search webpart and just adding the parameter with the correct timezone identifier (gotten from here) was enough to still get the expected results when using the local date as a search parameter.

I was therefore thinking that it shouldn't be to hard to add a new configuration parameter to the Search Results web part that would use the aforementioned parameter to enable time zone support for date based search operations. As far as my understanding goes, the pageContext object already used by the search service to fetch the current locale should also include information about the current time zone, so it should be possible to get that info and use it to populate the TimeZoneId parameter.

I would try and provide an enhancement myself, but right now I fear I lack full understanding of the project structure, so I don't think I am up to the task.

Could you please review this suggestion and see if implementing this new feature seems viable for you? As far as I can tell, this seems to be a common problem for many users, so having support for timezone-aware search could be a big "selling point" for this project.

Version used
3.7.0.0

Describe the bug
In a result set, when sorting the results by clicking on a column header, it appears that only the current page of the results are sorted rather than the entire result set. This is counter intuitive behavior and the entire result set should be sorted while the user remains on the result page.

To Reproduce
In an indexed site collection with content suitable for more than 1 page of results, create a site page with the search query, search results, and pagination web parts appropriately connected with a page size small enough to have multiple result pages based on content. Sort results by title.

1 - Issue a query for *
2 - Note the first and the last entry on the page 1.
3 - Click on the title header to change sort order. Note the original sort last entry on the page is now the first and the first original sort is now the last entry.
3 - Click to page two and repeat the click sort noticing that page and only that page are sorted.

Expected behavior
The entire result set, rather than the current page, should be sorted with the user left on the original result set page.

Version used
Ex: 3.9

Describe the bug
Search results condense all metadata tags together into a single string for each result item with no commas, semicolons or spaces between the tags.

To Reproduce

1. Do a search for an item tagged with multiple managed metadata tags.
2. Look at results.

Expected behavior
Metadata tags to be separated by spaces, commas or semicolons.

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

Desktop (please complete the following information):
Same issue seen on all mainstream browsers, safari, firefox and chrome.

Refiners: Display hierarchical structure of managed metadata terms (like Elio Struyf refiners example)
Refiners: Display description of managed metadata terms on mouse hover terms

Currently person fields in refiners are returned as claims username, is there a way to get it to display the display name, or would this require an enhancement?

Version used
3.7

Describe the bug
I have the search web part on a empty page and it sends the input to the standard SharePoint result page.

https://********/_layouts/15/search.aspx/siteall?q=

When I search 'Test Test' for example then the result url is https://********/_layouts/15/search.aspx/siteall?q=Test%2520Test

The result of this search is nothing can be found for test%20test

To Reproduce
Steps to reproduce the behavior:
Create a page and add de 'Search' web part. Configure the settings as below:

Send the query to a new page: https://****.sharepoint.com/sites/zis/_layouts/15/search.aspx/siteall?
Behavior for open: Use existing tab
Method: Searchquery parameter
Searchquery parameter name: q

Save the page and search for 2 words with a space in between. For example 'Test Test'. You will see the result as:

Their are 0 results found for test%20test.

Expected behavior
Searchresults.

Screenshots

Desktop (please complete the following information):

• Browser = Every browser

pnp/sp-dev-solutions#357

Seems to be related to the card rendering view - And I've been able to repro it, but no error message.

Version used
Modern Search - December 2019

Describe the bug
Thumbnails are empty

I want to use the PNP webpart to search through a large Picture gallery.
I'm also having the issue that thumbnails are empty. Also the Tiles view not showing pictures.

2nd issue is when you click on a picture the PNP webpart links to the following link which gives you en empty page. See screenshot
/sites/027314/Shared%20Documents/Forms/DispForm.aspx?ID=9

Standard SharePoint search redirects you to the following link: Then it works!

Desktop (please complete the following information):

• Browser [Chrome]

/sites/027314/Shared%20Documents/Forms/AllItems.aspx?id=%2Fsites%2F027314%2FShared%20Documents%2FPR%20foto%2Ejpg&parent=%2Fsites%2F027314%2FShared%20Documents

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

Is your feature request related to a problem? Please describe.
Would like to see a new Refiner template for FileType that works like classic.

Describe the solution you'd like
A new refiner template for the refiner webpart that shows a friendly name for the Filetype like in classic instead of the raw value.

Describe alternatives you've considered
Used the default refiner template, but users are not liking having to fine docx instead of Word.

Additional context
Screenshot of what classic looks like

Version used
Ex: 3.7

Describe the bug

I have a SharePoint site with One-column layout.
I have Search verticals here, but added so many that some of it is Blanked out.

To Reproduce
Steps to reproduce the behavior:

1. Go to Sharepoint site and add the search verticals
2. Add 10 or more verticals
3. add images and Rowcounter
4. See that part of it is blank or disappears behind the page background

Expected behavior
Search vertical using more width, or creating a second row if the width is too great

Screenshots

Desktop (please complete the following information):

• Chrome, but issue persists on all browsers

Additional context
I did find out that this is an issue on all SP-sites. i'm looking for a way to show more than 10 verticals, since it is also not poissble to add 2 searchverticals and connect them both to the results.

it would be great if the webparts supported section backgrounds especially the refiner webpart.

If I use a Handlebars expression in a Column on a "Details list". The full content is shown as Title.

Is there a way to change what is shown as Title?

I downloaded the sample solution search-extensibility-library, unzipped it. I did the following steps:

1. npm install
2. gulp --ship
   gulp bundle -- ship
   gulp package-solution --ship

I deployed the package to my tenant app catalog. After that I added the search results webpart into my page and in the Layouts section, I configured for the Custom Result Type. In one of the Result Type configuration, I used the following template to map my new library component which I deployed earlier.

This is my template mapping based on ContentTypeId:

After saving the page, a place holder is created on the page but it is not rendering into CustomComponent. I followed the documentation as it is. The markup is as follows after rendering the templated from result types:

Version used
3.8

Describe the bug
We are debugging custom renderers on the remote workbench (https://<your_tenant>.sharepoint.com/sites/<your_site>/_layouts/workbench.aspx). However, after adding the Search Results web part, none of our custom renderers appears in the web part property pane.
They do appear as expected when we modify the Search Results web part on ordinary pages on the tenant.

Is this a known bug, or is it by design?

I uploaded the package file ( pnp-modern-search-parts.sppkg ) in my app catalog at Sharepoint Online. Then I added the app to my site ( Add App ).
When I trying to insert der Webpart ( Search Box ) into my page, I get the following error messages:

[SPLoaderError.loadComponentError]:
Failed to load component "cc39324a-0913-4a5b-b77f-0b6ade7646f6" (SearchNavigationWebPart). Original error: Failed to load URL 'https://localhost:4321/lib/webparts/searchNavigation/loc/en-us.js' for resource 'SearchNavigationWebPartStrings' in component 'cc39324a-0913-4a5b-b77f-0b6ade7646f6' (SearchNavigationWebPart). There was a network problem. Make sure that you are running 'gulp serve' and you have run 'gulp trust-dev-cert'.

INNERERROR:
Failed to load URL 'https://localhost:4321/lib/webparts/searchNavigation/loc/en-us.js' for resource 'SearchNavigationWebPartStrings' in component 'cc39324a-0913-4a5b-b77f-0b6ade7646f6' (SearchNavigationWebPart). There was a network problem. Make sure that you are running 'gulp serve' and you have run 'gulp trust-dev-cert'.
CALLSTACK:
t@https://spoprod-a.akamaihd.net/files/sp-client/sp-pages-assembly_de-de_26fecec28f9e808d5b9f022e6be1635b.js:4:53651
t@https://spoprod-a.akamaihd.net/files/sp-client/sp-pages-assembly_de-de_26fecec28f9e808d5b9f022e6be1635b.js:20:119648
jx2P/s</e.buildErrorWithVerboseLog@https://spoprod-a.akamaihd.net/files/sp-client/sp-pages-assembly_de-de_26fecec28f9e808d5b9f022e6be1635b.js:20:129580
jx2P/s</e.buildLoadComponentError@https://spoprod-a.akamaihd.net/files/sp-client/sp-pages-assembly_de-de_26fecec28f9e808d5b9f022e6be1635b.js:20:125611
e/</<@https://spoprod-a.akamaihd.net/files/sp-client/sp-pages-assembly_de-de_26fecec28f9e808d5b9f022e6be1635b.js:20:115862

Version used
3.7.0.0

Describe the bug
Pagination should hide if there is only one page of results.

To Reproduce
Create a page having the query box, result part, and pagination part all appropriately connected.

Issue a query resulting in one page of results. The pagination web part is visible with only page 1 displaying as an option.

Expected behavior
A single page of results should hide the pagination control as there is no option to move from page to page. Frankly, it looks awkward.

Is your feature request related to a problem? Please describe.

The result search WebPar may be use to build company directory. The oob people layout template is built for displaying such results.

However, there's no "more details" or similar button to see profile information regarding the user. The classic search result webpart is a lot more usable, because of the shown callout.

It would be a huge improvement to mimic this behavior.

Describe the solution you'd like

The ideal solution (in my sense should be to reuse the same behavior that user click in list view).

This pops up a callout with all required information. However, I've read somewhere that MS doesn't allow reusing such component (in #27).

Describe alternatives you've considered

As an alternative, the result container should be clickable, with the user's delve profile page as default.

Additional context

Related issues :

• pnp/sp-dev-solutions#358
• #27

Hello,

I have the Search Box configured as so

This works great until you type something with a space like credit cards

instead of getting put in the URL as credit%20cards it is being put in as credit%2520cards

Therefore the expected refinement later on with this query string is failing.

Category

• Question
• Bug
• Enhancement

Expected or Desired Behavior

When choosing Tiles template in the SearchResultWebPart, the file icon shouldn't render when Show file icon isn't checked.

Observed Behavior

When choosing Tiles template in the SearchResultWebPart, the Show file icon option is ignored.

Steps to Reproduce

1. Drop a Search Result Web part in a modern page. Set its query to IsDocument=true.
2. Choose the Tile layout.
3. Uncheck the Show file icon option

The icon is still rendered.

Is your feature request related to a problem? Please describe.
Not related to a problem

Describe the solution you'd like
In classic mode, I can perform a search using the search box, refiners, etc and then copy the url to get a link to execute the same search.

Is it possible to do the same thing with modern search?

Thanks!

Category

• Question
• Bug
• Enhancement

Version used : 3.7.0

Expected or Desired Behavior

When activating the compact mode of tile layout, thumbnails should render correctly:

Observed Behavior

When activating the compact mode of tile layout, thumbnails do not render properly :

Steps to Reproduce

1. Add a search result web part in a page.
2. Set its query to *
3. Choose tile layout and check compact mode

Hello,

I am attempting to map a managed metadata tag to a refinable string i.e.(RefinableString100 - reserved for SPO by Microsoft), however when trying to save my changes, I encounter the below issue:

I appreciate it's a problem with SharePoint Online itself, rather than the Web Part but wanted to ask whether anyone has experienced this before, and whether there is a workaround for this.

Many Thanks

Version used
3.8.0

Describe the bug
When Web Part Title is set, a scrollbar is displayed

To Reproduce
Steps to reproduce the behavior:

1. Go to a page
2. Click on add a web part
3. Add the Search Results Web Part
4. On page 3, fill out Web part title property
5. On the page, the Web Part title is now displayed as expected, but with a tiny scrollbar to the right

Expected behavior
No scrollbar should be displayed.

Screenshots

Desktop (please complete the following information):

• Google Chrome v79

Is there a way to open a search result item into a new tab? using target="_blank" has no effect.

<span class="template_title example-themePrimary"><a href="{{getUrl item}}" target="_blank">{{Filename}} </a></span>

Thanks.

Context cannot be passed through the templateContext, By using the context perform the service calls for getting the data of that item.

Version used
3.9

Describe the bug
If the user email address is not the same as the account name in the claim the Persona refiner will return an error and the refiner webpart will crash.

To Reproduce
Steps to reproduce the behavior:

1. Make sure the user has an email address different than the account name
2. Map a people field crawled property to a RefinableString managed property
3. Set the people field to the user with different email address and account name
4. Wait for a crawl
5. Define a Persona refiner for the RefinableString
6. Do a search and try to refine with the Persona refiner and the refiner webpart will go blank and an error will be returned in the console.

Expected behavior
The Persona refiner should work just as well with users with account names other than the email address.

Desktop (please complete the following information):

• Browser Chrome, Edge

I will provide a pull request with a fix for this, just wanted to register an issue if others run into the same issue.

When using the person render template, should there be a Live Persona Card visible on hover? Or am I misinterpreting the template option "Disable info on hover".

The wording is a bit misleading ("Show info on hover" would be easier to understand). I tried true as well as false but could get any Live Persona Card pop up. I tried Chrome, Firefox and Chromium.

Hello,

I'm not sure if this is an issue but I wanted to make you aware of the following:

Based on Mikael Svensons Ignite presentation I was eager to learn that you can redirect search queries to a PnP Modern Search results page. Has anyone encountered the issue that it only works for the initial query?

So from site collection A I'm entering a query that is passed on to site collection B which hosts the results page. The parameters passed are Home.aspx?k=test&ql=2055, for example.

I have configured the result source web part to use the page environments query parameter k.

The search results web part correctly shows hits for the query. However, I can't get a new query to fire.

When I use the out of the box modern page's search box the url in the address bar changes but it's not passed on to the search results web part:

When I refresh the browser page the new query is passed on and the web part shows the new results.

Is anyone experiencing this behaviour?

I though of putting a PnP Modern Search box onto the page for further queries but the results web part can only be connected to one source it seems.

Thanks.

Is it possible to showing all the refiners when one is clicked? It would be nice to keep them and makes it easier to switch between the different refiners.

Forgive me - I originally posted this in the old github repo.

Expected or Desired Behavior

The token replacement should act like the SharePoint search token replacement by OR-ing the query such as translating this:

ContentTypeId:0x0101009D1CB255DA76424F860D91F20E6C411800E6AC0A08EAEEBF4FB7A1CD01XXXXXXXX* AND {|owstaxidmetadataalltagsinfo:{User.SubscriptionsMMDUserProfileField}}

into what OOB SharePoint search turns into this:

ContentTypeId:0x0101009D1CB255DA76424F860D91F20E6C411800E6AC0A08EAEEBF4FB7A1CD01XXXXXXXX* AND ((owstaxidmetadataalltagsinfo:#008466174-8d23-47de-af95-71f99bd88396) OR (owstaxidmetadataalltagsinfo:#0ec0eccb9-dcf1-45e2-9f75-1cd70494401c) OR (owstaxidmetadataalltagsinfo:#05f287ce5-796c-408c-afd1-a569cd19ba42))

Observed Behavior

Token replacement adds commas in between the separate terms so the resulting query does not return the expected results (and is possibly an incorrect query)

Source query:
{searchTerms} ContentTypeId:0x0101009D1CB255DA76424F860D91F20E6C411800E6AC0A08EAEEBF4FB7A1CD01XXXXXXXX* AND owstaxIdTopic:{Page.Topic.TermID}

Translates to:
{searchTerms} ContentTypeId:0x0101009D1CB255DA76424F860D91F20E6C411800E6AC0A08EAEEBF4FB7A1CD01XXXXXXXX* AND owstaxIdTopic:c52662de-76a9-4b63-af33-5c96801a6bf7--->,<---e5937827-fbf1-4a71-b41a-310195f46314--->,<---55f30609-524e-4934-bf77-d0d57cb1c98b

Please note: --->,<--- was just added for visibility of the comma

Steps to Reproduce

Add a field called Topic (or anything) that is a multi-value managed metadata field
Create 3 pages
2a) Page A has Topic value of: Topic 1, Topic 2, Topic 3
2b) Page B has Topic value of: Topic 1, Topic 2
2c) Page C has topic value of: Topic 1
Add a search results component with the following query in the Query Template:
{searchTerms} AND owstaxIdTopic:{Page.Topic.TermID}
the query could also use label, it still results in unintended results (or no results):

{searchTerms} AND RefinableString00:{Page.Topic.Label}

If you look at the response of the /postquery in QueryModification field, the result is a comma separated list of the terms rather than a grouped list of OR statements for the list of terms

I would expect that on pages A, B and C all 3 results would be returned for each page because they all are tagged with Topic 1. This would be the case if they were OR'd together in parens.

Is your feature request related to a problem? Please describe.
I can't seem to find any documentation on if it's possible to control which refiners are active based on url query parameters (deep linking). Is this possible and if so how would I go about using it?

Describe the solution you'd like
Support for deep linking into specific refiners as well as some documentation on how to use it.

Describe alternatives you've considered
I've considered building a custom web part to handle this or simply hard coding a search into the results web part.

Category

• Bug

Hi,
I have a weird bug on first release tenant.
I haven't tested on GA tenant.
I tested only with Chrome.
It's last release of pnp-modern-search (3.8)

Expected or Desired Behavior

If you have many page who use pnp-modern-search webparts and if you navigate between her with partial load you have this error in console :

The "DynamicData" object cannot be used because it has been disposed

Yesterday, I also had this error that makes crash this webparts, but I do not reproduce it this morning :

Source has already been initialized

Steps to Reproduce

• open chrome console
• create two page and configure pnp-modern-search with all search webpart (searchbox, refiners ...)
• create two nav access in header nav bar
• navigate several times alternately between these two pages
• see the console

Thanks

Version used
Sharepoint Online

Describe the bug
When scrolling down, modern page becomes wacky (see attached GIF).
This happens when the Search Refiner Webpart is larger than the Search Result Webpart

To Reproduce
For a Modern Page with 1 section containing 2 webparts:
Left-most webpart:
Search Refiners Webpart
Contains 10+ refiners, of which a handful of the refiner types have 10+ values (ie in total a long list of refiner values)
Right-most webpart:
Search Results Webpart
Returns 50 items (by configuration) of 30k items

Expected behavior
No jumping up and down (ie wacky behavior)

Screenshots

Desktop (please complete the following information):
Chrome

Additional context
Add any other context about the problem here.

Hi,

Is there a way to force results (e.g. documents) to open in Work Desktop, rather than Online?

I have made the relevant changes in the Library settings to default to desktop client etc., but that has no effect.

Thanks

Is your feature request related to a problem? Please describe.
I need to do service call from library component, How can do service calls without context in library component.

Version used
Ex: 3.8.0

Describe the bug
There seems to be an intermittent issue caused when navigating in a SharePoint site to different pages which each have an instance of the search results and search refiners webpart added to them. Sometimes you see the attached error

On refreshing the page the error goes away. Further if you navigate by opening in a new tab the issue is not reproduced.

To Reproduce
Steps to reproduce the behavior:

1. Create search results webpart and associated refiners on a few pages within a site collection
2. add links in the SharePoint nav and use these to navigate to the various pages containing the webparts.
3. Intermittently, you will see the attached error. This has been replicated by many users in my tenancy but again the issue is intermittent. Given the nature of the error this looks to be more fundamental that the webpart config, perhaps to do with how the webparts are communicating with each other.

Expected behavior
Error should not occur

Error

Is your feature request related to a problem? Please describe.
No

Describe the solution you'd like
Add the option in the results or refiners web part (or both) to turn on audience targeting and filter results based on aud targeting selections in libraries/lists. So user A will only get results targeted to him/her.
Describe alternatives you've considered
n/a

Additional context
Add any other context or screenshots about the feature request here.

Hi all,

I've noticed a small issue with the Search Refiners webpart when you have it configured as a Multi Value refinement item.

By default the "Apply | Clear" buttons are greyed out until you select an item to filter. This makes sense, If you then select a single item and click "Apply", the webpart filters the search results as expected. However, if you then uncheck the item, the "Apply and Clear" buttons are greyed out but the search results are still being filtered. You then need to recheck the item so that the buttons appear again. We really need Apply and Clear to stay visible if a filter is still in affect so the user can clear their selection.

Hope this makes sense,

Thanks,

-Max

Describe the solution you'd like
Search refiners web part: is it possible in the vertical presentation to have the filter nodes open up by default when a search is entered (similar to the way the panel option works)? Requiring the filter group category to be clicked to open it may confuse users.

Version 3.9.0.0

The query for filtering by current user does not work in the modern search webparts.

CreatedBy={User.Name}
CustomValue={User.Name}

When filtering using the highlighted content webpart this query works but it will not work in the modern search webpart

Alphabetical search on top of the search results. On clicking on alphabet, search results should render only title starts with that alphabet.
A property can be assigned in property pane to enable alphabetical filters, so who needs the alphabetical filter can use it.

Is your feature request related to a problem? Please describe.
I need an alphabetical filter in the results part.
I have added alphabetical filter in library component, On clicking on any alphabet do a search call with existing query keywords and refiners and then render all web parts with the output data.

Version used
3.8

Describe the bug
The display of refiners in the side panel doesn't look correct. The headings are smaller than the refiner items and there is no indicator the closed refiners can be expanded. They look correct when in vertical display mode.

To Reproduce
Steps to reproduce the behavior:

1. Add refiners web part to search page
2. Configure for Side Panel display mode
3. Click on Filters button when results are returned
4. See display formatting issues

Expected behavior
Expected the display of the filters in the side panel to look like they do on the page when in vertical mode.

Screenshots
Display in vertical mode:

Display in side panel mode:

Desktop (please complete the following information):

• Browser: Edge, Edge Beta, Chrome

Does this work with SharePoint 2019 on Premise?

I'm aware of this - https://github.com/SharePoint/sp-dev-solutions/releases/tag/ms-2019-08-14 which appears to be an older version of this new repo, but it's incomplete and only has the results webpart with static search query available, and attempts to build the src in the zip has a bunch of version conflicts.

Thanks for any info.

Is your feature request related to a problem? Please describe.

The classic search result webpart have a very useful feature : the "Test" tab of the query editor. Especially, when writing complex queries, with a lot of tokens, or when the result source has complex syntax, the test tab shows the actual, final, KQL query passed to the search engine.

This helps a lot to debug complex syntax, or to copy/paste the query (into Search Query Tool for example).

The modern search web part does not show the final query.

Describe the solution you'd like

It would be cool to show the query somewhere. It may at least in the browser dev console, or in the debug template, or in the component source (as Html comment), or shown using a hidden shortcut, ...

Describe alternatives you've considered

Additional context