Friday, March 24, 2017

Interesting behavior of Sharepoint list views with filters on hidden fields

Sometimes we need to set filter in Sharepoint list view on the hidden field. As hidden fields are not shown in UI we can’t set such filters from the browser, but we can set them programmatically. E.g. suppose that we have field “IsPrivate” which is hidden so end users are not able to change value of this field and we want to show only non-private list items in the list view. List view filter will look like this in this case:

   1: <Where>
   2:   <Eq>
   3:     <FieldRef Name="IsPrivate" />
   4:     <Value Type="Boolean">false</Value>
   5:   </Eq>
   6: </Where>

Now if we will try to modify this list view in UI we will see that its filter section looks like there is no filter at all:

And which is more interesting is that when we will click Save button there – filter on hidden field will remain. I.e. if we will add sorting from UI ViewQuery property will look like this:

   1: <OrderBy>
   2:     <FieldRef Name="Title" />
   3: </OrderBy>
   4: <Where>
   5:     <Eq>
   6:         <FieldRef Name="IsPrivate" />
   7:         <Value Type="Boolean">false</Value>
   8:     </Eq>
   9: </Where>

even though Filter was shown empty in UI. Be aware of this tricky moment to not be confused in situations when filter uses hidden fields.

Monday, March 20, 2017

Problem with outdated value in ModifiedBy search managed property after copying the document

Recently we faced with interesting problem: there is functionality which copies documents from another site collection in Sharepoint Online via SP.RequestExecutor:

   1: var sourceExecutor = new SP.RequestExecutor(sourceSiteUrl);
   2: var targetExecutor = new SP.RequestExecutor(targetSiteUrl);
   4: // Get form digest of target site collection
   5: jQuery.ajax({
   6:     url: targetSiteUrl + "/_api/contextinfo",
   7:     type: "POST",
   8:     headers: {
   9:         "Accept": "application/json;odata=verbose"
  10:     },
  11:     success: function (data) {
  12:         try {
  13:             var digest = data.d.GetContextWebInformation.FormDigestValue;
  15:             // Build executor action to retrieve the file data.
  16:             var getFileAction = {
  17:                 url: sourceSiteUrl + "/_api/web/GetFileByServerRelativeUrl('" +
  18:                     sourceServerRelativeUrl + "')/$value",
  19:                 method: "GET",
  20:                 binaryStringResponseBody: true,
  21:                 success: function (getFileData) {
  22:                     // Get the binary data.
  23:                     var result = data.body;
  24:                     // Build executor action to copy the file data to the new location.
  25:                     var copyFileAction = {
  26:                         url: targetSiteUrl + "/_api/web/GetFolderByServerRelativeUrl('" +
  27:                             targetFolder.get_serverRelativeUrl() + "')/Files/Add(url='" +
  28:                             fileNameFromInput + "', overwrite=true)",
  29:                         method: "POST",
  30:                         headers: {
  31:                             "Accept": "application/json; odata=verbose",
  32:                             "X-RequestDigest": digest
  33:                         },
  34:                         contentType: "application/json;odata=verbose",
  35:                         binaryStringRequestBody: true,
  36:                         body: getFileData.body,
  37:                         success: function (copyFileData) {
  38:                             ...
  39:                         },
  40:                         error: function (ex) {
  41:                             ...
  42:                         }
  43:                     };
  45:                     targetExecutor.executeAsync(copyFileAction);
  46:                 },
  47:                 error: function (ex) {
  48:                     ...
  49:                 }
  50:             };
  51:             sourceExecutor.executeAsync(getFileAction);
  52:         } catch (e) {
  53:             ...
  54:         }
  55:     },
  56:     error: function (ex) {
  57:         ...
  58:     }
  59: });

After file is successfully copied Modified By field shown in list views displays correct value – it shows account of the user which copied the document (i.e. under which account code above was executed). However when we tried to get the value of ModifiedBy managed properly from search index we got value which original file had in the source site collection before it was copied to target site collection (i.e. person which last modified the document in the source site collection). Recrawling of the list didn’t help. Also we tried to explicitly set value of Editor field in document metadata after file has been copied and it didn’t help either.

