Archive for June, 2015


In this article I explore how to check whether the login user has full permission or not using the SharePoint 2013 REST API.

I wanted to avoid using JSOM and do everything with REST. Fortunately, I understand that you must rely on JSOM for certain things. In this case JSOM has the SP.BasePermissions type with methods for combining sets of permissions. This type is defined in SP.js. JSOM also exposes the types of permissions as a basic integer enumeration as SP.PermissionKind. This enumeration is defined in SP.Runtime.js. I still could not figure out how to get the high and low values for the permission. I knew what the values were supposed to be for the EditLisitItems permission. Looking at the permission in debug view I noticed the values were exposed by the typical nonsensical property names $4_1 and $5_1 . Whenever you set the permission with a permission kind the JSOM function will bit-shift the values and re-calculate the high and low values.

Normally we need to perform tasks such as:

  • Does the current user have admin permission on the site
  • and so on

SharePoint provides a method called doesUserHavePermissions to do that. First of all we need to understand how SharePoint defines user roles by assigning permission levels such as Full Control, Contributor, design and so on.

For example, a site admin is assigned by Full Control that is a composite of a few permission items we call the permission kind.

Full Control: Permission levels and permissions


Assume that we want to check whether the current user is an admin of the site. For that we need to check that the user has the manageWeb permission kind. (Actually we need to check whether other permission kinds are assigned full control as well but if the user has manage web permission then it is more likely the user can perform admin tasks. In my other example I will show how to check the full permission kinds).


  1. function getUserWebPermissionREST() {
  2.     //Permission for admin to show or hide the entries on memory board using ShowOnHomePage Field
  3.     var perm = new SP.BasePermissions();
  4.     perm.set(SP.PermissionKind.manageWeb);
  5.     $.ajax({
  6.         url: _spPageContextInfo.webAbsoluteUrl + “/_api/web/doesuserhavepermissions(@v)?@v={‘High’:'” + perm.$4_1.toString() + “‘, ‘Low’:'” + perm.$5_1.toString() + “‘}”,
  7.         type: “GET”,
  8.         headers: { “accept”“application/json;odata=verbose” },
  9.         success: function (data) {
  10.             var d = data.d.DoesUserHavePermissions;
  11.             if (d === true) {
  12.                 //Show Check Box if Full Control
  13.             }
  14.             else {
  15.                 //hide Check Box
  16.             }
  17.         },
  18.   error: function (err) {
  19.             alert(JSON.stringify(err));
  20.         }
  21.     });
  22. }


In this blog you will see the solutions of common time zone issue of SharePoint.


This is almost certainly a result of your timezone.

When a Date Only picker returns a value, it returns a DateTime, where the time component is midnight for the local timezone – e.g. 2012-01-04 00:00:00.

When this value is converted to UTC time, it can become a value for the previous day. For email, if the local time zone for the above datetime is +2, then UTC time would be 2012-01-03 22:00:00.

Naturally, if you simply look at the date part of the date time, this now appears to be an entire day before. I would suggest you start by looking at the date component of the Expiry date – is that offset by your timezone setting?

SharePoint does store all datetimes in UTC time, so it will convert that local datetime to UTC. I’m not sure, off the top of my head, what timezone the datetimes in the AfterProperties are in.


The problem I’m updating a list with a date field (just the date) using the Client object model but when the date is inserted is one day off from the introduced date

After searching for a long time, it turns out that the “problem” was how SharePoint stores dates. Indeed SharePoint converts dates to UTC … that’s why my comparison was not good!

So when you want to work in code behind with dates, do not forget to convert to UTC!

For this, two methods:

SPTimeZone.UTCToLocalTime et SPTimeZone.LocalTimeToUTC


Another option would be to retrieve the time zone of SharePoint and explicitly convert now in local time by using the .NET Framework when you save the item list as shown below.

//1.Retrieve SharePoint TimeZone

  1. var spTimeZone = context.Web.RegionalSettings.TimeZone;
  2. context.Load (spTimeZone);
  3. context.ExecuteQuery ();

//2.Resolve System.TimeZoneInfo from Microsoft.SharePoint.Client.TimeZone

  1. var fixedTimeZoneName = spTimeZone.Description.Replace(“and”“&”);
  2. var timeZoneInfo = TimeZoneInfo.GetSystemTimeZones().FirstOrDefault(tz => tz.DisplayName == fixedTimeZoneName);

//3.Convert Time

  1. listItem [“DateTime”] = TimeZoneInfo.ConvertTimeFromUtc (dt, TimeZoneInfo);