I have a question on how to change the default versioning behaviour of Alfresco.
Our documents go through a simple review process: a user creates or modifies a document, and requests another user to review and approve the document. As we would like keep track of the approved versions of a document, we will set a metadata field to a certain value on an approved version. At the same time the intermediate draft versions have no value to us, and we don't really want to keep them.
The documents we would like to manage are mostly MS-Office documents (Word and Excel), and we would like to use the "Edit in Microsoft Office" as the default way of editing the documents. We will also provide the other content update functionality to the end-users e.g. Upload new version. When using "Edit in Microsoft Office", a user will create a new version in Alfresco every time he saves the document in MS Word, eventually generating a long version history.
I am not sure of the approach, and I would like your opinion. I see three possibilities:
Our first idea was to change only the versioning behaviour of the "Edit in Microsoft Office" in order to limit the size of the version history: as long as a user is editing a document in MS Office, a new version is created on the first save, and subsequent saves overwrite the existing version. Unless this approach can be easily implemented, I would not choose this approach as the solution, because it does not seem right to have a different business logic depending on the UI.
Another approach was to change the versioning behaviour by extending the "VersionServicePolicies", and overwrite the latest document version (= no versioning), as long as it has not been approved (metadata field not set). If the latest document version has been approved a new (minor) version is created. I am wondering whether this solution is robust enough: maybe there will be cases where the old and new content are both lost or corrupted, for instance due to a communication failure.
Another approach I have in mind is to keep the standard versioning policy, but to delete all the intermediate draft versions on a regular basis or when a version is approved.
Note: I found a suggestion in a post to use the "versionable" aspect to activate and deactivate the versioning behaviour, but removing the aspect destroys the complete version history, so also previous approved versions.
Unfortunately, about the only thing you can easily change is how versioning is applied to regular property updates and changes via version-unaware operations, e.g. if you simply execute an action on a document that changes its metadata, or use the WebDAV protocol to rename a file. The aspect cm:versionable primarily governs the auto-versioning behaviour. Now "Edit with Microsoft Office" unfortunately comes with inheren versioning as part of its core operations, that cannot be modified / configured. This is due to that interaction having to be compatible with the SharePoint default behaviour, which Office client applications expect.
What some of my customers do is simply delete the history of minor versions whnever it is getting to long, e.g. clearing out all but the latest 5 minor versions. This can be done via a scheduled job or a policy that reacts on new versions being created. This is an approach that requires custom Java code to be written and registered with the Repository.