One of the scenarios is updating and approving list items.through REST service.

While i will not go in details on using the REST services (there are multiple samples already available on net)  you can see that we can easily update list items through REST. For Approving items we set the OData__ModerationStatus to 0.

This works fine in most cases but in case of SharePoint 2013 workflow you will find that approving items fails though updating list items goes through fine.

The SharePoint 2013 workflows are really like provider hosted apps and have a default set of permissions which does not include approve items permission.

 Perform the below steps to fix this

 
Go to "Site Settings" "Site App Permissions"

Find the App Workflow as copy the first guid as shown below

Go to http://<site collection Url>/_layouts/15/appInv.aspx.

Enter the Guid copied in previous step in the App ID and click on Lookup.

This will populate the Title, App Domain and Redirect URL columns.

Copy the below in Permission Request XML (copy as is and do not change the url in the Scope)

<AppPermissionRequests>

    <AppPermissionRequest
Scope="http://sharepoint/content/sitecollection/web"
Right="FullControl" />

  </AppPermissionRequests>

Click on Create and Trust the Workflow App

Test the workflow again and it should start working.

Note the list item needs to be in Pending state else the Approval with not work even with these steps.

Following is the sample code that calls the FindFiltered method.

            string readListInstanceName = ConfigurationManager.AppSettings["method"];
            Microsoft.BusinessData.MetadataModel.Entity entity = clientContext.Web.GetEntity(ConfigurationManager.AppSettings["namespace"], ConfigurationManager.AppSettings["name"]);
            Microsoft.BusinessData.MetadataModel.LobSystem lobSystem = entity.GetLobSystem();
            Microsoft.BusinessData.MetadataModel.Collections.LobSystemInstanceCollection lobSystemInstanceCollection = lobSystem.GetLobSystemInstances();
            clientContext.Load(lobSystemInstanceCollection);
            clientContext.Load(entity);
            clientContext.ExecuteQuery();

            Microsoft.BusinessData.MetadataModel.LobSystemInstance lobSystemInstance = lobSystemInstanceCollection[0];

            Microsoft.BusinessData.MetadataModel.Collections.FilterCollection externalFiltersOnFieldCollection = entity.GetFilters(readListInstanceName);
            List<string> searchFilters = new List<string>();
            clientContext.Load(externalFiltersOnFieldCollection);
            clientContext.ExecuteQuery();
            foreach (Microsoft.BusinessData.MetadataModel.Filter filter in externalFiltersOnFieldCollection)
            {
                if (filter.FilterField.Equals(ConfigurationManager.AppSettings["filter"]))
                {
                    searchFilters.Add(filter.Name);
                }
            }
            foreach (string filterName in searchFilters)
            {
                externalFiltersOnFieldCollection.SetFilterValue(filterName, 0, ConfigurationManager.AppSettings["filtervalue"]);
            }
            Microsoft.BusinessData.MetadataModel.Collections.EntityInstanceCollection result = entity.FindFiltered(externalFiltersOnFieldCollection, readListInstanceName, lobSystemInstance);
            clientContext.Load(result);
            clientContext.ExecuteQuery();
            return result;

Calling clientContext.ExecuteQuery(); was throwing an error - "An exception of type 'Microsoft.SharePoint.Client.ServerException' occurred in Microsoft.SharePoint.Client.Runtime.dll but was not handled in user code System.ArgumentNullException: Value cannot be null.  Parameter
name: unescapedStr   "

The resolution of this issue was pretty straight forward but not very obvious.

This exception is thrown when a BCS Model Does not contain the ReadItem aka SpecificFinder method.

Now the question arises why does calling the BCS Read List method require the ReadItem method.

If we look at the stack trace in ULS log we see the following