In order to avoid this issue the following workaround was used: at first as before we get list of the files from search index using javascript object model and then when we get last n results sorted in correct way for displaying in web part we make n requests to content database in order to get correct value of ModifiedBy field (remember that in list views correct account is shown in this field and list views show data from content database):

   1: var documentsItems = [];
   2: var ctx = SP.ClientContext.get_current();
   3: for (var i in documentsFromSearch) {
   4:     var item = documentsFromSearch[i];
   5:     var path = item.Path;
   7:     var relativeUrl = _spPageContextInfo.webServerRelativeUrl +
   8:         path.replace(_spPageContextInfo.siteAbsoluteUrl, "");
  10:     documentsItems.push({
  11:         RelativeURL: relativeUrl,
  12:         File: null,
  13:         // item["ModifiedBy"] from search contains incorrect  value
  14:         ModifiedBy: item["ModifiedBy"]
  15:     });
  16: }
  18: for (var i in documentsItems) {
  19:     var doc = documentsItems[i];
  20:     doc.File = ctx.get_web().getFileByServerRelativeUrl(doc.RelativeURL);
  21:     ctx.load(doc.File, "ListItemAllFields");
  22: }
  24: ctx.executeQueryAsync(
  25:     function () {
  26:         for (var i in documentsItems) {
  27:             var doc = documentsItems[i];
  28:             if (typeof (doc.File) == "undefined" || doc.File == null) {
  29:                 continue;
  30:             }
  31:             var item = doc.File.get_listItemAllFields();
  32:             if (typeof (item) == "undefined" || item == null) {
  33:                 continue;
  34:             }
  35:             doc.ModifiedBy = item.get_item("Editor").$5E_1;
  36:         }
  37:     },
  38:     function (sender, args) {
  39:         ...
  40:     });

In this code we at first create array of objects from results returned from search index (lines 3-16) and then for each object we get it’s File object and from it’s list item read Editor value (lines 18-40). Note that for getting editor’s display name here we used undocumented property $5E_1 of SP.FieldUserValue – more proper way is to get user’s id from it’s get_lookupId() method and load it in separate request from web’s user collection, so please be aware of that. Of course this approach is slower than original because it makes n requests to content database, but if data is loaded asynchronously and number of displayed files is not big, performance will remain acceptable and web part will display correct value in ModifiedBy column. Hope that this information will help someone.

Tuesday, March 7, 2017

Provision and automatic update of embedded resources to App_LocalResources folder under Sharepoint Template/Layouts or Template/ControlTemplates sub folders

In one of my previous posts I showed how to include embedded provision resources (located in {SharepointRoot}\Resources) to wsp package so they will be provisioned and updated automatically (see Provision and automatic update of embedded resources to Resources folder in Sharepoint hive). However on practice we also often add UI resources specific to concrete application layouts page (page located under Template/Layouts subfolder) or user control (under Template/ControlTemplates). E.g. if we have a page /Template/Layouts/Test/foo.aspx then UI resource will be located in /Template/Layouts/Test/App_LocalResources/foo.aspx.resx. Note that it has the same name as parent page plus .resx extension. In this case we can use the following declarative syntax in foo.aspx layout:

   1: <asp:Literal Text="<%$Resources:Test%>" runat="server" />

and ASP.Net will automatically get resource string with key Test from foo.aspx.resx file.

