MyDMS

Found a register_globals dependency that was missed during the initial code conversion. The file affected is op.ViewOnline.php, and a fix has now been applied to CVS. If you are affected by this bug, edit $MYDMSROOT/op/op.ViewOnline.php and change line 19 to read:

$arr = split(":", $_GET["request"]);

Alternatively, you can grab the latest code directly from CVS.

I now know why the Akismet spam filter that ships with WordPress isn’t working: the SourceForge firewall is somewhat restrictive and blocks all requests originating from the web servers. Should’ve read the setup guide a bit more thoroughly…

Which means I’m looking into alternatives. Should have something up and running by the weekend, at which point I’ll open up the site to registrations (for both of you ).

Just a quick note to say that the site is now accepting registrations. Comments have been enabled for registered users.

Play nice, now.

This was supposed to be a status update, but I got a bit carried away, so here’s something completely different: the tale of how I became involved as a developer for MyDMS.

My employer, Sun Microsystems, generously allows me to develop MyDMS as part of my day-to-day work. The improvements I have been making are directly related to features required for a project management platform that I maintain. My involvement with MyDMS is quite accidential: while evaluating options for a document storage and management platform, I stumbled across a small internal repository that embeds MyDMS. The person who had set it up had wanted a simple tool with a small footprint to manage project documentation. Unfortunately, usage had spiralled on the system and performance had degraded to the point where it was extremely painful to use.

I offered to look into the problem.

(more…)

The project is still active, and I am making progress with the document work
flow (I’ll post more about that later). I’m a little behind the original
schedule, which was to have a working beta by the 1st July 2006. It’s now
looking more like the 10th July before all the features are in place. I’m
pretty sure it will be worth the wait.

The development is running late because it is close to the end of Sun’s
financial quarter and we’re in crunch mode fulfilling orders for our customer
ready systems programme. Normally, I expect to split my time more or less
evenly between managing the delivery of compute grids (and other complex
solutions) and writing software to support our processes. But at the end of
quarter we quite often get a rush on orders which means that, for me, the
software development has to take a back seat. Busy, busy, busy.

The next release of MyDMS will feature a document work-flow for managing document review and approval. This is what I have been working on since the release of 1.5.0b a few weeks ago. I’m making reasonable progress — reviewers and approvers can be assigned when uploading a new document and the “View Folders” and “View Documents” pages now display status information. There are some significant changes to the database in order to support this new feature, which I’ll describe in a future post.

Related information: process flow diagram [PDF]

(more…)

In order to support the document workflow, I have added 6 new tables to the database, organised into 3 pairs. The first pair of tables governs the overall status of a document version per the document life cycle rules, the second pair of tables record the review status and the final pair of tables record the approval status for each document verison.

The reason for recording the information in table pairs rather than within a single table for each data set is that it allows MyDMS to log historical data in an auditable, automatic way. It does make reporting a little more difficult, as one has to use a more complex query in order to retrieve the status of a given document version, but it does ensure that all transactions are recorded correctly and atomically without the overhead of having to programme in locks and scheduling. The database takes care of all of that on your behalf.

Now, as I have indicated, this is not without its overhead when querying the database. In fact, there is a small but significant change required in order to be able to support these queries without losing performance, namely the use of temporary tables to capture interim data used in a subsequent query. This makes certain assumptions about the capabilities of the underlying database and may have an impact upon the portability of MyDMS across different DMS engines. I am currently developing MyDMS using MySQL 4.1, and do not have ready access to other platforms such as PostgresSQL, so I do not know how this will affect non-MySQL users of MyDMS. Hopefully, all that anybody needs to do in order to support this new requirement is to ensure that the database user for MyDMS has drop table privileges in addition to their usual privileges.