Exception occured in scope Microsoft.SharePoint.BusinessData.MetadataModel.Collections.AbstractEntityInstanceCollection._SerializeToJson.
Exception=System.ArgumentNullException: Value cannot be null.  Parameter
name: unescapedStr   

 at Microsoft.BusinessData.Infrastructure.Util.Escape(Char
valueToEscape, String unescapedStr)    at
Microsoft.SharePoint.BusinessData.BCSObjectFactory.GetEntityInstanceCanonicalId(IEntityInstance
entityInstance)    at
Microsoft.BusinessData.ServerStub.Runtime.AbstractEntityInstanceServerStub.GetObjectIdentity(Object
target)    at
Microsoft.SharePoint.Client.ServerStub.WriteAsJson(JsonWriter writer, Object
obj, ClientObjectQuery objectQuery, ProxyContext
proxyContext)    at
Microsoft.SharePoint.Client.ServerStub.WriteChildItems(JsonWriter writer,
Object obj, ClientObjectQuery objectQuery, ProxyContext
proxyContext)    at
Microsoft.SharePoint.Client.ServerStub.WriteAsJson(JsonWriter writer, Object
obj, ClientObjectQuery objectQuery, ProxyContext
proxyContext)    at
Microsoft.SharePoint.Client.ServerStub.WriteAsJsonWithMonitoredScope(JsonWriter
writer, Object value, ClientObjectQuery objectQuery, ProxyContext proxyCon

The exception is actually thrown at Microsoft.BusinessData.Infrastructure.Util.Escape but the real error happens at Microsoft.SharePoint.BusinessData.BCSObjectFactory.GetEntityInstanceCanonicalId

It seems like the API internally uses the name of the ReadItem method to generate an identifier used internally (i didn't go into further details on where this is used ).

If the ReadItem method does not exist null is passed to the Microsoft.BusinessData.Infrastructure.Util.Escape method which does some kind of encoding of strings and the above exception is thrown.

Though i cannot really visualize a scenario where we don't need the ReadItem method I tried to find any documentation where it is mentioned that ReadItem is required in BCS Model.

I couldn't find any specific documentation but can see that all samples always include the ReadItem method.

Also if you make the External Content Type in SharePoint Designer you should be able to see a warning message if you don't have the ReadItem method.

 

I will conclude that it is safe to say that ReadItem is a required method in the External Content Type.

Hopefully this post will save someone the pain of further troubleshooting when they come across this issue.

Recently I did a small Proof Of Concept Application that called the Office 365 APIs to access data from a SharePoint site collection and performed some other operations that require higher rights like Creating lists.This was done to verify the way the user permissions in SharePoint and the permissions provided to the application in windows azure impact what data the application can access.

Though this App was done with a windows application in .Net this should be applicable to all the other platforms that use the corresponding O365 API as they call the same underlying infrastructure in Office 365.

The App did the following operations in a SharePoint site.

• View List Items
• Create List Items
• Create Lists

The App was tested with following set of permissions

• Full Control
• View /Add . Edit list Items
• View List Items

In addition the App was tested with following types of users

• Global Administrator (Azure)
• Site collection Admin \ Full Control
• Members \ Contribute permissions
• Visitors \ Read permission

Based on my tests I could come up with the below matrix for permissions. Please note there is currently no official documentation around this and the results are based on testing at my side.

These results should remain the same across the various platform on which the the APIs are called as the underlying infrastructure is same.

Also the scope of the Client Application is limited to retrieving the appropriate tokens and the permissions for an app will depend upon the permissions provided to the App in Azure + the right that the logged in user has

 One more point I need to mention is that I found some time lag before I could do some operation with a new user once the user is created.
  

The API was tested for SharePoint only and the below matrix is applicable for SharePoint only.

Following is the matrix

1. App has full controls

Following are the app permissions set in Azure for App

Below are the permission that the application will actually have based on the currently logged in user's rights.

2. App has read and write permissions on lists but not create lists

Following are the app permissions set in Azure for the App

Below are the permission that the application will actually have based on the currently logged in user's rights.

3. App has only read permissions on lists

Following are the permissions set in Azure for the App

Below are the permission that the application will actually have based on the currently logged in user's rights.

I recently had a customer who was having issues with the AlterToDo. Customer was calling the AlterToDo method of the workflow.asmx as per the documentation available but the task was not getting reassigned.

On researching further we could see that there is no accurate documentation on the internet for using the AlterToDo method to reassign tasks.

Following is the code sample which calls the AlterToDo method.

               string strURL = "http://sp/documents/doc1.docx";

            // task item id
            int intToDo = 1;

            // Task list id
            Guid GUIDToDoListID = new Guid("{f46aa19e-ea35-4357-80f4-882306a2ebdc}");

             WorkflowService.Workflow client = new WorkflowService.Workflow();

            client.Credentials = CredentialCache.DefaultCredentials;
       

            string strData = "" ; /*Some xml comes here */

            XmlDocument XMLTaskData = new XmlDocument();

            XMLTaskData.LoadXml(strData);

            var data3 = client.AlterToDo(strURL, intToDo, GUIDToDoListID, XMLTaskData);

By accurate documentation I am referring to the xml sent to AlterToDo method.

Following is the correct xml to reassign a task.

var strData = @"<my:myFields xmlns:my='http://schemas.microsoft.com/office/infopath/2003/myXSD'>
                        <my:TaskStatus>ReassignTask</my:TaskStatus>
                        <my:Comments></my:Comments>
                        <my:FieldName_DelegateTo>
                            <pc:Person xmlns:pc=""http://schemas.microsoft.com/office/infopath/2007/PartnerControls"">
                            <pc:DisplayName>User 2</pc:DisplayName>
                            <pc:AccountId>contoso\user2</pc:AccountId>
                           <pc:AccountType>User</pc:AccountType></pc:Person>
                        </my:FieldName_DelegateTo>
                        </my:myFields>";

I haven't seen this method being used very widely. But when it is being used it can be a bummer to get this working without the correct xml to reassign tasks.

Thanks to my Escalation Engineer Andy Li for helping in figuring this out.

We have a complex sharepoint solution on BPOS. A critical issue was found in the prodution version. On dev side we already have progressed to the next version, currently wating for it to be deployed on production.

Also our test environments contained the latest version. To test the issue we need to revert back to the older version. Considering the complexity of the solution this meant hours of rollback effort which we could not afford considering the criticality of the issue. Luckily we had Hyper-V snapshots to our rescue. The effort of many hours got tranformed into a 10 min task by restoring the snapshots.

I have seen many other instances of Hyper-V like speeding up builds and automated daily deployments (deployments which are meant for testing deployment scripts and need to be run on clean slate every time)

I really consider Hyper-V to be a must have for Sharepoint environments atleast Dev and QA.

http://blah.winsmarts.com/2009-3-Using_Site_Lookup_columns,_across_sites.aspx

This one shows how we can use a lookup field across the sites. Though this will work only for top down hierarchy i.e. you can have a look up column in child site that looks up a list in the parent. Not the other way.

If you want to have it the other way i believe custom field type will be the way to go.

Microsoft recommendation is not to modify these as the modifications can get overwritten in the next service pack or a patch. So what do you do when you want to modify the functionality of a Sharepoint Application Page. For example we had a scenario where we wanted to prevent users from entering 'NT Authority\All Authenticated Users' in the "People and Groups". This is the "aclinv.aspx" application page.

One of the solution is to make the copy of a page and then modify it. It looks good at first but with a bit more of investigation one will realize that it has potential for more bugs because it means rewriting functionality that has already existed and is certainly well tested. The other solution i am going to present here will demonstrate the power and flexibility of the asp.net framework.  This solution involves creating a HTTPModule which will modify the control tree of the page to achieve the required functionality.

Lets look at the scenario i mentioned above where i want to add custom validation to prevent giving permissions to 'NT Authority\All Authenticated Users'. The following summarizes the steps needed to be performed to achieve this

1. Create a custom HTTPModule and bind it to the desired sharepoint web application.
2. In the custom http module check if the page is "aclinv.aspx". Catch the init event of the page.
3. In the init event of the page add a custom validator.
4. Perform the validation in the ServerValidate event of the custom validator.

Let me demonstrate with more details

Create a new class and inherit it from the IHTTPModule class. Override the init and dispose method. Catch the PreRequestHandlerExecute event of the HttpApplication class.  This event is triggered just before the page execution starts.

        public void Init(HttpApplication context)
        {
            context.PreRequestHandlerExecute += new EventHandler(context_PreRequestHandlerExecute);
        }
In the PreRequestHandlerExecute event attach to the Init event of the Page class as shown below

 void context_PreRequestHandlerExecute(object sender, EventArgs e)
        {

            HttpApplication httpApp = sender as HttpApplication;



            if (httpApp != null)
            {

                page = httpApp.Context.CurrentHandler as Page;



                if (page != null)
                {
                    if (HttpContext.Current.Request.Url.AbsoluteUri.Contains("_layouts/aclinv.aspx"))
                    {
                        page.Init += new EventHandler(page_Init);
                    }
                }

            }

        }

Looks simple enough. Now we just need to add a custom validator control to the page. I want the custom validator control to be displayed just below the "Add Users" field. To figure out the location i opened the "aclinv.aspx" page in the Layouts folder. You can see that the Add Users field is a PeopleEditor control

<asp:Content ContentPlaceHolderId="PlaceHolderMain" runat="server">
<TABLE border="0" cellspacing="0" cellpadding="0" class="ms-propertysheet">
    <wssuc:InputFormSection Title="<%$Resources:wss,aclinv_Step1Title%>"
        Description="<%$Resources:wss,aclinv_DescGrantIndiv%>"
        runat="server">
        <Template_Description>
            <SharePoint:EncodedLiteral runat="server" text="<%$Resources:wss,aclinv_DescGrantIndiv%>" EncodeMethod='HtmlEncode'/>
            <br>
            <br>
            <asp:LinkButton id="LinkAddAuthUsers" Text="<%$Resources:wss,permsetup_addauthtitle%>" runat="server"
                       CausesValidation="false" OnClick="LinkAddAuthUsers_Click" />
        </Template_Description>
        <Template_InputFormControls>
            <wssuc:InputFormControl LabelText="<%$Resources:wss,aclinv_UserGroupsLabel%>" runat="server">
                <Template_Control>
                    <wssawc:PeopleEditor
                                AllowEmpty=false
                                ValidatorEnabled="true"
                                id="userPicker"
                                runat="server"
                                ShowCreateButtonInActiveDirectoryAccountCreationMode=true
                                SelectionSet="User,SecGroup,SPGroup"
                                />
                </Template_Control>
            </wssuc:InputFormControl>
        </Template_InputFormControls>
    </wssuc:InputFormSection>

This is nested in a deep hierarchy of controls and we need to play around to figure out the exact location where we can add the controls. I temporarily added the following bit of code to the httpModule to display the entire control hierarchy of the page.

private string GetControlCollection(Control ctrl, string indent)
        {
            string str = string.Empty;

            foreach (Control child in ctrl.Controls)
            {
                str += "<br>" + indent + child.GetType().Name + " -- " + child.ID;

                if (child.Controls.Count > 0)
                {
                    str += GetControlCollection(child, indent + "&nbsp;&nbsp;&nbsp;");
                }
            }

            return str;
        }

I called this function in the page_Init event in the custom HttpModule.

string hierarchy = GetControlCollection(page);
Literal literal = new Literal(){ Text= hierarchy};
page.Controls.Add(literal);

This displayed the entire control hierarchy of the page. Looking at it we can figure out the location of the "Add Users " control which can be accessed using the following code -

Control ctrl = page.Form.FindControl("PlaceHolderMain").Controls[1].FindControl("PlaceHolderControls").Controls[1].FindControl("PlaceHolderControl").FindControl("userPicker");

Thats it we are almost done. Just need to add the custom validator and handle the ServerValidate event of it.

The code will look something like this.

In the page_Init

                Control ctrl = page.Form.FindControl("PlaceHolderMain").Controls[1].FindControl("PlaceHolderControls").Controls[1]. FindControl("PlaceHolderControl").FindControl("userPicker"); //get reference to the "Add User"s control
                CustomValidator cust1 = new CustomValidator();
                cust1.ServerValidate += new ServerValidateEventHandler(cust1_ServerValidate); // Handle the event to perform validation
                cust1.ControlToValidate = "userPicker";
                cust1.Text = "'NT Authority\\All Authenticated Users' is disabled and cannot be added to any group. Please contact your system administrator"; //set the error message to be displayed if the validation fails
                ctrl.Parent.Controls.AddAt(ctrl.Parent.Controls.IndexOf(ctrl) + 1, cust1); //add the custom validator just after the Add Users control

In the cust1_ServerValidate

      
            string[] arr = args.Value.Split(',');
            foreach (string str in arr)
            {
                if (string.Compare(str, "nt authority\\authenticated users", StringComparison.InvariantCultureIgnoreCase) == 0) //user entered "NT Authority\Authenticated Users" as one of the options
                {
                    args.IsValid = false; //fail the validation
                    return;
                }
            }

The following is the complete code for the HttpModule

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Web;
using System.Web.UI;
using System.Web.UI.WebControls;
using Microsoft.SharePoint.WebControls;

namespace poc_httpmodule
{
    public class ValidatorModule : IHttpModule
    {
        Page page;

        public void Init(HttpApplication context)
        {

            context.PreRequestHandlerExecute += new EventHandler(context_PreRequestHandlerExecute);

        }

        void context_PreRequestHandlerExecute(object sender, EventArgs e)
        {

            HttpApplication httpApp = sender as HttpApplication;



            if (httpApp != null)
            {

                page = httpApp.Context.CurrentHandler as Page;



                if (page != null)
                {
                    if (HttpContext.Current.Request.Url.AbsoluteUri.Contains("_layouts/aclinv.aspx"))
                    {
                        page.Init += new EventHandler(page_Init);
                    }
                }

            }

        }

        void page_Init(object sender, EventArgs e)
        {
            if (page != null)
            {

                Control ctrl = page.Form.FindControl("PlaceHolderMain").Controls[1].FindControl("PlaceHolderControls"). Controls[1]. FindControl("PlaceHolderControl").FindControl("userPicker"); //get reference to the "Add User"s control
                CustomValidator cust1 = new CustomValidator();
                cust1.ServerValidate += new ServerValidateEventHandler(cust1_ServerValidate); // Handle the event to perform validation
                cust1.ControlToValidate = "userPicker";
                cust1.Text = "'NT Authority\\All Authenticated Users' is disabled and cannot be added to any group. Please contact your system administrator"; //set the error message to be displayed if the validation fails
                ctrl.Parent.Controls.AddAt(ctrl.Parent.Controls.IndexOf(ctrl) + 1, cust1); //add the custom validator just after the Add Users control
            }
        }

        void cust1_ServerValidate(object source, ServerValidateEventArgs args)
        {
            string[] arr = args.Value.Split(',');
            foreach (string str in arr)
            {
                if (string.Compare(str, "nt authority\\authenticated users", StringComparison.InvariantCultureIgnoreCase) == 0) //user entered "NT Authority\Authenticated Users" as one of the options
                {
                    args.IsValid = false; //fail the validation
                    return;
                }
            }
        }

        public void Dispose()
        {

        }

      
    }
}

Last step is to plug in our HttpModule. Add a strong name to the project and add the dll to the gac. Add the following in the <httpModules> tag.  Replace the "Public Key Token" to the appropriate value

<add name="ValidatorModule" type="poc_httpmodule.ValidatorModule, poc_httpmodule, Version=1.0.0.0, Culture=neutral, PublicKeyToken=7f1d0bb0d60d5701" />

Now browse to the intended sharepoint site and try to add "NT Authority\Authenticated Users".  You should see the following message

Seems amazing doesn't it. One really cannot help thinking of the amazing things that can be achieved using the power of asp.net. If you thought sharepoint puts too many restrictions compared to asp.net think again :-).

Happy Programming
Sohail

The code is part of a webpart that just displayed all the users in the owners group of the current site.  This code runs fine with users having Full control or Contribute access. But fails for users having only Read access. 

Label  labelUsers;  

protected override void CreateChildControls() {

 labelUsers = new Label();   

this.Controls.Add(labelUsers);  

SPSecurity.RunWithElevatedPrivileges(delegate() {

   SPSite site = SPContext.Current.Site;   

   SPWeb web = SPContext.Current.Web;  

   SPGroup group = web.Groups.GetByID(3);//get the owners group

   if (group != null) {

            StringBuilder users = new StringBuilder();  

             for (int cnt = 0; cnt < group.Users.Count; cnt++) {   

                   users.AppendFormat("{0},", group.Users[cnt]);

              }

                      labelUsers.Text = users.ToString();//display it on the label 

              }//End of "If" block 

        });//Close "SPSecurity.RunWithElevatedPrivileges" block

 }

  This code throws an exception for Read users at the line "for (int cnt = 0; cnt < group.Users.Count; cnt++)". This line fails when the Users collection withing the SPGroup it being accessed.

Looks like the SPSecurity class is not behaving correctly here but lt is working perfectly in the way it is supposed to.Though the entire code is enclosed within SPSecurity.RunWithElevatedPrivileges not all code is able to run with the elevated privileges. So the rule is --  The code will not run within elevated privilege if the object accessed was not created within the SPSecurity.RunWithElevatedPrivileges block. If we take a relook at the code we can see that the instances of SPSite (i.e. site object ) and SPWeb (i.e. web object) are retrieved through the current SPContext. The SPContext is created much before our elevated privilege code runs. Accessing the child objects of the SPWeb instance in form of "web.Groups.GetByID(3)" returns a SPGroup object which will also fail to run within the elevated privilege. And once we (with only read access) try to access the Users collection within the SPGroup object Sharepoint rings the bell indicating the information is classified. It throws you out of execution by rasing an exception.

    Now that we know the reason for the error, the problem doesn't look too tough and in reality the solution is simple. To run this code successully we need to create the SPSite and SPWeb instances within the SPSecurity.RunWithElevatedPrivileges. So we have the new code below (the changes are highlighted)

 Label labelUsers;

 protected override void CreateChildControls(){

    labelUsers =  new Label();

    this.Controls.Add(labelUsers);

    SPSecurity.RunWithElevatedPrivileges(delegate(){  

        SPSite site = SPContext.Current.Site;   

        SPWeb web = SPContext.Current.Web;  

         using (SPSite newSite = new SPSite(site.ID)) {  

            using (SPWeb newWeb = newSite.OpenWeb(web.ID)){ //Do not use the site object to create the SPWeb instance else the code will still fail     

                SPGroup group = newWeb.Groups.GetByID(3);  //get the owners group      

                if (group != null) {   

                    StringBuilder users = new StringBuilder();                    

                    for (int cnt = 0; cnt < group.Users.Count; cnt++) {  

                            users.AppendFormat("{0},", group.Users[cnt]);

                    }

                    labelUsers.Text = users.ToString();

              }// End of "If" block

          }// End of using for SPWeb

       }// End of Using for SPSite

   });//End of SPSecurity.RunWithElevatedPrivileges 

}

 This code now works beautifully.

With some more space to write let me jot down the lessons learned  (little bits of wisdom we cannot afford to ignore ;-) )

Lesson 1 -  Just putting your code within SPSecurity.RunWithElevatedPrivileges does not guarantee your code to run successfully irrespective of the access of the user logged in. You may want to look at the code carefully when writing it and look back at it again once you have written thinking that it will work fine no matter what.

Lesson 2 - No matter how confident you are with your code, its always better in sharepoint to unit test your code with all three types of user access (i.e. Owner/Full control access, Members/Contribute access and Read/Visitor access). I have made it a point to write my unit tests with all the three types user access in consideration and hopefully will be able to avoid similar mistakes in future.

Lesson 3 - And the final one. As one of my friend says "the world is round". So things we ignore (or maybe just use some workarounds no matter how elegant) do come back to us :-). In software it always pays to get to the root of the problem even if there is a workaround to the problem.