Saturday, January 21, 2017

How to rename the Title field in a list/library using PnP templates

Took me some testing to get this right, but turned out not that hard. You add a reference to the Title field with the out-of-box id fa564e0f-0c70-4ab9-b863-0177e6ddd247, and then change the display name. In the sample below I’m also using a reference to a language resource as I need support for four languages.

<pnp:ListInstance Title="My List" TemplateType="100" Url="Lists/MyList">
    <pnp:Fields>
        <Field ID="{fa564e0f-0c70-4ab9-b863-0177e6ddd247}" Type="Text" Name="Title" StaticName="Title" DisplayName="{resource:MyList_MyTitle}" />
    </pnp:Fields>
</pnp:ListInstance>

Thursday, January 19, 2017

Clarification on automatic managed properties in SharePoint Online

For some time now automatic managed properties in SPO are listed grayed out, with no settings shown. They sort of seem like ghost properties, not usable for anything. Fortunately this is not true.

image

Displaying no properties does not mean that they are not working as you would expect. The Microsoft SharePoint Escalation Services Team explained it all in a blog post dated August 30th 2016, but it’s not easy to understand. My take is that this was done in order to optimize schema handling in SPO, where there are millions of schemas. They were slowing up, but now at least you can still work with them.

Before you start mapping your crawled properties to new managed properties, see if the automatic ones work as you would expect. The default settings for an automatic managed property (has OWS in the name) are:
  • Queryable
  • Retrievable
  • Multi-value (taxonomy and multi-user fields only)
  • Searchable (taxonomy fields only)
If not, use my rule of 3 below.

Mikaels managed property rule of 3:
  1. Use automatic managed properties if possible
  2. Map crawled properties (the plain ows_columnname ones) to the RefinableXXYY re-usable properties if possible. And do give them an alias for easier management and use
  3. Create a custom managed property as last resort – which is only possible for Text and Yes/No fields.
Shout-out to Joanne Klein for making me blog something which I have just taken for granted :) and to Tarjei for verifying the settings of the auto generated managed properties in an on-prem environment for me. And to Marc Anderson for being the glue!

Friday, January 6, 2017

Retrieving search results from private Groups in Office 365 via REST

By default when you run a search REST query against SharePoint Online results from private Office 365 Groups are not included.

By adding &Properties=’EnableDynamicGroups:true’ to the URL, you will also get results from private groups.

If you are running REST POST requests, add the following to your JSON payload (odata=verbose):

'Properties':{  
         'results':[  
            {  
               'Name':'EnableDynamicGroups',
               'Value':{  
                  'BoolVal':true,
                  'QueryPropertyValueTypeIndex':3
               }
            }
         ]
      }

When using CSOM, it seems dynamic groups are included by default.