Wednesday, January 28, 2015

SharePoint Online Public Facing winners announced: GoDaddy and WIX.com–with more to come

In December 2014 Microsoft announced the demise of their public facing web feature in Office 365 – a surprise for some, not so much from others. But that’s now history.

Screen shot of new subscriptions without the SharePoint Online Public Website feature

Microsoft has now announced the partners whom you can contact to get your public facing site up and running. GoDaddy and WIX.com! Hoorah!

And to be clear. This is a partnership and no real integration. There will be links within your SPO portal to direct you over to the external partners pages for setting up a new public facing portal. Which means you have to author and build your public facing site on these other platforms. Any integration with Office 365 has to come on your part for now, unless they roll out more features later. I would love to do cross site publishing, authoring in Office 365 and consuming that via search over to the publishing portal.

Time will tell if this idea is fiction or reality……

So  as of March 9th 2015 new Office 365 customers have to head over to the new partners, while existing can continue to use their public facing SPO site for at least two more years.

Check out the support page at Information about changes to the SharePoint Online Public Website and the SharePoint Online Public Website Feature Partner FAQ for more information.

Tuesday, January 27, 2015

How to query using the Result Source name instead of using the id

I’m not going to take credit for this as the solution was originally blogged about at http://blog.voyta.net/2014/04/26/how-to-specify-results-source-name-for-search-query-using-sharepoint-2013-javascript-client-object-model/

I’ve known for some time that you can use the result source name in the .webpart config files as previously blogged. I just didn’t connect this over to SSOM/CSOM/REST for some reason. And turns out a colleague of mine stumbled upon the post referenced at the top for a solution without notifying me :).

There are two parts needed to get this working. Add a SourceName and a SourceLevel parameter. SourceName is obvious and takes the display name you have given your result source. SourceLevel takes any of the values below and has to match the level where you created your result source.
  • SSA
  • SPSiteSubscription
  • SPSite
  • SPWeb
Result sources created on the tenant level in SharePoint Online will use SPSiteSubscription.
The original post on this show JSOM code which is easily portable to CSOM.

var clientContext = new SP.ClientContext.get_current();
var keywordQuery = new Microsoft.SharePoint.Client.Search.Query.KeywordQuery(clientContext);
keywordQuery.set_queryText("*");

// set Source Name
keywordQuery.get_properties().set_item('SourceName', 'Test Global');
// set Source Level
keywordQuery.get_properties().set_item('SourceLevel', 'SPSiteSubscription');

var searchExecutor = new Microsoft.SharePoint.Client.Search.Query.SearchExecutor(clientContext);
var searchResults = searchExecutor.executeQuery(keywordQuery);

clientContext.executeQueryAsync(function onSuccess() {
    // process searchResults
    // e.g. iterate through searchResults.get_value().ResultTables[0].ResultRows
}, function onFailure(args) {
    // process failure
});


If you however want to search in a RESTful manner, format your query by adding the source information needed to the properties property:

https://server/site/_api/search/query?querytext='*'&properties='SourceName:Your Source Name,SourceLevel:SPSite'

This beats using the &sourceid parameter with a guid any day, and allows you to move your search solutions across environments without a concern for the guid per environment.

What’s a value anyways, and how should it be formatted?

There’s been this interesting discussion on twitter this week about formatting of date values in a the slider refinement template. It started with a post over at http://sharepointroot.com/2015/01/22/sharepoint-refiner-with-datetime-field/ where the issue is that if you use for example LastModifiedTime as your managed property the template will pretty print your years with “one year ago” instead of showing for example 2014. For custom managed properties it will show 2014 – no pretty print for you.

If you add OWSDATE as a suffix to your property name or follow Elio Struyf’s fix from http://www.eliostruyf.com/fixing-slider-bar-graph-refiner-custom-date-time-managed-properties/ then it format properly.

And I want to say that I do agree that it is nice to have values pretty printed. But the discussion has been focused on if it’s a bug or not, with everyone thinking it’s a bug except me (and maybe Elio which hasn’t really taken sides hehe).

Why it’s not a bug

Firstly the oob display templates and refinement templates were made to work for what’s shipped out of the box. If it happens to work for other cases, then good for us. This is at least my point of view. If you want a different behavior you create a custom display template and render stuff the way you want (like Elio explains how to do in his post).

The issue with refiners and data types + parsing is that refiners are returned as ranges in strings. Here’s two samples for the last modified property and the size.

image

image

If you look at the token for each refiner it’s an FQL statement, and the value type won’t be verified until it actually it’s the search query pipeline to verify with the type of the managed property. So between the search engine and the UI, values are text.

If the refinement data coming back had an additional property to say which type it was, that would be grand, but it’s not there. And also remember that passing a refinement back in the query API is just passing some arbitrary additional query parameters. It doesn’t have to be a range on on managed property, it could equally be the name of your dog or an XRANK statement as I’ve written about before.

