Sunday, October 22, 2017

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.



Tuesday, February 21, 2017

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();
}


Monday, February 20, 2017

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.