[dev] Functional & Design Specification: VFS with Version control and Life-cycle management

[Chris Carter]

Hi all,

First of all my apologies for this extra-long message. 

I am new to the list so please bear with me while I get to grips with
everything. Horde is all new to me. I am looking for your input to see
if there is anything I missed before actually starting the development
work.

I originally initiated this discussion on the Gollem mailing list and
Chuck recommended I bring it here. My professional background is IT, PM,
QA and QC (having worked in both IT and Pharma industries with these
roles). 

The overall goal is to implement certain DMS (Document Management
System) functionality at the core of Horde so that Horde apps can take
advantage of these. For the Horde framework, my definition of a document
is a file with certain attributes associated; these attributes include
date created and date modified, owner, version number, size (size in
bytes), content (what it contains, could be OCRed or user input), type
(doc, xls, bitmap, audio, video, etc.) and life-cycle stage (perhaps
even some user-defined attributes). Some examples of very good and
successful DMS systems are Documentum, Docuware (these are horizontal
market products with some vertical options thrown in) and LTC Organizer
(highly vertical market product).

The goal of my proposal is to produce a VFS that will support advanced
search, version control and life-cycle management for each file type.
Below I explain what I understand by advanced search, life-cycle
management and version control.

What is advanced search?
By using the document-associated attributes, it should be possible to
find any documents that meet the search criteria. For example a HR
office might use this feature to find all CV's of candidates that have
SAP experience, or an audiovisual company might use this to find
video-clips taken in Portugal.

What is Life-cycle Management?
All documents live through a life-cycle. As an example and in most
cases, Quality Procedures are first draft, reviewed, approved, effective
and finally cancelled. An email's life-cycle may look like: draft and
sent; but if we look closer, we can also add received, receiver read,
replied, response read. Note how all life-cycle stages are not actions
and tend to be in the past. Life-cycle stages also carry certain
attributes (which are specific to the stage, not the document); these
are: editable (yes or no) and current. 'Current' means which life-cycle
stage shall be used when identifying the 'current' document: the last
version of the document with a current life-cycle stage. 

What is version control?
Version control enables the system to keep multiple copies of the same
file and each one can be individually referenced. Hence it is possible
to go back to previous versions if necessary. I like to think of
versions and revisions. Depending on the life-cycle stage (if its
editable) a new edition of the document corresponds to either a new
revision or a new version.

Structure of the VFS:
Documents are stored in Repositories. Repositories associate life-cycles
to documents. They also manage access control to the repository (who can
access, who can author new documents). Documents individually also carry
access control features: who can read, author, edit. Deleting is not
possible in a true QA/QC environment because all actions must be
traceable (this leads me to the next point). BTW, the associated
life-cycle cannot be modified in a Repository once it contains at least
one document. Repositories can also be nested in hierarchy (need to
check how hierarchies are managed in Horde).

I am not aware of any audit trail features in Horde, but it would make
sense that any activities (adding new document, version, revision,
changing life cycle stage, etc.) should also be recorded with the
document information through VFS.

So much for the User/Functional Specifications. Below, is my Design:

Some modifications need to be carried out to VFS.php in order to support
some of the new features and a new version of sql_file.php renamed
dms.php would implement the rest. The following functions need to be
written:

Documents:
1. Check-in/Add new document (this involves version and revision
control, and triggers content info procedure).
2. Check-out document (leaves document locked exclusive to check-out
user).
3. Download document (does not lock document).
4. Unlock document (admin function).
5. Content info procedure (either auto or manual depending on doc type).
6. Change life-cycle stage (new docs or versions always get the first
life-cycle stage by default).
7. Change document access control.
8. Get document details and attributes.
9. Get Current Document.
10. Enumerate Document versions/revisions.

Repositories:
1. New repository
2. Change repository (name, ACL, Life-Cycle). 
3. Change repository hierarchy level.
4. Enumerate repositories.
5. Enumerate documents in a given repository (filters by life-cycle
stage).

Life Cycles:
1. Create new life-cycle.
2. Define life cycle stages.
3. Enumerate Life-cycles 
4. Enumerate stages of a life-cycle.

Audit trail:
1. Register event.
2. List events (filter options? Per document, repository, between
dates).

All the above functions should call the audit trail function in order to
record the event. And it would be great if life cycles and repository
functions also benefited from version control.

I don't know if I have left anything out, but I believe the gist of it
is all here. Anyway, the purpose of this mail is to make sure my
analysis is complete and hear your comments; so let me have it.

Cheers!
Chris

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.476 / Virus Database: 273 - Release Date: 24.04.2003