This approach simplifies localization of UI components in Sharepoint. The problem is that if we add our resource file as Content to Visual Studio project it will be added to result manifest.xml of wsp package during publishing. However if we will change it’s type to Embedded resource it won’t be added (which is needed if we want to use resource strings also from C# code), i.e. in this case we will need to update it manually (i.e. behavior is the same as for root resources described in the article mentioned above).

In order to fix this issue, i.e. in order to force Visual Studio to add embedded resx file from App_LocalResources folder to wsp package we will use the same approach described in Provision and automatic update of embedded resources to Resources folder in Sharepoint hive. But syntax of SharePointProjectItem.spdata file will be different. In case of local UI resources it will look like this:

   1: <?xml version="1.0" encoding="utf-8"?>
   2: <ProjectItem Type="Microsoft.VisualStudio.SharePoint.GenericElement"
   3: SupportedTrustLevels="All"
   4: SupportedDeploymentScopes="Web, Site, WebApplication, Farm, Package"
   5: xmlns="">
   6:   <Files>
   7:     <ProjectItemFile Source="..\..\..\Layouts\Test\App_LocalResources\foo.aspx.resx"
   8:         Target="Layouts\Test\App_LocalResources" Type="TemplateFile" />
   9:   </Files>
  10: </ProjectItem>

After that if you will publish wsp package reference on embedded resource will be added there:

   1: <TemplateFiles>
   2:     ...
   3:     <TemplateFile Location="Layouts\Test\App_LocalResources\foo.aspx.resx" />
   4: </TemplateFiles>

I.e. we will have all embedded resources provisioned automatically.

Friday, February 24, 2017

Problem with delayed propagation of Azure AD groups to Sharepoint Online

As you probably know in Sharepoint Online it is possible to use Azure AD groups which belong to your tenant for configuring permissions. The problem is that Azure AD security groups are not become available in Sharepoint Online immediately after creation, there is some delay between the moment when group was created and the moment when it can be resolved in Sharepoint people picker. If you have automation process which creates Sharepoint Online site, Azure groups and then grants them permissions on created site, you need to handle this delay.

One of the solutions is to make several attempts to try to resolve Azure AD group in Sharepoint. If group is not available yet, wait some time and repeat attempt. And you need to decide maximum number of attempts and delay between them. Here is possible solution:

   1: private static void AddAzureGroupToSharepointGroup(ClientContext ctx,
   2:     Microsoft.SharePoint.Client.Group spGroup, string azureGroupName)
   3: {
   4:     if (spGroup == null)
   5:     {
   6:         Console.WriteLine("Sharepoint group is null (Azure group name '{0}')",
   7:             azureGroupName);
   8:         return;
   9:     }
  10:     if (string.IsNullOrEmpty(azureGroupName))
  11:     {
  12:         Console.WriteLine("Azure group name '{0}' is empty", azureGroupName);
  13:         return;
  14:     }
  16:     Console.WriteLine("Add Azure group '{0}' to Sharepoint group '{1}'",
  17:         azureGroupName, spGroup.LoginName);
  19:     int num = 0, numOfAttempts = 30;
  20:     do
  21:     {
  22:         try
  23:         {
  24:             var user = ctx.Web.EnsureUser(azureGroupName);
  25:             ctx.Load(user);
  26:             ctx.ExecuteQueryRetry();
  27:             break;
  28:         }
  29:         catch
  30:         {
  31:             Console.WriteLine("Group '{0}' is not available yet (attempt #{1})",
  32:                 azureGroupName, num + 1);
  33:         }
  34:         Thread.Sleep(60000);
  35:         num++;
  36:     } while (num < numOfAttempts);
  38:     ctx.Web.AddUserToGroup(spGroup.LoginName, azureGroupName);
  39: }

This methods add specified Azure AD group to Sharepoint group. In order to make it work Azure group should be available in Sharepoint Online (should be resolvable in people picker). It makes max 30 attempts and waits 1 minute between each attempts (lines 19-36). If group is not available yet, then call to Web.EnsureUser() will throw exception (line 24). We catch this exception and increment attempts counter (lines 29-35). If group was resolved it means that it is propagated to Sharepoint Online (Azure AD groups are represented in Sharepoint Online as User object – in the same way as for regular AD groups) and we can add it to the Sharepoint group (line 38). Method Web.AddUserToGroup() is extension method which is implemented in OfficeDevPnP.Core.