How to a sharepoint form library be set up to allow users to submit forms, but not see other people’s forms

formsinfopathsharepoint

This use case seems like it would apply to just about every form, but I have yet to find a good out-of-the-box solution for it. Imagine an HR Complaint form based on InfoPath and SharePoint. All Employees should be able to fill them out and submit them, and possibly see the ones they've submitted, but only members of HR should be able to view others' forms. How can I configure the form and/or the form library to accomodate this? Some things I've tried:
[[NFL-LIVE]]#Philadelphia Eagles vs Jacksonville Jaguars: 2018 Live Stream (NFL-FOOTBALL) ON TV CHANNEL
– Creating a Form Library View filtered where CreatedBy=[Me]. Security cannot be set on views, so users can still see all submitted forms if they choose a different view.
– Adjusting security on the library. It is not possible (AFAIK) to give a user 'submit' rights without also giving them 'view' rights.
– Creating a custom workflow. This might work, but we would prefer an out-of-the-box solution or 3rd party feature to enable this scenario, without requiring code for each form. We want non-developer end-users to be able to create InfoPath forms with this behavior.

Best Answer

I've done this with Holiday Requests forms (and we now use it for all forms that we create). Only HR, the user's manager or the 'creator' of the form can open a full view. I'm not a Sharepoint or Infopath expert so my solution may not fit all scenarios.

background - InfoPath 2010 Form filler (not browser forms), with SharePoint wss3.0 (though I don't see why it wouldn't work on later versions).

I designed an Infopath form, with several views, opened on form load dependant on who the user is, and what the status is. One of the views is a 'sorry, you can't open this form' view.

When the form is created I move the userid (a built-in function on the form - userName()) to a field 'created by'. When the form is opened a rule checks that field against the current user field and can take action to show the appropriate view (depending on other field values). I also move their manager's userid to another field - this is also retrieved from a data connection to another list

Then I have a SharePoint List (called permissions) - this list contains userids and what their permission is (senior manager, HR etc) and I read this using a data connection, and filter it on the userid (retrieved when the form is opened).

So, in summary - when the form opens,the Form Load rule: 1) retrieves current userid 2) retrieves that user's permissions from my list 3) checks the Form status

and then shows the appropriate view of the form (update, read-only, private etc)

I created a new permission type which is a copy of 'contribute' settings, but without the delete permission. So by default everyone can in theory add, read and update all forms, but my rules prevent certain actions.

Someone with more knowledge of SharePoint & InfoPath than me might be able to find fault with it, and it might not be 100% secure in the true sense, but it works for us. I also remove the 'Open in Windows Explorer' options from the tool bar so they can't see the raw xml data.

I hope this helps

Related Solutions

R – Submit issues – send to 2 locations at once

You can add an additional DataSource for submission (send to SharePoint library) and add a rule to your submit button before the save&close rules.

BUT - I would suggest a method that is based on workflows and a form that is held on a SharePoint site. I had a very similar task, where approvals were needed in a staged manner.

If there is a fixed number of approvers, create fields for each one - if the number is not fixed you will need some replacing rules that change the current approver with the next one. Then you will need one (or more) workflows that are triggered by a flag field (or more) that you promoted before. (Make them writable from the outside during publication - the workflow will need that) This field (or fields) trigger the workflow that sends the email. After sending it should clear that flag to avoid infinite looping.

The mail should contain a link to the SharePoint library. And the approver should work on that library rather than sending the XML file through the network.

Hint: Enable versioning on that libary - and you (or the approvers) can keep track of the changes.

Hint 2: If this process will be part of the daily work, maybe a custom view and alerts will help the approvers keep track of the form's status.

Html – How to overcome the HTML form nesting limitation

I know this is an old question, but HTML5 offers a couple new options.

The first is to separate the form from the toolbar in the markup, add another form for the delete action, and associate the buttons in the toolbar with their respective forms using the form attribute.

<form id="saveForm" action="/post/dispatch/save" method="post">
    <input type="text" name="foo" /> <!-- several of those here -->  
</form>
<form id="deleteForm" action="/post/dispatch/delete" method="post">
    <input type="hidden" value="some_id" />
</form>
<div id="toolbar">
    <input type="submit" name="save" value="Save" form="saveForm" />
    <input type="submit" name="delete" value="Delete" form="deleteForm" />
    <a href="/home/index">Cancel</a>
</div>

This option is quite flexible, but the original post also mentioned that it may be necessary to perform different actions with a single form. HTML5 comes to the rescue, again. You can use the formaction attribute on submit buttons, so different buttons in the same form can submit to different URLs. This example just adds a clone method to the toolbar outside the form, but it would work the same nested in the form.

<div id="toolbar">
    <input type="submit" name="clone" value="Clone" form="saveForm"
           formaction="/post/dispatch/clone" />
</div>

http://www.whatwg.org/specs/web-apps/current-work/#attributes-for-form-submission

The advantage of these new features is that they do all this declaratively without JavaScript. The disadvantage is that they are not supported on older browsers, so you'd have to do some polyfilling for older browsers.

Best Answer

Related Solutions

R – Submit issues – send to 2 locations at once

Html – How to overcome the HTML form nesting limitation

Related Topic