Web-distribution of plain-old HTML/JS/CSS solution in Office 365

One of the many capabilities of SharePoint is that of webserver platform: host and distribute HTML/JavaScript/CSS based (mini)applications. With the birth of the SharePoint Framework (SPFx), I expect this role to be utilized a lot more in near future. The typical SharePoint setup for this web-distribution role is 1) a SharePoint page, 2) a ScriptEditor (or good-old ContentEditor webpart), and 3) the (mini)application itself consisting of an html-file for UI, potential javascript and/or css file(s), all stored as (SharePoint) content entities in a document library, or in a CDN.

SharePoint Online / Office 365 also supports this setup, and thus should be an equal fit for the role of web-distribution. However, you need to be aware of 3 aspects:

1. Default, custom script is not allowed in Office 365 tenant.

   You'll notice the effect of this when you try to add custom script in a ScriptEditor, or on using PageViewer webpart which refuses to remember the url to the (mini)application html file - (Office 365 SharePoint Online - Page Viewer Web Part Not Working)

   The resolution is to set in SharePoint Online Admin settings the allowance for custom script - (Turn scripting capabilities on or off). Be aware that it can take up to 24 hours before the effect of the change is actually applied in your Office 365 tenant.

2. ContentEditor prohibits 'FORM'tags in content:

   

   The resolution is to indeed use a PageViewer webpart, that is if the HTML contains a FORM tag. If not, good old CEWP accept the HTML as included content.

3. SharePoint Online only supports download action on .htm(l) file

   The Microsoft SharePoint team made an explicit design decision to only allow download of html files, and no rendering in browser - (Office 365 - Open html document in browser in document library).

   The simple resolution is to change the extension of the .htm(l) files into .axpx, then SharePoint (Online) will no longer include the "X-Download-Options: noopen" header in the HTTP response, and the file is opened in the browser rendering the html code.

On-the-fly extend ECB-menu

Say you have business data administrated in a SharePoint list/library, and you want to enable a custom action on the items. In the "old days" one would create a Feature that deploys a CustomAction. But nowadays we intend to / or even must (Office 365 /SharePoint Online) avoid server-side (or sandbox) deployments. Clientside-development is the new mantra. SharePoint as webapplication is strongly javascript-based, from 2007 and beyond. Also the handling of the Edit-Control-Block menu is via SharePoint javascript code. This makes it possible to "break" into that execution, and inject some own handling. Via F12 DeveloperTools I identified where to 'break into'/extend:

var EnrichListView = window.EnrichListView || {};

