Here’s the requirement. I have a forms library to which all users must be able to submit forms. Once the incident report is submitted, users should only be able to see their own forms.
There are 7 classifications of “incidents”. These incident codes and the primary person responsible for handling them are in a separate SharePoint list.
Additional requirements: the forms cannot be moved to another forms library.
Here’s what I’ve tried so far.
On the actual form library page, I have the My Documents view set as the default view. I’ve disabled the save this view and view selector menu in the Miscellaneous section of the Edit Web Part section.
I added a second web part of the library to the page and set target audience to the VP & Facilities manager who need access all forms… this web part has the All docs view.
However, I began to wonder if it would be better to create a Web part page to show these views. So on the first page add 4 web parts. the first web part is the form library with My Documents view using the current user filter (2nd web part) to display forms only to the logged in user. I then added a 3rd web part (the All Documents view of the forms library) and connected it to a SharePoint List Filter web part. This filter uses the external list containing the Incidents codes and the person responsible for each code. The filter user the Incident code field from the list (the user can select it right now), and the library is then filtered to only show forms of that Incident Code.
What I’m wondering is how to set the audience on the 3rd/4th web part? If the incident code is Employee Accident for instance, only the worker’s comp rep from HR and the VP for Admin Services should see these forms. I can create SharePoint groups for each incident code which could be used for Audience targeting.
Would it be better to create a separate web part page for each group? or is there a way to conditionally target the result based on the Incident Code selected? (it would need to be OOTB or maybe using JS link as I am not a developer and don’t have access to one).
Any thoughts/assistance would be greatly appreciated.
?width=750
Not sure if you had this resolved but here are some thoughts .
If your filter field for handler is a multi-person field it should still only render the items where that persons name is listed. I know it more difficult to do that with groups but you are on the right path. You could add the group to the item, and then have the filter show based on the group (membership ). That way you don’t need multiple Web parts and technically one person could see items from two groups if they were listed in both.
As to your original question, you could have simply connected two Web parts together where one would show results based on the filter of the previous one.
Also you should have been able to achieve the viewing without using audiences but metadata. Have you considered using the Department on the user profile?
thanks for that information, Dave. Since I have the library set to NOT be indexed anyway, I don’t think that would be an issue in this instance.
It’s worth noting that draft Item security will prevent items from being indexed by search… Obviously that won’t matter in certain contexts, but it is the biggest limitation of this type of workaround (IMO).
A work-around that I have used for this kind of requirement in document libraries (not on a form library) is, in the Versioning Settings, to set Approval Required and under Draft Item Security allow Approvers and the user who created the item to approve drafts.
You set unique permissions to give everyone Contribute permissions, and elevated permissions for “Approvers” who should be able to see everything, then don’t approve the documents.
You will need to change the view to remove the Approval Status column so as not to raise concerns for your users.
It’s not the most elegant solution but it does the job.
I could be wrong, but I think you can toggle off folder creation and will not remove the folders you have already created. I meant manual creation. So, you would use the GUI to put the folder structure in place and then disable folder creation.
Ah, good. Search is always an issue when opting to hide instead of secure. 🙂
Users will still be able to get to the underlying list. The only way to ensure security is to permission everything. What you’re doing is the right approach if hiding is ok versus securing. One thing that always came up when I took this approach was the OOTB redirects when you submit a form. If you’re using a web part page and avoiding sending users to the list, you need to make sure forms pop-up. When they close, it just refreshes page. If you don’t pop-up, the OOTB behavior upon form submit is to return to the list.
