Versioning and only seeing the latest major version

Question

This is the good old question I just can't fathom there's no good solution for with SharePoint.

The business case is the following

• One document library with several content types and 3000+ documents
• Documents should always have full version history
• When documents are to be reviewed, someone will start the review and invite reviewers
• The reviewers work on minor versions of the document
• Reviewers can be anyone in the company - and the majority of employees will need to review one or more documents sooner or later
• At the same time, only major versions of documents should be available to users where they are not a reviewer

The obvious problem is that to avoid item-level permissions, all reviewers needs contribute access and they need to see draft versions. But this means that they will see all draft versions of all documents, which is not acceptable.

Anyone found a good solution for this?

Answer 1

In developer speak this is a classic "feature branch" scenario. You want to be able to work on a change to some content without affecting the "trunk" of the content, while still having the revisions merged back to trunk once you are happy with your change.

In SharePoint it seems like the closes thing to "supporting" this is to shell out a copy of a document to a document workspace (this would allow flexible managment of participants, and related information), and using a workflow to marshal the changes back to the "trunk" document when finished.

In this case the trunk document should be checked out while being in the branch (which makes it easier to merge back).

There are lots of supporting sp stuff that needs to be done in a case like this: * create workspace, * assign people to it, * check out the source document and copy it to the workspace, * remind people about the review, * collect review-done confirms from the people, * copy the document back as a new version to trunk, * approve the new version in the trunk

While some of these operations are fairly easily resolved using code, they would potentially be scattered across different deployment units and system hooks, and some (such as collecting review participant feedback) are not that trivial to implement custom.

IMO the best maintainability of this as a single functional unit would be through a workflow addon such as Nintex (albeit with some tasks having to be custom configured in Nintex too).

Answer 2

A few non-code answers come to mind:

1. While items are in review, they are in another library. Move to the main library when released. Each folder has specific permissions. If every document has a UNIQUE set of reviewers, create a library for each document. If there are documents that SHARE reviewers, create a library for each group of reviewers and store the group's documents there while in review.
2. Same as above, but use folders instead of libraries. Create a folder with unique permissions while reviewing that document, then move it back to the main folder when released.

I am trying to take your requirements at face value. You say that every person in the company is going to be a reviewer at some point for at least one document (and likely only one), this almost sounds like an Interview 2.0 brain teaser. It seems more likely that a group of people with similar expertise are going to be called on to review similar documents, so you won't need hundred of folders, just a few dozen, maybe.

Answer 3

Won't the standard "send to -> document workspace" be what you need? Then a limited group of users could collaborate on the document copy, finalize it and use "send to -> publish to source location" to publish it back to the library as a new version. See http://office.microsoft.com/en-us/windows-sharepoint-services-help/create-and-manage-a-document-workspace-site-HA010158257.aspx