EnrichListView.UI = function () {

    function MyCustomItemAction(itemId) {
        // do something with the item identified by 'itemId'
    }

    function OverloadMenuHtc_show() {
        $.prototype.base_MenuHtc_show = MenuHtc_show;
         MenuHtc_show = function(oMaster, oParent, fForceRefresh, fFlipTop, yOffset) {
           if ($(oMaster).find("SPAN[id='ID_EditItem']").length == 1) {
               var itemId = oParent.childNodes[0].id;
               var spanInsert = $("<SPAN text='Custom Action on item' 
                    onMenuClick='EnrichListView.UI.MyCustomItemAction(" + itemId + ")' 
                    type='option' 
                    iconAltText sequence='200' 
                    CUICommand='CustomActionItems'
                    ></SPAN>");
               $(oMaster).append(spanInsert);
           }
           $.prototype.base_MenuHtc_show(
               oMaster, oParent, fForceRefresh, fFlipTop, yOffset);
           return false;

        };
    }

    var ModuleInit = (function() {
        ExecuteOrDelayUntilScriptLoaded(OverloadMenuHtc_show, "core.js");
    })();

    // Public interface
    return {
        MyCustomItemAction: MyCustomItemAction
    }
}();

Result:

This client-side approach is on itself future-proof, and also works online. The only caveat is that online Microsoft may change the javascript handling/code on which this code breaks into, without you knowing. The javascript code can also change due an update to SharePoint on-premise installation, but then you're aware of a change in the SharePoint installation and can prepare for the change in advance.

Automatic revert-to-self for InfoPath forms

(Functional) users working with more complex InfoPath forms may be familiar with below notorious error dialog:

A typical cause is that after saving the listitem, in the SharePoint background one or more workflows are triggered that also update the listitem. And that makes the state as loaded in the form (stateless setup) outdated, and InfoPath refuses next save due optimistic locking. Pragmatic way out is to force data reload in the form, and most simple approach to that is close the form as last action in the ‘Save’ rule. Drawback is that the user must self relocate the listitem again, reopen and set into edit modus.

Via javascript injection the standard InfoPath Forms Services handling can be overruled, and instead automate the relocate/reload/edit - revertToSelf:

var InfoPathCheck;
var maxNrChecks = 10;

$(document).ready(function(){
    InfoPathCheck = setInterval(function() {  //Wait for InfoPath to finish loading
        HasInfoPathLoaded();
    }, 200);
});

function HasInfoPathLoaded() {
    var selectAppl = $("#<form-id>");
    if (selectAppl.length > 0 || --maxNrChecks === 0) {
        clearInterval(InfoPathCheck);
        if (selectAppl.length > 0) {

            var saveBtns = $("input[id^='<form-id>_FormControl'][value^='Save']");   
            if (saveBtns.length > 0) {
                $(saveBtns).click(function() {
                   // Overload IP-function to return-to-self upon 'Save'.
                   CurrentFormData_UrlToNavigateToOnClose = function(a) {
                      return document.location.toString();
                   }
                });
            }
        }
    }
}

Hide columns from (grouped) ListView with conditional formatting

Calculated Fields in SharePoint Lists enable conditional (rich) formatting of raw data from one or more other columns in the same List. This is typically used to ‘business-beautify’ the data display for the end-users. Example is to render ‘Green/Orange/Red’ headlights for immediate visual reference, based on the raw ‘text’ data of a status/progress field. In such usage setup, only the conditional columns should be visible for end-users, not the raw data columns. However, the execution of SharePoint ListView requires that the source data columns are included in the view, otherwise the conditional columns lack their source data in the listview and render empty (or with an error, dependent upon formula).

Hide the columns from display

There are multiple approaches to still hide the ‘raw data columns’ from end-user visibility. My preference is for a CSS-based approach: hide via nth-child selector. For SharePoint 2010 + IE an extension is needed on top of this: IE only supports nth-child as of IE9, but the standard DocumentMode for SharePoint 2010 is IE8 (multiple of the standard SharePoint 2010 functionalities require this, and give browser-problems with document mode later than IE8). Luckily via jQuery the nth-selector is also available for the older IE-versions. The full setup to hide columns in a listview is therefore 2-staged:

1. CSS:

   
   /* 
    * Below CSS-selector is supported in >= IE9, Chrome, FF; but not supported in IE8
    */
   .ms-listviewtable th:nth-child(3),
   …
   .ms-listviewtable td:nth-child(3),
   … {
       display:none;
   }
   
   /*
    * This to compensate with non-support of nth-child in IE8 (compatibility mode)
    */
   .ms-listviewtable th.Hide, 
   .ms-listviewtable td.Hide  {
       display:none;
   }
   

2. JavaScript:

   
   function HideRawDataColumns() {
       $(‘.ms-listviewtable th:nth-child(3)’).addClass(‘Hide’);
       $(‘.ms-listviewtable td:nth-child(3)’).addClass(‘Hide’);
       ….
   }
   $(document).ready(function () {
        HideRawDataColumns (); 
   });
   

Grouped Views

Above approach breaks for ListViews with one or more Group By applied. The cause is in the deferred loading behavior by the ListView rendering: the data is delayed loaded only when the user clicks to open a group header, and also delayed rendered. For the fully CSS-based approach, this is not an issue: the CSS will be applied for all elements, also when later added to the rendering. The formula is a bit different though, as you need to distinguish between the ‘Grouping’ rows and the ‘Data’ rows. However, for SharePoint2010 + IE it is different. On initial page load moment, the data rows might not be present yet in the DOM, and the IE8 / JavaScript approach to explicitly determine + tag the TD-childs will fail. Solution is to delay the CSS-tagging to after the moment that the data-rows are actually added to the DOM. This requires to hook into the standard ListView javascript handling.

1. CSS:

   
   /* 
    * Below CSS-selector is supported in >= IE9, Chrome, FF; but not supported in IE8
    */
   .ms-listviewtable th:nth-child(3),
   …
   .ms-listviewtable td:nth-child(3),
   ..
   .ms-listviewtable tbody:not([groupString]) td:nth-child(3),
   … {
       display:none;
   }
   
   /*
    * This to compensate with non-support of nth-child in IE8 (compatibility mode)
    */
   .ms-listviewtable th.Hide, 
   .ms-listviewtable td.Hide  {
       display:none;
   }
   

2. JavaScript:

   
   var HideFormatColumnsListView = window.HideFormatColumnsListView || {};
   
   HideFormatColumnsListView.UI = function () {
   
       function HideRawDataColumns() {
           $(‘.ms-listviewtable th:nth-child(3)’).addClass(‘Hide’);
           $(‘.ms-listviewtable td:nth-child(3)’).addClass(‘Hide’);
           ….
   
   
           if ($.prototype.base_UpdateCtxLastSelectableRow === undefined) {
               $.prototype.base_UpdateCtxLastSelectableRow  = UpdateCtxLastSelectableRow ;
   
               UpdateCtxLastSelectableRow  = function(clvpCtx, clvpTab) {
                   $.prototype.base_UpdateCtxLastSelectableRow(clvpCtx, clvpTab);
   
                   var groupRow = clvpCtx.clvp.tBody;
                   if (groupRow !== null && groupRow !== undefined) {
                       $('td:nth-child(3)', $(groupRow)).addClass('Hide'); 
                       …
                   } 
              };
          }
       }
   
       var ModuleInit = (function() {
           ExecuteOrDelayUntilScriptLoaded(function () { HideRawDataColumns() }, "inplview.js");
       })();
   }();
   

SharePoint ignores MIMEtypes mapping unless on web server level

Earlier I reported that our business users request user-intuitive handling of non-Microsoft and non-standard file-formats that are administrated within document libraries. Enabling such in SharePoint on premise consists of 2 steps (See ‘SharePoint: Browser File Handling Deep Dive’ for an authoritative reference):

1. Add in IIS Manager a MIMEtype mapping for the involved file-extension(s)
2. Add the MIMEtype(s) to the AllowedInlineDownloadedMimeTypes configuration of the SharePoint webapplication(s)

These server-level configuration steps are not possible in Office 365 / SharePoint Online. I ensured that we can deliver our business users sustainable custom filetype handling on migrating to cloud deployment, via the utilization of Office 365 FileHandler Add-Ins concept.

Wrt MIMEtype mappings, IIS allows multiple levels on which you can configure these:

• Web server
• Site
• Application
• Physical and virtual directories
• File (URL)

Note that not all these levels are applicable to SharePoint as virtual webserver.

The web server level is most easy to execute, but drawback is that it requires an IISReset to become active. And that means a temporary down of any SharePoint webapplication hosted on the WFE. Therefore I instructed our operations to add the MIMEtype mappings on the Site level. To be disappointed afterwards: on download of the files from SharePoint, the content-type was still ‘application/octet-stream’ aka the “unknown type”, instead of the configured MIMEtype e.g. ‘application/vnd.spotfire.dxp’. Only when we add the MIMEtype to web server level, SharePoint returns in the file download response the configured MIMEtype.

I conducted an internet search on whether this is intentional, or at least known SharePoint / MIMEtype (mis)behavior. Only found some discussion posts ([1], [2]) inquiring about the effect we noticed (on SharePoint 2010 and SharePoint 2013 Server farms).

Augment the Org Chart with additional information

The SharePoint Organization Browser (Org Chart) is a convenient out-of-the-box functionality to display the organogram on user basis. The information of this typically comes from the HR system, and is propagated to SharePoint User Profiles. In our company we work with a lot of externals. All of them are also administrated in our HR system, and thus also provisioned to the User Profiles. Which is what we want. Only thing that our managers miss, is that in the Org Chart no visual distinction is made between internal and external subordinates. We have this information available in the User Profile in a custom property. But the Org Chart only displays the full names of the colleagues visualized in the organogram chart.

In the ‘old days’ we simple would have built a custom Org Chart, using server-side code. But in the current times, this is strongly advised against. We have an architecture guiding principle that all application customizations and extensions must be future-proof. Modifying or rebuilding something that a platform delivers out-of-the-box does not qualify for us as future-proof. The platform vendor might replace the current component by a complete different setup in the future, of which we would then miss out. In this particular scenario there is another reason to not replace the out-of-the-box delivered by a custom developed. The Organization Browser webpart is standard included on user profile page Person.aspx. To change that we would need to replace the inclusion of the webpart by an own. Note that for Person.aspx publishing page (= SharePoint content) it is possible to do this, on premise and also online, e.g. via SharePoint Designer. However, what online is not possible is to deploy a server-side webpart. Implication is that the future-proof custom Org Chart must be redeveloped fully from scratch (no reuse / extension possible of the standard Org Chart webpart), either via 100% clientside script, or as (Azure deployable) provider-hosted Add-In.

As said, Person.aspx can be modified in both on prem as online. Better sustainable approach is therefore to extend on the out-of-the-box functionality with the requested customization. Inject a reference to an own JavaScript file, and in that file include a method to extend the displayed names of a colleague’s subordinates with information on whether internal or external. We have this information as user profile property, and this can in clientside context be retrieved via the UserProfile REST service.

Dynamic extend the Organisation Browser rendering with additional User Profile information

enrichOrgChartWithExternalOrg = function() {
   jQuery("#ReportingHierarchy").find("TR.ms-orgme").next().find("TD.ms-orgname > a").each(function(index) {
       var anchor = this;
       var href=jQuery(anchor).attr("href");
       var accountName = unescape(href.substr(href.indexOf("accountname=") + "accountname=".length));

       jQuery.ajax({
  url: _spPageContextInfo.webAbsoluteUrl + "/_api/SP.UserProfiles.PeopleManager/GetUserProfilePropertyFor(accountName=@v,propertyName='ExternalOrganization')?@v='" + accountName + "'",
  contentType: "application/json;odata=verbose",
         headers: { "accept": "application/json;odata=verbose" },
  success:function(data){
            if (data.d.GetUserProfilePropertyFor.length != 0) {
                var extCompName = data.d.GetUserProfilePropertyFor.substr(0, data.d.GetUserProfilePropertyFor.indexOf(" - "));
                var augmentedSubordinateName = jQuery(anchor).html() + " (" + extCompName + ")";
                jQuery(anchor).html(augmentedSubordinateName);
            }
  }
       });
   });
};

Standard Organisation Browser display extended with additional User Profile information

Note, the above code retrieves the extra user profile property per subordinate in a loop-control, each iteration includes a request-reply to the UserProfile REST service. To reduce the network latency impact from the client to SharePoint and back, one would want to avoid the loop and request all in one http request. The REST protocol supports this via $batch (Get UserProfile Properties with REST API Batching. And SharePoint Online and SharePoint 2016 are a good REST citizens, but SharePoint 2013 on premise is not: $batch is not supported. (Make batch requests with the REST APIs).

(scroll)height of children influences scrollheight of page

This is a follow-up on earlier post ‘Freeze pane on SharePoint list’

Business users very much appreciate the inserted functionality to freeze the listview header in visible top of screen, while one scrolls through the content. However, they reported a problem in case of smaller display size: it was not possible to scroll completely to the bottom, and also the page navigation controls cannot be reached.

The cause is that in my initial code I decided to unconditional hide the page scrollbar. I decided for this as otherwise the page scrollbar would remain in state to scroll through a large list, despite my changes to reduce the height of that list and give it a scrollbar for itself.

The simple way out to resolve the reported issue would be to just not hide the page scrollbar. But from User Experience point of view I dislike that, the result with 2 scrollbars and the page scrollbar over full initial height, is confusing for end users. I instead opted for only displaying the scrollbar when needed (screen smaller as minimal height for listview), and in such case reduce the scrollheight of page to only scroll to the bottom of the height-reduced listview. Thus not for the full initial height.

At first (html) code attempts this was not that simple to achieve, whatever reduction I made still the page scrollheight remained at the initial large value. Via debugger I identified the cause. The scrollheight of the listview remained at the large value, despite that I reduced the visible height. And the scrollheight of page as parent is directly influenced by the sum of scrollheights of the child elements in page. The scrollheight value is readonly, thus not possible to also reduce this to match the reduced height of the listview Div element.

Post ‘Making elements not affect page height (thus scrolling)’ put me on track to break out of this: It appears that scrollheight of relative positioned children has impact; but not that of absolute positioned children. So what I needed to change in my initial FreezePane code was to break the relative parent-child positioning relation for the listview with respect to page. This is accomplished by following changes:

    // Set visible height, with minimum of 300
    var visibleTableHeight = Math.max(availableHeight, 300);

//    $table.wrap("<DIV class='FreezedLV' style='OVERFLOW: auto; HEIGHT: 500px;'></DIV>");
    $table.wrap("<DIV class='FreezedLV' style='position:absolute; left:0; top: 0; width:100%; OVERFLOW: auto; HEIGHT: " + visibleTableHeight + "px;'></DIV>");
 
//    $(".FreezedLV").wrap("<DIV class='FreezedLVContainer'></DIV>");
    $(".FreezedLV").wrap("<DIV class='FreezedLVContainer' style='position:relative; margin:0px; height:" + (visibleTableHeight + freezedTRHeight) + "px;'></DIV>");

The end-result: now truly happy users, some of which forced to view the page on small(er) laptop screensizes.

The complete 'FreezePane' method:

function FreezePane() {
    var $table = $(".ms-listviewtable").first().data("summary", "list name");

    // Determine the available height for table to render in visible screen.
    var origWorkspaceHeight = $("#s4-workspace").height();
    var origTableHeight = $table.height();
    var spaceInWorkspaceWithoutTable = origWorkspaceHeight - origTableHeight;

    var windowHeight = window.innerHeight;
    if (windowHeight == undefined) {
        windowHeight = document.documentElement.clientHeight;
    }
    var topPos = $("#s4-workspace").offset().top;
    
    var freezedTRHeight = 25;
    var availableHeight = windowHeight - topPos - spaceInWorkspaceWithoutTable - freezedTRHeight;

    // Set visible height, with minimum of 300
    var visibleTableHeight = Math.max(availableHeight, 300);

    // WRAP TABLE IN SCROLL PANE
    $("#s4-workspace").css( { 'overflow-y': 'auto' } );

    $table.wrap("<DIV class='FreezedLV' style='position:absolute; left:0; top: 20; width:100%; OVERFLOW: auto; HEIGHT: " + visibleTableHeight + "px;'></DIV>");

    // FROZEN HEADER ROW
    $(".FreezedLV").wrap("<DIV class='FreezedLVContainer' style='position:relative; margin:0px; height:" + (visibleTableHeight + freezedTRHeight) + "px;'></DIV>");
    $("<table id='FreezedTR' class='ms-listviewtable' cellPadding='1' cellSpacing='0'></table>").insertBefore(".FreezedLV");
    $("#FreezedTR").width($table.width() + "px");

    var $origHeader = $("TR.ms-viewheadertr:first", $table);
    var $firstRowTable = $("TR.ms-itmhover:first", $table);
    var $freezeHeader = $origHeader.clone();
    // Propagate computed width of columns of origheader to freezeheader
    $origHeader.children("th").each(function() {
        var width = $(this).width();
        var ownerIndex = $(this).index();
        $($freezeHeader.children("th")[ownerIndex]).width(width + "px");
    });

    $("#FreezedTR").append($freezeHeader);
    $("#FreezedTR").append($firstRowTable.clone());
    $("#FreezedTR").wrap("<DIV style='OVERFLOW: hidden; HEIGHT: " + freezedTRHeight  + "px;'></DIV>");
    // Visualize "hide" the orig header, make sure it still is rendered as otherwise the alignment of 'body' rows is altered
    $origHeader.children("th").each(function() {
        $(this).css( { 'height' : '0px' , 'max-height' : '0px', 'min-height' : '0px' , 'padding-top' : '0px', 'padding-bottom' : '0px' } );
        $(this).find("div").css( { 'height' : '0px' , 'max-height' : '0px', 'min-height' : '0px', 'margin-top' : '0px', 'margin-bottom' : '0px' } );
        $(this).find("input").css( { 'height' : '0px' , 'max-height' : '0px', 'min-height' : '0px' } );
    });
    $origHeader.css( { 'max-height' : '1px', 'visibility' : 'hidden' } );

    // Delegate eventhandlers from the copied+freezed header to the actual header of the listview.
    var $inputFH = $freezeHeader.find("input[title='Select or deselect all items']");
    $inputFH[0].onclick = null;
    $inputFH[0].onfocus = null;
    $table.onmouseover = null;
    $inputFH.click(function() {
       $(this).closest(".FreezedLVContainer").find(".FreezedLV .ms-viewheadertr").find("input[title='Select or deselect all items']").trigger('click');
    });
    $inputFH.focus(function() {
       $(this).closest(".FreezedLVContainer").find(".FreezedLV .ms-viewheadertr").find("input[title='Select or deselect all items']").trigger('focus');
    });
    $("#FreezedTR").mouseover(function() {
       $(this).closest(".FreezedLVContainer").find(".FreezedLV .ms-listviewtable").trigger('mouseover');
    });
}