SharePoint

The last month, Microsoft announced the strategy, vision, and timeline for SharePoint 2019.

From the screenshots provided, it is evident User Experience has improved. Though the article has listed the key features, we have to wait to experience what changes SharePoint 2019 brings to the users.

SharePoint 2019 is available to the customers in second half of this year. Preview should be available to the customers soon.

Check this article for details.

In SharePoint 2013 on-premises site, if you are trying to apply a filter on EndDate column (or EventDate column) of a Calendar List using REST API, it throws the below error.

The field 'EndDate' of type 'DateTime' cannot be used in the query filter expression.
Basically we cannot use EndDate column in the filter query. That sounds weird but it looks to be a "miss" from the SharePoint product team.

However, it is interesting to note that this filter works fine in SharePoint Online (SPO). So the sample query like below returned valid items.

https://domain/sites/pub/_api/web/lists/getByTitle('Calendar')/items?$select=Title,EndDate&$filter=EndDate lt '2018-05-31T23:59:00Z'

So, the Product team might have fixed the issue in SPO. Hope this should be resolved at least in SP2016.

When we have to implement Delete operation using REST API, we normally use the straightforward method to delete an item or a document. For example, to delete an item from a List, we use the following code.

$.ajax({ 
 type: "POST", 
 url: _spPageContextInfo.webAbsoluteUrl + "/_api/web/lists/getByTitle('CustomList')/items(2)", 

 headers: { 
   "accept": "application/json; odata=verbose",
     "X-HTTP-METHOD": "DELETE",
     "IF-MATCH": "*",
     "X-RequestDigest": $("#__REQUESTDIGEST").val()
 },

 success: function(data){
     alert("Item is deleted!");
 },
 error: function(error){
     alert("Error"); console.log(error);
 }

});

To delete a document from a Library, we use the below code.

$.ajax({ 
 type: "POST", 
 url: _spPageContextInfo.webAbsoluteUrl + "/_api/web/getfilebyserverrelativeurl('/sites/pub/Documents/DocIcon.png')"…

Though SharePoint handles security trimming throughout the site, sometimes when you need to create custom pages and controls, you would need to check the permissions of the logged in user to allow/block certain actions. For example, only if a user has permission  to edit list items, show Edit button. So how do you check if the logged-in user has the required permission or not?

SharePoint provides a REST endpoint "effectiveBasePermissions". Using this endpoint, you can check if the user has required permission or not.

THE URL syntax is: [Domain]/[Site]/_api/web/lists/getByTitle('ListName')/effectiveBasePermissions.

Interestingly, this endpoint returns data as JavaScript Object Model (JSOM) object. So to use this data, you would need to load two libraries sp.runtime.debug.js and sp.debug.js. These libraries are available at 15 hive folder.

Let me show you the complete code (jQuery should be loaded for this code). This code is tested in SharePoint Online and it should …

I came across an interesting behavior. I had created a custom page with custom logic. I had to pass a parameter and a number so that I can use the value in the code.

So the URL looks something like this:

http://[Domain]/[SiteCollection]/Page/MyCustomPage.aspx?Id=[number]

When I navigate to this page, MyCustomPage was not loading, instead SharePoint was giving "Page not found" error. If I navigate to the same page without passing a parameter, it renders the page without any problem. That means, when I pass a parameter in the URL, SharePoint was treating the entire URL as a page URL. Since it doesn't exist, it was throwing page not found error.

This was one of those weird behaviors which is hard to comprehend. After a bit of Googling, I came across this article by Stefan Goßner. In this article Stefan lists some of the parameters which we should not be using as they are reserved query string parameters. Though the article is specific to MOSS 2007 and SharePoint 2010, the i…

Security trimming is an important feature in SharePoint. The permissions defined in a site is "respected" throughout the site including the APIs. So once you define a permission, wherever you navigate, the permissions are applied and accordingly you will (not) see the data.

What does it also mean that if you are using REST API to fetch data from a SharePoint site, the API returns data with security trimmed. So you don't have to apply any additional filter to the query. The same query might return 10 items for one user, 20 items for another user based on the user's permission on items.

Also, let us say, you are trying to get a list of Apps (Libraries and Lists) from a site using REST and you are displaying that on a page. Also assume that you have not given permission to 5 out of 10 Apps to the user "User A".

How many Apps User A get to see in a page? It's not 5 but all. Remember, this is similar to the case where user navigate to Site Contents page and…