Friday, November 17, 2017

Convenient delete a single document from large list

SharePoint Lists and Libraries can store large amounts of (document) items. This does complicate the management of the stored items: before you can edit or delete the item, you need to find it in the large list storage. As result of the listview threshold max 5000 items are displayed, and you will therefore likely spend a lot of time navigating page-wise through the list/library before you eventually find the item you want to manage. When it concerns a regular list, you can automate this item-search via "search in 'this list'" (<site-url>/_layouts/OSSSearchResults.aspx?cs=This%20List&u=<list-url>); however for managing document items this does not help: the searchresult does not display the document library ribbon, and thus you cannot activate for instance the 'Delete Document' action. But the SharePoint toolbox has more to offer: setup an interactive listview search experience by combining it with a connected TextFilter webpart. For the how-to I refer to Connect a Filter Web Part to a List View Web Part on a classic page.
Screen impression of the convenience result:

Tuesday, November 7, 2017

Retrieve data from a large list via REST

The infamous ´5000´ listview threshold, we all have encountered that limit at least once in utilizing SharePoint as data backend. This time I was consulted by a business user that utilized SharePoint´s data management capabilities for storage of above 135,000 listitems. Wrt storage this amount is not an issue, but for retrieving it can be due the listview threshold. The advised approach to deal with that is via indexed columns, and tabbed/indexed views. That is for retrieving + viewing the big amount of listitems in the standard SharePoint UI. But what about requesting the data via SharePoint REST service? The REST protocol promises to support a similar navigation/tabbed experience via $top and $skip parameters. However, here SharePoint (2010) demonstrates to be not a fully compliant REST citizen. The $top parameters works fine on indexed large list, but usage of $skip results in an HTTP 500; and in ULS the error "Throttled:Big list slow query. List item query elapsed time: 0 milliseconds" is logged.
Also here it turns out that the '5000 threshold' is such a common encountered SharePoint issue. Internet search within a few hits leads to the helpful Stackoverflow resource: SharePoint 2010 REST top, skip fails on large list:
$skip query option is not supported, but $top is. Workaround, use a mix of $orderby on ID, $filter on ID and $top x items, and loop
Pseudo-code to loop through the entire big SharePoint List:
var nextId = 0;
WHILE TRUE DO
    var getData = $.getJson(“<site-collection url>/_vti_bin/listdata.svc/LargeList"
          + "?$select=Id,Name&$top=1000&&orderby=id&$filter=Id gt " + nextId);
    if (getData is not empty) {
        nextId = getData(last)[id];
    } else {
        break;
    }
END DO

Tuesday, October 31, 2017

Microsoft security (tools) landscape

Microsoft as platform vendor takes information security and protection very serious. It delivers a diverse set of tools and services to help enterprises protect the valuable resources. The protection differentiates on 4 layers:
  1. Devices
  2. Apps
  3. Files
  4. Identity
In below diagram, the palette of tools are displayed in their mutual relationships in the full Microsoft security landscape (with thanks to Peter van Leeuwen / Microsoft):
Legenda:

AbbreviationExplanation
AADAzure Active Directory
ADFSActive Directory Federation Services
MAMMobile Application Management
MDMMobile Device Management
MFAMulti-Factor Authentication
MIMMicrosoft Identity Manager
NDESNetwork Device Enrollment Service
PIMPrivileged Identity Management
RMSRights Management Services
SCCMSystem Center Configuration Manager
SSOSingle Sign-On
WIPWindows Information Protection

Thursday, October 19, 2017

Tip: code-snippet to enlarge image in context of SharePoint page

Requested Web Content Management (WCM) capability: include smaller / shrinked version of an image in the body of a page, and enlarge it on user click while remaining within the context of the page.

The rich SharePoint platform enables this with a small code snippet, via re-use of the standard SP.UI.ModalDialog.showModalDialog function. Reusable code-snippet:

