Specific Access to Files within Document Library

Question

My company is trying to develop a solution within Sharepoint for sharing documents across similar departments of different companies.

The requirement is that there is a store of documents that each companies department, for this example marketing, can upload to. Each document would be tagged with the uploading users company and a flag allowing it to be public. The idea is that users should be able to see a.) Files that are marked as their company and b.) files that are marked public.

The ideal solution would be that there is some way to do this within the Document Library itself. The original idea would have been by using Audience Settings, but it doesn't appear as though this is how Audiences work.

The less ideal solution that still might work, would be to give them all their own library specific to their company, and do some work behind the scenes to maintain a separate list that everyone has access to that would contain all the shared files (so everyone would have access to their own list of files for their own company, and another with all shared files across all companies).

Has anyone tried to implement a document library with similar requirements and would be able to point me towards a 'best practices' way towards doing this or some resources on ways this could be accomplished?

Thanks

Answer 1

Interesting Question, there are a few solutions I can think of, and to do it properly all of them would require coding. (note I do not know which would be best practice and I don't know if such a thing exists for this specific scenario)

By far the most concise solution I can think of, is to do the following:

1. Use a Single Document Library for the documents with a field for the public flag (you will need extra configuration/logic if you want to restrict editing of this flag)
2. Have some means of dynamically identifying users based on company
   • This can by via groups or a list containing the user and a column for company
3. When a user submits a document, you have an Item Updating Event Handler alter the permission on the object to break inheritance and set permissions on the item to be for that company, or everyone depending on the public flag

This solution will create an entire library of uniquely secured content, so keep that in mind for future reference.

The major advantage of this method is that from process standpoint, there is only a single point of coding and everything is in one place. Alternate methods would require several libraries and different working parts, which can cause other types of complications between them.

Let me know if this is appropriate! I can get into the other ideas i had if you like as well.

Answer 2

We can also have indivdual list views for each groups and then set that view based on which user has loggend in.

Answer 3

GO for separate doc libs. Use routing (the Content organizer feature that comes with SP) to redirect content to the correct target lib based on metadata values (i.e. a column in the item that has the item's department and or company in it).

The reason for this: The limit (configurable) for unique permissions (per item) in a list is 50000. MS recommends 5000 though. This is because the more unique perms, the more performance breaks down (think SQL join upon SQL join upon SQL join) (to the level of being unworkable, and we actually LOST content because of this!!!).

Trust me, we have lost a client because of making the mistake of giving each item unique perms...

Answer 4

Why not just use folder structures and folder permissions?

\
\Corp1DeptA\Private -> Private for Corp1DeptA
\Corp1DeptA\Public -> R/W for Corp1DeptA, R to All
\Corp2DeptB\Private -> ...
\Corp2DeptB\Public -> ...
...

Then have an event receiver manage the moving of files from one folder to another based of CurrentUser's department and that public flag. You set up the "Department" column to not appear in the New or Edit forms (only Display).

Then you just have a single flattened view, that will show to everybody what they have access to across the library. There is no evil in using folders as an alternative to item-level security.

Answer 5

We developed a similar funtionality not long ago.

The demand was to share documents from withing Intranet to Internet.

We wanted to avoid any sync issues, so we didnt want to copy the files.

Instead we coded a handler (ashx file) that fetched the file based on DocumentId (actually it ended up being a handler on the internet site calling another handler on the intranet site, due to the fact that we were running anonymously, but if your case is more like an extranet you are probably authenticated).

• The handler is placed on _LAYOUTS folder on internet/intranet site
• The handler (: IHttpHandler) takes an ID parameter that matches the DocId of the document, eg _LAYOUTS/Customer/DocHandler.ashx?id=prefix12345). Behind the scenes this handler calls the handler on intranet (this can be skipped in extranet scenario) and fetches the document as a HttpWebRequest, and send result using Response.BinaryWrite()
• Libraries that need the functionality has a new custom action in Document Properties that adds a "make public" field and set InternetPublishing=true on list property bag (this is so we can also enable the functionality with PowerShell). A "DocumentReaderAccount" is added with read permissions.
• on Intranet another handler is placed in _LAYOUTS folder. Behind the scenes this handler fetches the SPListItem from the local site and send result using Response.BinaryWrite(). We check that "make public" field is checked and the document is fetched in context of a "DocumentReaderAccount" (SPUserToken) that has minimal access to the libraries that has this feature enabled

Security here ofcourse is an issue, so at all steps permissions and metadata is checked before anything is fetched.

As a bonus of using DocId and metadata we can use search on the Internet site to fetch documents that is published. Either as a tool in Rich Text Editor or as a list of "published" documents as a standard static query search web part.