After reading Hariska2@drupal.org's comment about creating a rudimentary DMS module, I was thinking about wanting just such a thing. (It is part of the reason for establishing this group.)
However, much of the functionality already exists. I want to make sure that if I aid in the creation of a new module for document management that that module doesn't totally overlap existing functionality to much. However, there are some pretty significant improvements that I think could be made. I will commence with suggesting the things that already exist and then consider what is missing.
Existing Features
These pieces exist, but might use some improvement in order to coordinate with building a document management system.
Access Control
Drupal has plenty of access control. There's Taxonomy Access Control, Taxonomy Access Control Lite, Category Access Control, Organic Groups, CCK Field Permissions, and others.
I can, though, see a possible need for an additional access control module for accessing the document itself. For example, one might have access to the metadata, but not the document itself. Though, this could be regulated via filefieild and CCK Field Permissions.
File Upload
There are a few different modules for handling file uploads. However, it would be nice if these could be better unified. There are modules for handling images, audio, video, any kind of file, etc. You can upload multiple files per node or some can limit the uploads to one per node. It is nice that the upload module provided with Drupal out of the box handles revisions gracefully.
This is an area that I've not looked into deeply, but it seems like all the modules are limited for use in a DMS in some respect. This might be resolved by beefing up some of the new file-based CCK modules and creating specialized DMS-related node types to handle different kinds of media (probably a good idea anyway).
Document Metadata
This one seems obvious to me: CCK. Each document is a node with one or more files associated with it (multiple files to represent multiple formats or versions of the document). If you need to associate metadata with the document or document group, you can do so with CCK fields.
Categorization
This one is also obvious. If Drupal provides anything, it provides a categorization system.
Workflow
The workflow that is built in to Drupal is just satisfactory. You can at least mark a node as published or unpublished and can create multiple revisions of the document. I know that you can, with the built-in upload module at least, also provide multiple revisions of the uploaded document.
It's not uncommon for the needs of a DMS publisher, though, to extend beyond rudimentary moderation systems. For more advanced handling, there is the Workflow module, though I'm not sure how mature it is (I haven't looked very far into it for 12 months and it wasn't usable then.)
If you're needs extend very far beyond that, you're talking about major workflow engine. A product like Bricolage or Magnolia or Alfresco is probably called for to handle complex needs rather than reinventing those systems here. (Not to discourage it if someone really wants to, just letting you know that you can plug those systems into a Drupal front-end with a little effort.)
Missing Features
Okay, so now for the features I wish Drupal had better support for, but I haven't really seen anything.
Search
This might actually be supplied in one of the newer search modules that I haven't examined, but being able to search the contents of the documents themselves is a must. If you upload a Word document, Excel spreadsheet, PDF, ODF files, OneNote notebooks, etc. it would be good if Drupal could search those. There are indexing and search systems out there already for such, but they would need to be integrated or new systems written.
If you want to get really emotional about it, you could even use an OCR scanner to find text in images and video for indexing and a speech recognizer to pull text for indexing out of video and audio media. I can think of similar work being done to unravel the mysteries held in Flash formatted files, etc. That's all dreaming though.
Hierarchical Browser
Drupal sorely lacks a hierarchical browser. There are a couple modules that sort of provide something kind of like a hierarchical browser, but nothing like a file tree or the Apple column view that would really make browsing categorized documents easy.
The great thing, though, is that if you think of taxonomy terms as the directories and the nodes (with attached documents) as the files, you could have multiple views of your hierarchy. This module would not have to be at all linked with document management. This would just be a solid node browser with the ability to assign icons to nodes, etc.
File Organization
All of the file upload modules are really flat when it comes to how they store the files. I don't particularly care if the actually file structure storage mirrors the taxonomy or something like that, but you simply can't store all your files in a single directory.
There needs to be a flexible way of partitioning directories so that you don't have 100,000 files in a single directory (which will kill the performance of many modern file systems). This could be done by assigning every file a UUID and storing the file according to that UUID or something. It needs to at least partition the files. If the structure for handling file storage were flexible and could be according to some particular taxonomy, all the better for situations that is suited to.
DMS Bundle
Ultimately, what we really need is an über-module for bundling the work together into a "drop this into your Drupal install, turn it on, and shazaam, you have a DMS". With Drupal 5.1, this module could require all the others be turned on before operating and then start with a single settings screen that has a big button to setup the DMS system, which creates node types, a basic taxonomy, etc.
The hard part being that certain aspects can be handled by different extra modules in different ways. The way that suits your setup might not be best handled a given way. Perhaps the module could provide some basic structure where you answer a few questions (e.g., TAC or TAC Lite or OG?) and then it sets up a basic structure that you can customize. If you want to be totally custom, you don't use the DMS bundle, but just piece it together yourself.
Just Ideas
Anyway, all of this is very preliminary and just some ideas. Please feel free to comment or post new ideas. This group belongs to you. I just started the thing and have an interest in making sure something happens in this direction. The exact nature of the ultimate solution will work better if folks better than I, that is, if you put in your 2¢.
Cheers.
Comments
hierarchical browser
Some (long) time ago, I've done a module for 4.6 that provides you with a taxonomy based filebrowser. The UI is rudimentary, but for browsing/viewing documents it is sufficient.
Although the code Is not suitable for maintream use there are a fiew things I discovered chatting to users. File uploads should be straight from the browser view. This comes together with another 'perception' they had - these things we are uploading are files, not [other] nodes. Which lead me to firmly believe that there is a need for a contrib module doing the files as nodes thing. How exactly, is something I haven't really though about. Even more - how to attach metadata to that - I'm not sure, but... The idea, that clicking on the node title should download the document was/is a constant request I get.
Tying the files with the drupal revisions system properly is another frequent request I get.
Being able to use the windows explorer(nautilus,plug in your favourite file manage here) is another very popular request. Fortunately webdav can help out. The GSOC 2005 webdav code does the heavy lifting, but we would mneed to evaluate the usability of the code in real terms.
Files as nodes
You're bang on with that idea. There was a project that aimed to do that a while back (and even split files across multiple directories, if I recall correctly), but I don't think it was ever updated for Drupal 5.
search_attachments
There is actually a module called search_attachments that allows Drupal to search attachments as well. It uses freeware Unix utilities to parse text, Word, and Excel files, and I was able to add in support for a PDF parser. Unfortunately, it isn't set up as a project on Drupal.org, but it really should be.
Search Files Module
A quick update about this. I discovered that this module has since been merged into a module called Search Files, which is available for D5 and D6, and seems to be enjoying ongoing support.
FWIW, I completely agree with the issue raised about being able to replace documents instead of just adding a new one (by default, anyway).
Hierarchical Browser
I agree that there shoudl be a better hierarchical browsing system. I recently discovered that another developer and I had both written taxonomy matrix modules, that allow you to browse content as the intersection of a couple of vocabularies, properly generating breadcrumbs, menus, and so on. Integration with image_module is a plus, to get some visual cues.
Also, there's a module called upload_preview, which creates a preview of uploaded files. I was able to make a spinoff module called upload_preview_view which displays the same preview when viewing documents in either list or detail view. I was also able to tie it into ghostscript, to rasterize PDFs into a preview, and set default icons for PPT, DOC, and XLS documents. It's a little crude just yet, but hopefully I can refine it into something worth posting as a project.
Ext JS has a beautiful GUI
After looking at the recently released Ext JS web site, I've been very interested in using Ext JS in a couple projects I'm using. One is Prototype-based and the other (Drupal) is jQuery based. ExtJS builds a standard and very pretty GUI interface on either. Starting with a basic ExtJS module, I think it would be nice to then build some UI on that.
However, that's about as far as I've had time to think about it thus far. ;)
Elaborate?
Can you elaborate on what Ext JS is doing for you that jQuery can't? It's not 100% clear from looking at the web site.
I do see a folder-type icon system that would be intuitive for most computer users. If that's what you're refrring to, then point taken.
There is a project called WebFM that does do some interesting things, but at the moment is mostly intended as an administration tool.
I should have linked the docs/demo page
See this page: http://www.extjs.com/deploy/ext/docs/index.html
jQuery only provides a cross-browser foundation for building animations, UI, and other functionality, but doesn't actually provide any widgets. The Drupal contributors have built some nice widgets on jQuery, but Drupal is still really clunky in comparison to the widgets provided by ExtJS. I'm not saying that ExtJS needs to be brought into Drupal to fix it or that a browser module should absolutely depend upon it.
However, if it could use ExtJS to provide the extra smoothness to the UI (with a graceful degradation when not available), that would be awesome. Looking through the demos of ExtJS just made me drool, so I'm commenting about it here.
I'm also just suggesting an idea of what's possible. I'm not making any design decisions here.
Footprint?
Do you know what the overall footprint is for ExtJS, in terms of download size? I know that was one of the reasons they chose jQuery, was a relatively small downlaod requirement.
Still, there's no reason a module that woudl make extensive use of ExtJS couldn't load that in. And it does seem to have some very nice features, especially for the application this discussion is centered around. ny chance we could look at some kind of a demo for one or more of the Drupal sites where you've applied it?
No, I don't know...
I haven't actually done anything with ExtJS except read about it and tried out the demos. I probably won't have the opportunity to do anything until the second week of May at the earliest (we've got a crazy launch schedule coming up at work).
I don't know much of anything at all about ExtJS. That's one reason I said it was just a thought and that I hadn't really taken long to consider it yet. But that's the kind of sweet action I'm hoping for. After using the DMS in Magnolia, I'm really desirous of a nice Explorer-type interface that will be easy for my site authors/members to comprehend. ExtJS looks to provide that pretty easily, but I haven't performed a full evaluation and would be interested if someone has another option they think would be a good alternative.
A small foot-print is certainly a noble pursuit in a platform like Drupal because not everyone wants a heavy load. jQuery is a great choice because it provides quite a bit in a very small package. However, memory footprint isn't the prime concern for me. Yet, if we can provide something that degraded based upon the available tools (say a simplified jQuery-based script without ExtJS and plain old links without any JS), that would allow the module to hit a wider audience (and thus, gain better development support).
DHTML Menu + CSS
DHTML Menu should provide the ability to quickly navigate to the node you want (without page refreshes), the folder-style interface could be achieved with some CSS. Maybe part of the solution for adapting Drupal for Document Management should be a theme that makes the interface seem more specific to the purpose.
BTW, have you played around with Alfresco at all?
Revisioning
What do you mean by saying that It is nice that the upload module provided with Drupal out of the box handles revisions gracefully ? I noticed that drupal will add _x for files with same name.
But real revisions of uploaded documents would be important to have in any DMS. At the moment I can use book and upload modules to allow users to have different revisions of their documents, but this requires users to use those remove and list selections to show only the latest revision of the document. Then after changes, downloading the document will end up with a file named file.doc_23. This solution eats a lot of disk space when every time the document is changed, a new file is created to the server.