Wehave created a MS InfoPath form with it's corrsponding SharePoint Document Form Library, but would like torestrict the access to the SharePoint Document Form Library. After the user completes and submits the forms then he/she should not be able to go into the SharePoint Document Form Library and view the form. In order to allow users to fill out and submit an InfoPath form, Contributor level access is required to be granted. But Contributor level access allows them to view not only the form he/she has created but everyone else's which is not acceptable in this particluar situation. The solution we've come up with is to grant Contributor access to the SharePoint Document Form Library when the Submit button is pressed using stsadm grant the user Contibutor role. Then remove the access once the submission is completed.

We would be interested to know if there is a better process to accomplish this task. And, of equal importance, the coding that is required to execute this task.

Here are afew possibilities that may solve your problem:

• Create two document libraries, one for submission of new forms and the other for storage of the submitted forms. Next, create a custom workflow using the SharePoint Designer that moves the current document from the submission doc lib to the storage doc lib, then attach the workflow to the submission lib so that it runs when a new item is created. I'm pretty sure that the workflow will be able to move the document even if the user doesn't have Edit permissions on the storage doc lib.
• Write a document library event handler (see http://msdn2.microsoft.com/en-us/library/ms462433.aspxfor an example) that moves or set permissions onthe document when it is added to the form library.
• Write a custom web service method that handles the form submission. In the web service, you can perform an "elevation of privilege" (see http://msdn2.microsoft.com/en-us/library/aa543467.aspx) to runcode that saves the form to the correct location, evenwhen the current user doesn't have Add or Edit permissions. Steps 4-6 of the following example from the WSS 3.0SDK(http://msdn2.microsoft.com/en-us/library/ms454491.aspx) show some of the code you would use to create folders and write a file to a document library.

In our application, we use custom web service methods to handle form submissions rather than using the SharePoint submit adapter in InfoPath. This approach gives us more control over the handling of the submitted documents.

David,

This is a great tip. Thanks for sharing it with us. I have a question to add to this thread. When a task is created by custom workflow, we would expect only the person to who them task is assigned to to edit the task. When someone else tries to edit/approve the task, then the task should not let them to do it.

Ideally, if a task is created to a person then only that person should edit the task. If the task is assigned to a group then any one from that group should edit the task. In my workflows, I added all the task approvers as contributors of the site. that means they will be able to edit any list. And hence they will be able to edit the tasks created for someone else. How can we restrict the task editing capabilities to only the assigned person? Do we break the permissions for the task in the workflow code and then set the Edit permissions of the task to only the corresponding approvers? Should this done right after a task is created in the workflow code?

Or is there any setitng on the list that would allow only assigned users change the task?

In the advanced settings of the task list, Item level permissions are there. Iftheedit access set to all itemsthen every one can editany task.If the edit access is set to Only their items, then even though a person is assigned a task he will not be able to edit because he is not the one who created the task.

I appreciate any inputs. Thanks in advance

This is is also something that is effecting my company now....I would be very thankful for more information regarding this. Thank you.

Josh Rogers

Josh,

Shaun's tip helped me setup custom security for the tasks.

See the thread here:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1656688&SiteID=1

Hope htis helps.

Kiran

Kiran,

Which direction did you end up taking as far as allowing users to view only their submissions? I am having the problem with an expense report right now in that they can access the form and create a new expense report but everyone can see it and modify it. We don't want anyone to be able to view it except management and the author.

Thanks,

Josh

I end up using VSewss.exe and this code:

[SharePointPermission(SecurityAction.LinkDemand, ObjectModel = true)]
public override void ItemAdded(SPItemEventProperties properties)
{
base.ItemAdded(properties);

try
{
SPWeb web = new SPSite(properties.SiteId).OpenWeb(properties.RelativeWebUrl);
SPListItem item = web.Lists[properties.ListId].GetItemById(properties.ListItemId);

if (!item.HasUniqueRoleAssignments) { item.BreakRoleInheritance(true); }

//give the user read only permissions, we dont want to let him change his expense report after submission

SPRoleDefinition rd = item.Web.RoleDefinitions.GetByType(SPRoleType.Reader);
SPRoleAssignment ra = new SPRoleAssignment(item.Web.CurrentUser);
ra.RoleDefinitionBindings.Add(rd);
item.RoleAssignments.Add(ra);

// remove hisgroup access

SPGroup Group = web.Groups["GROUPWITHFULLACCESS"];
item.RoleAssignments.Remove(Group);
item.Update();
}
catch (Exception ex)
{
properties.Cancel = true;
properties.ErrorMessage = "Error : " + ex.Message;
}

}

' ---------------------------------------

Thank you all for your help.

Hi,

I need help with the same problem. I have forms that I need only the creator and a few others from the group to have view and modify access. I am not able to figure out how this can happen.

Please advice. (I'm not a fullfledged programmer....)

Thanks.

Josh,

Were you able to get a solution for your problem? I'm having the same problem and need help.

Appreciate your response.

Thanks.

The solution is to handle it as stated above. Grant contributor access to the Submission Library. Then restrict access to the Receiving Library.

I personally prefer using a VS 2005/2008 generated workflow to handle the transmission instead. The designer workflows are too buggy for my tastes.

The transmission workflow is quick and simple though.

Set it to fire 'When a new item is created'

Then with code, copy the item from the first library to the second, then delete the original.

End workflow.

Hi All,

I am very new to Infopath 2007 in sharepoint and was wondering how to incorporate the code which lets to grant perrmissions when the user hits the submit button.
I haven't been able to get much helponlin.

I would appreciate any help in this regard!

Thanks,
Naami

The solution is to handle it as stated above. Grant contributor access to the Submission Library. Then restrict access to the Receiving Library.

I personally prefer using a VS 2005/2008 generated workflow to handle the transmission instead. The designer workflows are too buggy for my tastes.

The transmission workflow is quick and simple though.

Set it to fire 'When a new item is created'

Then with code, copy the item from the first library to the second, then delete the original.

End workflow.

This will not work. When you kick off the workflow, it is being ran by the user who submitted it. In order for the workflow to move an item from one list to another, the user needs permissions to submit to both lists. Essentially, you are just moving from one list to another and the end user can access each the same. Problem not solved. However, you can create a custom action for a workflow that will use the system account to do the moving, this way the user doesn't need submission rights to the final list. The problem with this is you can have anyone submit items to a list they have no permissions for.

I still can't believe Microsoft hasn't come up with a permissions setting that allows user to submit to a forms library but also allow them to have a limited view of only their items. You can do this now, but the user has the ability to change views and ultimately see everyones submissions so what is the point of setting the default to show only their items. Who would have thought I would want user to submit forms and not see others? What a joke MS....

Hi All,

I am very new to Infopath 2007 in sharepoint and was wondering how to incorporate the code which lets to grant perrmissions when the user hits the submit button.
I haven't been able to get much helponlin.

I would appreciate any help in this regard!

Thanks,
Naami

Changing permissions within the submission code is not a good idea.

The transfer solution is actually pretty common and quoted all over the place. One thing to get used to in Sharepoint is the concept of Elevation of Privilege and Impersonation. You will run into countless scenarios where you will need to temporarily upgrade a users permission to let them do just that ONE thing that is holding your project back. Rather than writing a custom security policy every time you need to achieve this, its a lot easier to use a quick Visual Studio workflow to get the job done.

To transfer from one list to another, open a new workflow in Sharepoint. Add a single 'Code activity action' to the designer. then go to your codebehind and add this code.

 private void codeActivity1_ExecuteCode(object sender, EventArgs e)
        {
            String myName = "myServiceAccount";
            String myPass = "myPassword"; //not the most secure way of doing it, obviously
                                  
            WindowsImpersonationContext wic = NewClass.CreateIdentity(myName, "nmed", myPass).Impersonate();    
            SPWeb web = workflowProperties.Web;
            SPList SendingList = workflowProperties.List;
            SPList ReceivingList = web.Lists["ReceivingList"];
            SPListItemCollection ReceivingListItems = ReceivingList.Items;
            SPListItem currentItem = workflowProperties.Item;
            web.AllowUnsafeUpdates = true; //This is always important
            try
            {
                SPFile myFile = currentItem.File;
                myFile.CopyTo(("http://myservername/ReceivingList/" + myFile.Title), false);
                
            }
            catch (Exception ex)
            {
                String whathappened = ex.Message;
                
            }       
            
            foreach (SPListItem item in ReceivingListItems)
            {
                if (item.Title == currentItem.Title)
                {
                    IsPresent = true;
                    item["Template Link"] = "http://myServerName/ReceivingList/forms/template.xsn"; //Specifically for my forms library to make sure its linked to the current template.
                    item.Update();
                    break;
                }
                else
                {
                    IsPresent = false;
                }
            }
            if (IsPresent == true)
            {
                try
                {
                    currentItem.Delete();
                }
                catch (Exception ex)
                {
                   
                }
            }
            web.AllowUnsafeUpdates = false;
            wic.Undo();
        }

http://msdn.microsoft.com/en-us/library/aa830816.aspx- Introduction to Workflows
http://msdn.microsoft.com/en-us/library/aa543467.aspx- Introduction to the concept of Elevation of Privilege
http://msdn.microsoft.com/en-us/library/system.security.principal.windowsimpersonationcontext.aspx- Windows Impersonation (Elevation is much easier in C# IMO, than WIC)

There's more than one reason for doing it this way.
1. You can glance at a library and immediately tell what kind of permissions you granted it. Sending allows everyone to add, receiving is locked down tighter than my wife's purse.
2. No guess work. It transfers immediately, no timing wait, things are kept nice and clean.

Cons -Two submissions atEXACTLY the same time can potentially lock your workflow and leave an item in the 'sending' library. My current thought is because I tend to titleanon submissions with a name & DateTime stamp. I only go down to seconds on the date time, soif two users hit submit in the same second, it locks.

Hi vmaruv,

If u want that only the creator should be able to see the forms then you can filter the view by setting the "Created by" field equal to [Me]. In this way, people who created the documents can only see their created documents. If you want that with the creator some other user group should be able to see them then you can see my blog. You will get some help. See Post "Showing items to a partocular user group or user in a view"

http://sharepointissues.blogspot.com/

Regards
Ginni

If they use explorer view, they can see eveyones submission. This is a really crazy problem. It has held up adoption of this sharepoint in many places. emailing to a document library seems to oversome this issue, but is not elegant for many reasons

Somehow I came across this old post..

If views are an issue you can restrict explorer view or any view by using http://spviewpermission.codeplex.com/ by Laurent Cotton. Also, I have worked with financial institutions, pharmaceutical companies etc where there isnt an issue (and there would be if we allowed information to be disseminated to everyone. We usse event receivers to kick off and control the OOB WF, email messages, task creation, document moves and rename all the way through to inserting the data once approved into their accounting system of choice or you can just create your own WF depends on the complexity also a larger dependency using an expense report as the example is having all of the information in AD so you can route the emails and assign tasks to the correct people and allow submitted on behalf of...

 

-Ivan

I find the easiest solution to this problem is to use a SharePoint Designer workflow to set the permissions on the form. I use the excellent SPDActivities (http://spdactivities.codeplex.com/) add-on to give the ability to set permissions from within a SharePoint Designer workflow.

The process is as follows.

-Install SPDActivites

-Create an SPD workflow for the form library to run when an item is created (or each time it's modified depending on your use case)

-Add actions to add/remove permission assignments as needed.

This avoids the complication of the two library method. It's much easier than a custom coded event reciever or Visual Studio workflow. It's very quick and easy to implement, installing SPDActivities the first time takes at most an hour or so. After that you can have a permissions workflow up and running in minutes. And if you need a different setup on a different library, that's just minutes again.

Some tips:

-I find it easiest to put all relevant users in a sharepoint group and give that group contribute permission on your form library, any of those users can then create a new form.

-In the workflow you can then delete the permission assignment for that group for that form, then add in the specific users who should have access (creator etc)

-You can give permissions to a SharePoint group as well, so you can have a group for say Approvers and give them access in the workflow.

-If you form has fields where the user needs to select other users (such as an approver or manager) promote those field to SharePoint fields and they become available in your workflow too so it can give those users permissions too.

-If you are giving permissions to SharePoint groups, make sure the group is set so that everyone can view it's membership, not just it's members, or you might get an error if a non-member tries to give it permissions

This works extremely well for me and I've used it with much success on relatively large/busy browser-form applications.

The only time to date it has sufficed and I have had to resort to custom code was a form with a people picker control in a repeating section to pick a large number of collaborators, the workflow can only see the first value in a repeating table/section.

Hi Ginni,

I Really Appreciate your simplest and most acurate solution to the asked question.

Grate support keep it up,

Ragards,

Waheed Sami.