Also, for a number refiner, how many decimals should be displayed by default, and what if I do want year numbers for dates? Well… I create a custom template.

Conclusion – the way I see it

The way SP choses to format custom managed properties is something you as a developer have to deal with. The OOBtemplates are just that. OOB templates meant to work for SP data and as inspiration for you to work with and extend.

Sometimes they work like we want, sometimes they don’t and we resort to using all og Elio’s excellent tips on how to write awesome display templates.

Friday, January 23, 2015

Hide content from Delve–but not from search

[Update 2015-05-01]
Microsoft have now updated the documentation at Manage the search schema in SharePoint Online, and you no longer have to create a managed property or map the crawled property to it. The only step you have to perform to hide data from Delve is to create a site column named HideFromDelve of type Yes/No, and start using it. Everything else is taken care of for you by Microsoft :)

Remember that this will only hide the content from the Delve application, not from the Office Graph and other apps built using it.

[Original Post]

I love Friday’s! Why? Because I get to spend time in the office not being out at a customer site. And when in the office, more often than not, conversations with my colleague Andreas Eide spawns an idea or a blog post. So here goes!

Andreas has this issue where he get’s a lot of invoices in his Delve board, which is not very interesting. They appear because people he collaborates with produce a lot of invoices. The first solution was to mark the invoice library not to be indexed. The drawback however is that this makes the invoices not discoverable at all via search, and you also have to exclude the full library, not just individual items or folders. So then what?

Read the official documentation

Thursday, January 22, 2015

Crawl Time for SharePoint Online and 2013

SharePoint Online (at least old tenants) has this nice managed property called CrawlTime. This is however not available in SharePoint 2013 (if you’re not getting the property back in SPO, see the end of this article).

Crawl time is stored in a crawled property named 323 in the Internal category. By default this crawled property is not visible in the schema, but if you create it, you can use it.

Thursday, January 15, 2015

Let Yammer translate those unreadable messages for you

Yammer has a built in translation service!

Although not a new feature, as it was rolled out back in 2013, it seems network administrators are not aware of it (https://about.yammer.com/yammer-blog/message-translation/).

If you are part of a Yammer network where people post in multiple languages, poke your admin in the kidneys and tell him or her to do the following in Yammer:

  • … (upper right corner)
  • Network Admin
  • Configuration
  • Check “Message Translation”

image

With this turned on you can easily translate from for example Norwegian to English.

image

Wonder why it’s not automatic or user driven…..

Monday, January 12, 2015

SharePoint 2013 Search Query Tool v2.3 released

It’s been about 3 months since the release of v2.2 which as the main feature had GQL support.

image

v2.3 is not a big release, but has the following improvements:

  • Rank detail now works for result sets larger than 100 items
  • Renamed Source Id to Result Source ID in the UI
  • Improved logic to fetch item when displaying all managed properties, now using WorkId
  • Fixed bug with anonymous querying introduced in v2.2
  • Added pretty print to JSON and XML in the Raw tab
  • Fixed app icon

DOWNLOAD

How-to: Provision search web parts configured to custom result source’s

image
When creating search solutions it’s best practice to format the query needed for a search web part via a Result Source, and not directly in the web part itself. This approach however requires you to be aware of a small quirk when moving the configuration from one environment to another.

Friday, January 9, 2015

How to: Boost metadata in SharePoint search results

As pointed out by Mike Fairly in the TechNet forums (see thread), the default rank profile, or any other rank profile included with SharePoint, does not give any weight in particular to tagged content.

This means that if you add managed metadata columns or Enterprise Keywords to a list or library, the terms used will merely help on content recall, but not provide any extra rank to the items moving them higher up in the search results.

On the other hand, when promoting the use of tagging to information workers, you might think they want a return on investment for those tags, meaning tagged items should appear higher in the result set.

There are several ways to go about fixing this:

  1. Create a custom rank profile
  2. Change the weight of managed properties
  3. Use dynamic ranking via the XRANK operator

The easiest in terms of implementation and flexibility is #2.

Monday, January 5, 2015

SharePoint Search Queries Explained–The Book

imageMarch of 2014 I started out the blog series “SharePoint Search Queries Explained”, and just before the Christmas holidays I wrote the last post. I’ve gotten some questions along the way about a book on search queries in SharePoint 2013/Online based on the material, so I decided to go ahead and do it.

During the holidays I put it all together, did some edits and tweaks and here it is! SharePoint Search Queries Explained – a reference book for when you configure up your search solutions.
If you enjoyed the blog series or is just getting into it, you can order your copy today!

Kindle Edition                  Print Edition

PS! If you purchase a copy ping me in and I’ll forward you a PDF version on request.