Data Model

The underlying data model of SeedDMS is very similar to a regular file system with documents and folders being organized in a hierarchical structure. Folders can contain subfolders and documents. Both are owned by a certain user and have access restrictions for reading and writing. Besides that, SeedDMS offers more features not regularly found in a file system:

• Documents can have different versions

• Documents and folders can have user defined attributes

• Each document version has a status

• Document versions can be reviewed and approved

• Document versions can be revised and its reception aknowledged (since SeedDMS 6)

• Files can be attached to documents

• Documents can refer to other documents

The data model is fully implemented in what is called the SeedDMS Core. It does all the database operations. Quite often the core provides a very basic access on the data in general and puts no meaning to concepts like a document status or access rights. It is up to the web application and the user interface to provide reasonable operations by taking e.g. a document status or access rights into account.

Document

What is called in SeedDMS a document is actually a container for an unlimited number of versions. Because the name version can easily be confused with the version number it is often called content of the document. The content of a document represents the actual file behind the document. There can be various versions of a document and SeedDMS will keep them all until they are deleted. Both, the document and the version have some given attributes. For documents these are:

• Name

• Comment

• Owner

• Keywords

• Access rights

• Date of creation

• Date of expiration

Versions contain a file and have the following attributes:

• Version number

• Comment

• Creator

• Mimetype

• Original filename

• File size

• Checksum

• Date of creation

Creating a document implies the creation of a version and putting it into a document. This version is also called the latest content or latest version. Updating a document can be either the modification of the document attributes or adding a new version. Versions will automatically be numbered starting with 1, though one can choose any other version number as long as it is not smaller than the last version number.

Both, document and version have its own comment. For a document with just one version, which is also unlikely to be updated in the future, the document comment is more reasonable to be used. If there are more versions to come, then choose a comment for the document that is unrelated to a specific version and put those additional information related to the version itself into the version comment.

Keywords can only be added to a document. In the data model this can be any text, but SeedDMS provides a user interface to select keywords from a predefined list and stores them comma separated into this attribute. Removing a keyword from one of the predefined lists will not remove the keyword from the document.

The owner of the document is initially set by SeedDMS to the currently logged in user, when a new document is created. The owner can be changed later by the administrator. The owner is always somebody from the list of user accounts. Being the owner of a document means to have full access on the document. If other users are allowed to modify the document, they will also be able to add new versions. The creator of such a version will be set to the user adding the version. There are no access rights derived from the creator. It is just for an informational purpose. The owner of the document remains the user having done the initial creation of the document unless the owner is changed afterwards.

Access rights will be discussed in detail later on. Just one note: by default access right do not take the version into account. If a user has a particular access right on a document, the user has it for each version as well, regardless on who added that version.

The date of creation is something stored for both documents and versions. For the first version the date of creation is identical to the date of creation of the document (though in theory they could differ because of minimal time lack between the creation of the two). Later versions will have the current time. The document creation date will never be updated.

A document has another date which specifies the point in time when the document expires. Thought this date is a property of a document it has influence on the status of the last version (see below for more information on the document status). The way SeedDMS handles this is mostly driven by the user interface and not the underlying core of SeedDMS. The core just provides methods to set the expiration date and to recalculate the status of the latest version. It is the user interface which calls those methods when needed.

Whenever a document is accessed through the user interface the expiration date is checked against the current time. If the expiration date is in the past and the latest version is still set to be released, it will change its status to expired. This is somewhat confusing, because the expiration date is a property of the document but the status is actually a property of a version (though it is often referred as document status). So in theory adding a version to a document with an expiration in the past, will set the status of that new version immediately to expired. Actually, SeedDMS’ user interface will by default unset the expiration date of the document when a new version is uploaded. So, new versions will not be expired right away.

A version has some more specific properties which are related to the actual file being stored. The mimetype, file size and checksum could be derived from the file itself but are also stored in the database for better performance, security and redundancy. The original file name is the name provided by the browser when the file was uploaded. It would get lost, if it was not stored in the database, because SeedDMS renames the file when put into the data store. The mimetype is either provided by the browser or determined on the server when a new version of a document is uploaded. In general it is good advice to let the server determine the mimetype, because browsers often deliver slightly different mimetypes for the same file format which complicates the generation of the preview images and fulltext index. The checksum of an uploaded file is always calculated on the server. It is used to discover modifications of a document content.

Status

As mentioned previously, the document status is not as easily understood as expected. This status should actually be called version status because it is stored per version. The document status as occasionally mentioned in the user interface of SeedDMS is the status of the latest version. If this document uses the term document status it will exactly use it in that notion.

The version status can be one of the following values:

• released

• expired

• obsolete

• waiting for review

• waiting for approval

• in workflow

• rejected

SeedDMS 6 introduces two more status:

• in revsion

• needs correction

The first three values are possible for any document, the other values are only possible for documents in the traditional or advanced workflow. The two new status are for the revision workflow.

The status is not stored as a single value but as a list of status changes. Each change will add a new entry containing the date of change, the new status, a comment and the user in charge for the change. The core of SeedDMS provides methods for modifying this list of changes directly, but most of the time this is done by a method which checks various parameters and recalculates a new status, e.g. reviewing a document version. The core just keeps track of the document status but does not interpret it in any way. This means for example, that expired or obsolete document versions can still be altered at will. It is completely up to the application to give the document status a meaning and possibly restrict certain operations on a document.

Links

Documents can be linked together in the sense of a hyperlink in the WWW. Except that the link is not placed in the document content itself but attached to the document. The target is also just another document. The user interface calls this related document. Those links can either be public or only visible to the user creating the link. There is no further meaning in the link.

Attachments

Attachments are very much like attachments known from emails. It can be any file associated with the document. Attachments have a name, a comment and are always public if the document is readable by the user. All other regular users will see the attachment only if it is explicitly marked public. Since SeedDMS 5.1.0 attachments can be either linked to the document or a specific version of the document. Files attached to a version of a document will be deleted when the version itself is deleted.

Categories

Categories are a rather simple concept of attaching predefined tags to a document. Categories can only be defined by an administrator, but can be used by all users when adding or modifying a document. Categories are linked to documents only. Compared to keywords they are linked on the database level, which means, that a category cannot be deleted if is still used by a document. Categories are often used to classify a small number of document types (like order, invoice, contract) or to associate a document to a certain domain, department, etc. SeedDMS can filter documents by category in the search result. User defined attributes can to some extend be used to achieve a similar user experience.

Folder

Folders are containers for other folders (subfolders) and documents. Folders have a very similar set of attributes like documents:

• Name

• Comment

• Owner

• Access rights

• Date of creation

There meaning matches those of the document attributes.

Attributes

Beside some already described hard coded attributes - folder, documents and versions can have user defined attributes. These attributes are key/value pairs complying with an attribute definition previously set up by the administrator. Attribute definitions declare various properties of an attribute:

• the object type it can be used for (folder, document, or version)

• the type of the value (string, integer, float, email, date, …)

• an optional set of allowed values

• a minimum and maximum number of values

• a regular expression the value must match to be valid

The object type can limit the scope of where an attribute may be used. If it is not set, it may be used for folders, documents and versions. The minimum value determines whether an attribute is required. Any value greater then 0 will make the attribute mandatory. The maximum number of values is only usable if a set of values is given. The regular expression is only used for attributes of type string. SeedDMS core will not enforce any of the restrictions mentioned above. The database will store the attribute value always as a string. A given value set must be in the form <sep><value><sep><value>... with <sep> (separator) being any character not used in a value itself. Any white space right after and before a separator will be removed, when the attribute definition is saved.