SharePoint Online Search Isn’t Displaying What I Expect – Part 2 – EnableDynamicGroups

This occasional series probably ought to be titled “How to solve a search problem by asking Mikael Svenson” (@MikaelSvenson), but he probably doesn’t want to be the world’s help desk for search. Luckily, I know him.

In my previous post, I showed how to simplify your code by using PnPJS and async/await. I didn’t focus much on what I was trying to accomplish. The goal of the search call was to get a list of all the sites (STS_Site) which the current user could access. We’ve built a My Team Sites SPFx Web Part and this call is in the services for it.

Over several weeks, we’ve been trying to get the Web Part to display what we want – which wasn’t as simple as we would have thought. If you work with the search APIs all the time, these things may be old hat to you, but since there is usually a big gap in between the times I use them, my memory can get a little fuzzy.

In the prior post in this series, I talked about how the way that the search API trims duplicates – which may make total sense in many ad hoc search results – can cause you to miss results you actually need. By setting TrimDuplicates to false, we can ask the search API to return all the results.

We ran into another search “feature” in this instance. Since we’re trying to retrieve all the sites to which the current user has access, we’re asking the search API to return objects where contentclass=STS_Site. I’d already turn off duplicate trimming – can’t catch me twice on that! But we still weren’t getting all of the sites back. Even more strangely, we were getting some modern sites back, but not others. The sites we were getting back and those we weren’t were darn near identical in their set up and use. Because they represented a project covering a specific scientific topic, the names of the sites were almost identical.

Here’s an abstraction of what we were seeing:

* In this case, my permissions as I was testing, but we checked with a few other people’s views as well.

As you can see, the only difference we could spot was the single character difference in the Title and URL for the site. Duplicate trimming could certainly have kicked in there, but we had already turned that off. (If you have any ideas of what else might be different, I’m all ears!)

After a discussion with Mikael, he suggested adding EnableDynamicGroups to the call. Magical – it worked! I can’t for the life of me understand why it worked, since we were seeing probably a good half of the modern Team Sites already, but since it worked, I guess we should just be happy with that. As Mikael told me, “turn off duplicate trimming and add that, and things usually work.”

If you’re using PnPJS and async/await- as I recommended in my prior post, then the change is in lines 14-20. We’ve simply added the EnableDynamicGroups property and set it to true.

  private async _getSiteData(): Promise<ISPSite[]> {

    var thisDomain: string = location.host.split(".")[0];
    var exclusions: string[] = ["https://" + thisDomain + "-my.sharepoint.com", "https://" + thisDomain + ".sharepoint.com/portals/personal"];
    var exclusionString: string = " -Path:" + exclusions.join(" -Path:");
    exclusionString += " -Path=https://" + thisDomain + ".sharepoint.com";

    try {

      let result = await sp.search(<SearchQuery>{
        Querytext: "contentclass:sts_site " + exclusionString,
        RowLimit: 500,
        TrimDuplicates: false,
        Properties: [{
          Name:"EnableDynamicGroups",
          Value: {
            BoolVal: true,
            QueryPropertyValueTypeIndex: QueryPropertyValueType.BooleanType
          }
        }],
        SelectProperties: ["Title", "Path", "SiteLogo"]
      });

      return this.processSearchResults(result);

    } catch (e) {

      console.error(e);
      return null;

    }

  }