Monday, February 22, 2016

When query by content type name use SPContentType and not ContentType

If you are to query in SharePoint using search using the name of a content type, be sure to query using the managed property SPContentType and not ContentType. The latter contains extra data, and will usually fail you.

Use SPContentType=Document, and not ContentType=Document

Of course you can query using ContentTypeId instead if you have the id.

Tuesday, February 16, 2016

Why you should back up your term store in SharePoint Online

image
Short version, if you delete a term, you cannot easily restore it.

But it is possible! (solution at the end of the article)

Monday, February 15, 2016

Using SPServices to help populate fields in a SharePoint form

image

I know SPServices is old skool and so am I. We both go very well in hand with web services indeed, but we do enjoy the occasional re-write to new world of REST. Honestly!

I have a form where based on a lookup to another list I should populate, or copy values, over to some fields. Pretty simple task, which is not out of the box.

As I hate writing plumbing code I pinged Marc Anderson and found out that his SPServices library has a method named SPDisplayRelatedInfo. This method is meant to be attached to the drop-down tied to the look-up list, and will pull in related data and render it as an inline table.

(Image borrowed from https://spservices.codeplex.com)

In my case I wanted to populate the Site name, Department and Responsible person based on the item selected in the below drop-down.

image

Thursday, February 11, 2016

Search schema mapping level explained

In SharePoint search you can map a crawled property to a managed property at basically three different levels. On-premises farm have SSA, site collection and site, while SPO have Tenant (subscription), site collection and site.

Search Service Application / Tenant

This is the top level, and mappings done at this level are inherited down to all site collections and sub sites.

Mappings for content outside of a SharePoint site collection like user profiles, hybrid crawled data, bcs, file crawls etc HAS to be mapped at this level.

Site collection

Mappings at a particular site collection will have effect for content stored on that site collection only, and only for searches executed in the context of the site collection. The last part is important. If you search center or search page is residing outside of the site collection where you did the mapping, then the mapping is not applicable. Any mapping is also inherited down to sub sites.

Site

Only for viewing the schema - no mapping possible.

Takeaway

If you map on a level besides the SSA/Tenant level, make sure the content you are mapping for resides at the level you map, and that queries executed also run in the same context. This means for a REST query you would set the API url to target the full URL of a site collection if that’s where the mapping is – https://server/site/mysite/_api/search/query, and not https://server/_api/search/query.

Read more at https://support.office.com/en-us/article/Manage-the-search-schema-in-SharePoint-Online-d4fab46d-ba41-4c03-9d4c-32b5b33198b6 and https://technet.microsoft.com/en-us/library/jj219667.aspx

Wednesday, February 10, 2016

Scenario where you do not want to use output caching in ASP.NET (MVP/WebAPI)

Always fun to get to the bottom of weird issues when you didn’t write the code yourself.

Take a look at the following method declaration.

[OutputCache(Duration = 3600, VaryByParam = "none", Location = OutputCacheLocation.Any, NoStore = true)]
public async Task<JsonResult> GetCurrentUser()
{
    var userId = UserHelperFunctions.GetCurrentUserId();
    var userName = UserHelperFunctions.GetUserName(userId);
    var hasPrivilege = <check admin access>

This is what happens, User A logs in and retreives user data, and within the next hour, every other visitor will get user A’s information. Also pay attention to line 6

Wow!

There are ways to solve this, for example like in this SO question, but for now I’ll set it to the below to make sure it’s not cached at all.

[OutputCache(NoStore = true, Duration = 0, VaryByParam = "*")]

A small alfanumeric sorter with numeric padding

I just got a support task where I’m pulling data from an API and need to sort the items based on a chapter like key. The data looks like this:

  • ST.1.1
  • ST.1.2
  • ST.1.10
  • ST.2.20a

The data is coming back random, and if I do a pure alfanumeric sorter, then ST.1.10 will sort above ST.1.2, which is lexically incorrect. Since I know I will never have numbers above three digits (ST.999.999), I figured I could sort it all by padding the numbers. This is the solution I ended up with, and if you have a smarter one let me know :)

I’m matching right to left in the regular expression as this makes it easier to replace the string as indexes are not changed when inserting characters.

class Program
{
    static void Main()
    {
        var demo = new List<string> { "ST.1.1", "ST.1.10", "ST.1.3c", "ST.1.3a", "ST.1.2" };
        demo = demo.OrderBy(PadName).ToList();
        demo.ForEach(Console.WriteLine);
        //output is: ST.1.1 ST.1.2 ST.1.3a ST.1.3c ST.1.10
    }

    static readonly Regex _reNumber =
       new Regex(@"\d+", RegexOptions.Compiled | RegexOptions.RightToLeft);
    static string PadName(string name)
    {
        foreach (Match match in _reNumber.Matches(name))
        {
            string newNumber = match.Value.PadLeft(3, '0');
            name = name.Remove(match.Index, match.Length)
                       .Insert(match.Index, newNumber);
        }
        return name;
    }
}

Tuesday, February 2, 2016

"I Want to Believe" - Is Microsoft abandoning the enterprise features of enterprise search?

image
I want to believe that Microsoft has not abandoned the enterprise in enterprise search, and that the good people behind the FAST seearch engine still are allowed to deliver well tested and proven features around the SharePoint search space.

If features are removed, as they were from FAST ESP to FAST Search 2010 from SharePoint, and from FAST Search 2010 for SharePoint to SharePoint 2013, then remove them first after you have tried to advocate the use of them. Just because a feature is not used by the average SharePoint consultant/pro-user, does not mean it’s not valuable. It might be that they just don’t know about it, or don’t know how to put it to good use.

Want to read more? Head over to ITUnity for the full article.