Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

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

share|improve this question
add comment

5 Answers 5

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.

share|improve this answer
    
This could work. I had not thought of using an Item Handler to change the permissions on individual items. It is possible to target items to specific groups via code? –  Mike Kshymensky Mar 30 '12 at 20:57
    
Absolutely, social.technet.microsoft.com/Forums/en-US/sharepoint2010setup/… and blogs.msdn.com/b/robgruen/archive/2007/11/15/… are two good examples to get you going with how to code it –  Zork Mar 30 '12 at 21:04
    
+1 for a good idea. The downside is that you'll have a library of unique permissions which can easily grow to be un-manageable long term. For example, if you ever needed to change the security settings you would need to modify a lot of documents. –  Kit Menke Mar 30 '12 at 21:07
    
Your completely correct, unfortunately in order to get around that, you would have to do something similar to what Mike mentioned above.. although when i think about it, you might be able to create a webpart that pulls all documents from libraries you have permission to, and then using an administrative delegate, pull all items from the rest that have a public flag... which seems just as reasonable the more i think about it, and easier to scale as well... –  Zork Mar 30 '12 at 21:13
    
+1 this is an idea I may have to explore. I would love to hear any other ideas you may have as well –  Mike Kshymensky Mar 30 '12 at 21:14
show 2 more comments

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

share|improve this answer
    
This would not prevent access to other views nor actually restrict users from editing documents they should not be able to even see. This type of solution is valuable for organizational purposes when the user is allowed to view/edit all items, but may not need to. –  Zork Jun 20 '12 at 15:32
add comment

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...

share|improve this answer
    
The one question I had about content routing is that is it possible for a file to be routed to two places. –  Mike Kshymensky Apr 2 '12 at 13:49
    
Correct me if I'm wrong, but content organizer only moves files, and even if it copied something over to a second document library, edits would NOT be consistent across the two documents. That is the reason I did not suggest this type of solution. –  Zork Apr 2 '12 at 14:05
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.