Site Icon click to home page of root site - Best method

There are a few alternatives to how one can get SharePoint Icon to always go to the home page of the root site. (By default, it goes to the home page of current site, so it is an issue if you are in a sub-site)

I found the following JavaScript method best and most robust among all the alternatives. The alternatives were updating the link on document load etc. but all those assume that SP will not update that link after your script has run (which it does in Search Center)

var hijackSiteIconLinkClick = function () {
        $('.ms-siteicon-a').click(function (event) {
            event.preventDefault();
            event.stopPropagation();
            window.location.href = window.location.protocol + "//" + window.location.host + _spPageContextInfo.siteServerRelativeUrl;
        });
    };

The above works for every type of subsite as it runs on anchor click event and not when JS thinks that SharePoint page is loaded.

PS: The code above assumes that you have JQuery loaded on the page prior to running this script

O365 - Workflows sending mails

SharePoint Online Workflow in Office 365 cannot send emails to Distribution Lists. A few of my colleges have come across this issue when dealing with workflows in O365.

This information is widely enabled and there are a few blogs about it like - https://askmanisha.wordpress.com/2016/01/19/send-emails-to-distribution-lists-using-sharepoint/

So what you need is a mail enabled security group.

But wait, there is another piece to the puzzle which often stumps people. This mail enabled security group needs at least read-only access to the site where workflow is.

There you go, now you can successfully have workflows mailing stuff.

To summarize, two things required for workflow to send mail -
1. Mail enabled security group
2. Mail enabled security group having at least read-only permissions to the site.

Setting SharePoint SEO (Search Engine Optimization) settings using CSOM

I wanted to add viewport meta to my SharePoint page to make it responsive. The best way to do that I found and agreed with was to add it to Search Engine Optimization settings. Stefan Bauer has an excellent blog on it: http://www.n8d.at/blog/how-to-add-viewport-meta-without-editing-the-master-page/

So, next step was to be able to provision this via CSOM. So I wrote the following code does that:

public void SetSearchEngineOptimizationSettings(ClientContext ctx)

{

  var web = ctx.Web;

  web.AllProperties["seoincludecustommetatagpropertyname"] = "true";

  web.AllProperties["seocustommetatagpropertyname"] = "<meta name=\"viewport\" content=\"width=device-width,initial-scale=1,maximum-scale=1\" />";

  web.Update();

  ctx.ExecuteQuery();

}

Ref: https://lixuan0125.wordpress.com/2013/10/18/add-and-retrieve-property-bag-by-csom/

Ref: https://code.msdn.microsoft.com/office/Updating-Search-Engine-848b7c0d 

SharePoint Search URLs and how to use them in Webpart TitleUrl property

I recently came across a flaw/bug/defect with SharePoint that made me spend a lot of time on a simple thing, as simple as adding a TitleUrl to a content editor webpart.

The url I wanted my content editor webpart title to navigate to was a search result page:
/search/Pages/resultseverything.aspx#Default={"k":"","o":[{"p":"ViewsRecent","d":1}],"l":3081}

The mumbo-jumbo after # in the url instructs search result webpart to render the result ordered in the decreasing order of recent views. This is new Sharepoint way sorting using JSON format.

However, the pain point is that when you try and add this url to the TitleUrl property of the web part, SharePoint does not allow you to do that and throws an error.

I tried the encoded form of the above url: #Default=%7B%22k%22%3A%22%22%2C%22o%22%3A%5B%7B%22p%22%3A%22ViewsRecent%22%2C%22d%22%3A1%7D%5D%2C%22l%22%3A3081%7D

This did not work either, because when you now click on the link, SharePoint tries to encode this encoded string including '#' in the url and results in unexpected behavior.

This lead me to building my own custom solution to get around the issue (jQuery to the rescue).
(Assuming you have already added jQuery to your sharepoint site as custom action or otherwise)

First step:
I added the following url to the titleurl:
/Pages/resultseverything.aspx?TA

Second step:
Then added script editor on the page with following javascript:
$('h2.ms-webpart-titleText > a').click(function (e) {
                var redirectUrl = $(e.target.parentElement.parentElement).href;
                var i = redirectUrl.indexOf('?');
                var redirectUrlNew = redirectUrl;
                if (i >= 0) {
                    switch (redirectUrl.substring(i + 1)) {
                        case "TA":
                            redirectUrlNew = _spPageContextInfo.siteAbsoluteUrl + '/search/Pages/resultseverything.aspx#Default={"k":"","o":[{"p":"ViewsRecent","d":1}],"l":3081}';
                            break;
                    }
                }
                window.location.href = redirectUrlNew;
                e.preventDefault();
            });

So what the above code does is finds all the webpart title links and grabs their href element. Based on the token in front of '?', it redirects the page to the that location.

This was all hunky-dory except this does not prevent users from right-clicking on the link and going 'open in new tab/window' to end up going to the page - /Pages/resultseverything.aspx?TA and of-course, TA as a token does not do the sorting unless replaced by #Default =....

So another jQuery trick:

Third step:
$.each($('h2.ms-webpart-titleText > a'), function (i, value) {
                var hrefValue = $(value).attr('href');
                $(value).attr('data-redirect', hrefValue);
                $(value).removeAttr('href');
            });

$('h2.ms-webpart-titleText > a').click(function (e) {
                var redirectUrl = $(e.target.parentElement.parentElement).attr("data-redirect");
                var i = redirectUrl.indexOf('?');
                var redirectUrlNew = redirectUrl;
                if (i >= 0) {
                    switch (redirectUrl.substring(i + 1)) {
                        case "TA":
                            redirectUrlNew = _spPageContextInfo.siteAbsoluteUrl + '/search/Pages/resultseverything.aspx#Default={"k":"","o":[{"p":"ViewsRecent","d":1}],"l":3081}';
                            break;
                    }
                }
                window.location.href = redirectUrlNew;
                e.preventDefault();
            });

So the first part of the code above loops through all the webpart title links and removes their href attributes with 'data-redirect' attribute. By removing href attribute, one ensures that the browser no longer provides that 'right-click and open in new window' option. Also, as you may notice, I had to update the code of second step to use value of 'data-redirect' attribute rather than href.

This worked like a charm but took me way more time in accomplishing what I expected to have worked out-of-the-box for SharePoint.

I hope this saves someone's time.