How to hide Shared With ECB menu item for non-admin users via javascript

In Sharepoint lists and doclib there is possibility to check which users have access to list item or file using “Shared With”. Often this item should be hidden for non-admin users. Below javascript allows to hide “Shared With” ECB menu item for users which are not site admins:

SP.SOD.executeFunc("sp.js", "SP.ClientContext", function () {
	var ctx = SP.ClientContext.get_current();
	var user = ctx.get_web().get_currentUser();
	ctx.load(user);
	ctx.executeQueryAsync(
		Function.createDelegate(this, function () {
			var isSiteAdmin = user.get_isSiteAdmin();
			if (isSiteAdmin) {
				return;
			}
			jQuery("td.ms-list-itemLink-td").click(function(){
				setTimeout(function(){
					jQuery("span.js-callout-ecbActionDownArrow a").click(function(){
						setTimeout(function(){
							jQuery("li[text='Shared With']").hide();
						}, 200);
					});
				}, 200);
			});
		}),
		Function.createDelegate(this, function (sender, args) {
			// log error
		}));
});

Here we first check whether current user site admin or not. After that we add our own event handler for ECB click item which hides “Shared With” command. Little delay is needed in order to allow ECB sub menu to be displayed after original click handler will be triggered.

Set O365 group classification via Graph API

Some time ago MS announced possibility to specify groups classifications – see e.g. Classifications for Office365 Groups and Microsoft Teams. After you configured classifications on tenant level like shown in mentioned article when you go to Sharepoint app from your Office 365 App launcher (it will lead to https://{tenant}.sharepoint.com/_layouts/15/sharepoint.aspx) and choose “+ Create site” from the header – you will see dropdown list with specified classifications:

When you will create new site classification will be shown in the header:

Also if you will get related group via Graph API – classification will be returned with other group’s properties:

GET https://graph.microsoft.com/v1.0/groups/{id}/classification

will return

{
  "@odata.context": "https://graph.microsoft.com/v1.0/$metadata#groups('{id}')/classification",
  "value": "internal"
}

But is it possible to update group’s classification programmatically? If we just try to send PACTH request on https://graph.microsoft.com/v1.0/groups/{id} endpoint we will get the following error:

{
    "error": {
        "code": "Request_BadRequest",
        "message": "Property 'classification' is read-only and cannot be set.",
        "innerError": {
            "request-id": "...",
            "date": "2018-05-28T14:22:55"
        }
    }
}

The answer is however yes it is possible: in order to set classification of O365 group via Graph API you need to use beta endpoint instead of v1.0: https://graph.microsoft.com/beta/groups/{id}. In this case property should be successfully updated.

Note that team site classification is stored in own property Site.Classification. So if you updated group’s classification you may also want to update classification of related site. If you use SiteExtension.SetSiteClassification from OfficeDevPnP both actions will be done automatically.

Solve problem with missing Get-AzureADDirectorySetting and Set-AzureADDirectorySetting PowerShell cmdlets

If you want to play with Office 365 classifications you will need to configure tenant-level directory settings which contains available values which can be used for groups’ classifications. You may do it using Get-AzureADDirectorySetting and Set-AzureADDirectorySetting cmdlets like shown in the following article: Classifications for Office365 Groups and Microsoft Teams. But if you will follow this article and install both AzureAD and AzureADPreview modules from PowerShell gallery:

Install-Module AzureAD
Install-Module AzureADPreview

and then will connect to Azure AD using command:

Connect-AzureAD

and after that will try to use Get-AzureADDirectorySetting cmdlet you may get the following error:

The term 'Get-AzureADDirectorySetting' is not recognized as the name of a cmdlet,function, script file, or operable program

The problem is that on the moment of writing this post Get-AzureADDirectorySetting cmdlet was defined only in AzureADPreview module. You may check it if will execute the following command:

man Get-AzureADDirectory*

For me it produced the following result:

Name                              Category  Module                    Synopsis
----                              --------  ------                    --------
Get-AzureADDirectoryRole          Cmdlet    AzureADPreview            Gets a directory role.
Get-AzureADDirectoryRoleMember    Cmdlet    AzureADPreview            Gets members of a directory role.
Get-AzureADDirectoryRoleTemplate  Cmdlet    AzureADPreview            Gets directory role templates.
Get-AzureADDirectorySetting       Cmdlet    AzureADPreview            Gets a directory setting.
Get-AzureADDirectorySettingTem... Cmdlet    AzureADPreview            Gets a directory setting template.
Get-AzureADDirectoryRoleMember    Cmdlet    AzureAD                   Get-AzureADDirectoryRoleMember...
Get-AzureADDirectoryRole          Cmdlet    AzureAD                   Get-AzureADDirectoryRole...
Get-AzureADDirectoryRoleTemplate  Cmdlet    AzureAD                   Get-AzureADDirectoryRoleTemplate..

As you can see Get-AzureADDirectorySetting cmdlet is defined in AzureADPreview.

So solution is to start new PowerShell session and connect to Azure AD using Connect-AzureAD from AzureADPreview module:

AzureADPreview\Connect-AzureAD

After that Get-AzureADDirectorySetting and Set-AzureADDirectorySetting cmdlets should become available.

Redirect Sharepoint WebDAV network locations from http to https

As you probably know it is possible to connect to Sharepoint sites and doclibs via WebDAV in Wnidows explorer view, by creating new network location or by mapping new network drive to Sharepoint site. If your site works via http WebDAV will use http, if site uses https – WebDAV also will work over https. What if you want to force users to use https instead of http?

First of all you have to configure your Sharepoint stie to use https (purchase SSL certificate, install it on your IIS server, add https binding to Sharepoint site in IIS manager, change alternate access mappings in Central administration). After that you need to redirect traffic from http to https. In order to do that use URL Rewrite IIS module and add new blank rule which looks like this:

This rule will redirect http requests to https in browser. But also it will redirect http to https for WebDAV clients. If you will open fiddler and will try to open network location which uses http url then you will see something like that (test was done on Windows 10 client):

Request headers:

PROPFIND http://example.com
User-Agent: Microsoft-WebDAV-MiniRedir/10.0.16299

Response headers:

HTTP/1.1 301 Moved Permanently
Location: https://example.com

Where instead of example.com will be url of your Sharepoint site. I.e. URL Rewrite IIS module successfully redirects traffic also for WebDAV.

Problem with sync delay between Azure AD and Sharepoint Online when Rest API is used

When you create user or group in Azure AD it is not immediately available in Sharepoint Online. I wrote about this problem here: Problem with delayed propagation of Azure AD groups to Sharepoint Online. In this post I will describe another interesting problem which may occur because of this delay.

Azure AD group members and owners may be retrieved with Graph API and with Rest API:

Graph AP endpoint:

https://graph.microsoft.com/v1.0/groups/{groupId}/members

Rest API endpoint

http://example.com/_api/SP.Directory.DirectorySession/Group('{groupId}')/members?$select=displayName,id

where instead of http://example.com you need to use url of your Sharepoint site.

The problem is that until Azure AD data won’t be fully synced to Sharepoint Online Rest API may return not correct data. E.g. /members endpoint may return actually owners, while /owners endpoint may not return users at all. Depending on how fast MS data center will propagate changes it may take up to several hours. So be aware about this problem.

The main advantage of Rest API endpoint is that it returns members count. While in Gtaph API $count query string parameter is not supported for users and groups: Use query parameters to customize responses:

Note: $count is not supported for collections of resources that derive from directoryObject like collections of users or groups.

So you may want to use Rest but notice that it may work incorrectly first several hours.