<div>
   <script type="text/javascript">  
       function EnlargeImageInDialog(elem) {
           var imgUrl = $(elem).find("img").attr("src");
           imgUrl = imgUrl.replace("/_w/", "/").replace("_png.jpg", ".png”);
           var popupImg= 
                 "<div id='enlargeImg'><img src='" + 
                 imgUrl + 
                 "' style='margin: 5px; width:1200px;'/></div>";
           $(elem).append(popupImg);     
 
           SP.UI.ModalDialog.showModalDialog({
              html: document.getElementById('enlargeImg'),
              title: "...",
              allowMaximize: false,
              showClose: true,
              autoSize: true
           });
       }
    </script>   
    <a onclick="EnlargeImageInDialog(this); return false;" href="">
        <img src="/.../PublishingImages/_w/..._png.jpg" alt="" style="margin: 5px;"/>
    </a>
</div>
Example of the effect:
Smaller image (reference) in the web content page
Enlarged image displayed within context of the webpage via a SharePoint UI modal dialog popup

Sunday, August 27, 2017

Community answerring on typical SPFx usage scenarios

Vesa Juvonen asked the community to give some typical examples of business 'applications' that are build as client-side applications, before typical by utilizing ContentEditor or ScriptEditor. And now likely candidates for SharePoint Framework (SPFx) utilization:
Naturally I'm a good community participant / citizen, and answerred with some example scenarios I build myself of behalf of internal business stakeholders...

Friday, July 21, 2017

Enable CORS not possible on SharePoint authenticated application without HttpModule

On 1st research, enabling CORS on SharePoint (on-premisse) web applications seems to be easy: just configure it in the web.config.
Source: enable Cross-Origin Resource Sharing - CORS on IIS7:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
 <system.webServer>
   <httpProtocol>
     <customHeaders>
       <add name="Access-Control-Allow-Origin" value="*" />
     </customHeaders>
   </httpProtocol>
 </system.webServer>
</configuration>
(also given as answer on stackoverflow: Enable CORS in SharePoint 2013)
However, on validating the effect of the config change, it turns out that the web.config based approach is insufficient in case of authenticated SharePoint application. You encounter 2 issues with only the configuration based approach:
  1. In the web.config you can only specify either the '*' or explicit client domain for the Access-Control-Allow-Origin header. To interoperate with an authenticated application, you need to pass authorization headers and set Access-Control-Allow-Credentials to true. The issue is that according to the CORS specification (see also explanation on MDN, HTTP Access Control), if Access-Control-Allow-Credentials is set to true, Access-Control-Allow-Origin cannot contain *, to disallow just any client making requests with credentials attached. Also on CORS specification level, it is documented that in case of specific domain list, it actually means 1 single specific domain (https://www.w3.org/TR/cors/#access-control-allow-origin-response-header). This limits enable CORS to a single client application.
  2. First call in the CORS protocol, is HTTP OPTIONS to establish whether CORS is allowed between client host domain and server host domain. A web.config enabled SharePoint application responds successful on the OPTIONS call with CORS-allow headers. However, SharePoint / IIS returns for authenticated webapplication the OPTIONS response with status code 401; and as result the preflight handling is stopped in browsers that respect the CORS specification.
Conclusion:
Enable CORS for a SharePoint / IIS authenticated webapplication, cannot be done via configuration only. Resolving both issues strict on SharePoint level is possible, but requires a custom HttpModule. If such server-side deployment is not allowed, another option is to resolve it on infra level, via a Reverse Proxy setup.

Saturday, July 15, 2017

Approach to performant display from a SPList with multiple Lookups + Person fields

Issue: business users complain that the page loading of a SharePoint listview takes a long time, up to a minute. During page loading + rendering, the browser is totally unresponsive (Chrome even pops up a dialog about page unresponsive).
In the analysis for the root cause of this structural slow performance I observe that the list contains multiple Lookup fields to other lists in the site, and also a 'Person or Group' field - which is a specific type of Lookup, to the hidden UserInformationList.
This multitude of Lookups in the list is the most significant cause for the slow performance. However, also on user experience / functional level, it is wrong designed: the usage of the page is to first load + display all the items from the list, and next the end-user must filter to select the relevant items.
I therefore first aligned with business owner on another functional approach: let the end-user start with specifying the relevant filter(s) [can be a combination of filters for multiple columns], and then select + retrieve only the items from the list that satisfy the filter-conditions. For the technical design, the Search tool must be setup future-proof, aka cloud ready. Thus interoperating with SharePoint either via CSOM or via REST services. I decided to utilize REST, so that data is returned in JSON data-format, and can be directly data-binded in client-side UI (I used Knockout.js; but same holds for other clientside UI frameworks as Angular, Ember).
In SharePoint REST one uses the $expand parameter to include referred lookup values in the result set. But similar as for XsltListView, this quickly destroys any performance:
So I needed a way to avoid the Lookup-expands, while still being able to filter on and select the values of the Lookup fields. Totally getting rid of the Lookup columns is not an option: for consistent data-management it is a Must-Have that one can select only from the values maintained in the Lookup list. And it holds even more for the Person field: selecting via the PeoplePicker ensures a user-friendly selection + validation.
The approach I decided to is to 'flatten' the lookup values in additional columns. Functional management can still manage the data-items using the lookup functionality, and on data-selection + retrieval I avoid the need to $expand.
The elements of the approach
  1. Per lookup value that is needed in the selection and/or display, add a single-line of text column to the list. Set them to hidden in the Item content type, so that their existense is invisible for functional management in the New/Edit/View list-forms;
      For the 'Person or Group' column, include 4 new fields, for
    1. Person Name,
    2. Photo,
    3. Department,
    4. and the UserId in the UserInformationList
  2. Create a SharePoint Designer Workflow on the list that activates on ItemCreated + ItemModified events. Design the workflow to propagate ('flatten') the lookup values to their respective flattened counter-field;
  3. Realize the bulk flattening of the existing list items through the same workflow, via javascript start the workflow on every item.
Impression of the solution setup + result