Here are my initial notes around what we can and should do with MyDMS to create our DMS. Please add your comments, so we can lay out a development path.
Okay. Here are my implementation thoughts, taking Moodle's current structure into account, and looking ahead.
DMS Structure
The DMS has to be a conceptually separate entity from the category/course/activity structure of Moodle (much like the User Administration is). This is not to say that it should feel like a separate application running alongside Moodle - it should not! It should still be an integral part of the whole, just removed from the creation of courses. In other words, I should be able to create and manage documents even if I don't have any courses.
In that sense, we need to define the following issues:
- Where does the DMS reside?
- Where does the repository reside?
- How is the repository structured?
- What can it contain?
- How do users access it?
- Who can access it?
- How is it accessed by courses/activities?
- How are documents tagged?
Where Does the DMS Reside?
Because it is conceptually a separate function from Moodle, it should be designed such that it can run on a server separate from Moodle. It should share a user database and any group and role functionality (present and future) with Moodle. It should be able to share a database with Moodle or use its own.
Development Implications:
- Have an API that can be called from any application. Reduce/remove dependencies on Moodle globals and constants.Have a separate configuration file that can be included in the Moodle configuration file.
- Since they share an authorization function, design should allow for authorization function to be part of DMS, Moodle or separate.
- Initially, develop DMS to work integrated with Moodle. This is the easier path, and will allow for the primary functions of DMS to be established first.
- How will Moodle exchange information and data when DMS is on a separate server? XML-RPC, SOAP?
Where does the repository reside?
This shouldnt matter, according to the above. The physical repository is a combination of disk/file structures and database tables. The important issue is that all access is controlled via the DMS to maintain integrity. It would be ideal if parts of the repository file structure could be located in different physical locations. That way, the entire system expands easier.
Development Implications:
- Configurable locations for repository structures.
How is the repository structured?
Initially, to keep things simple and to work with Moodles current Category / sub-category / course, user and group structure, I suggest creating two directory structures just below the DMS root, called: Course Root and User Root. (see diagram)
This structure will allow Moodle to easily control access to documents within the existing CategoryCategoryCourseGroup structure. DMS groups can be implicitly created for each category, sub-category, course and group (implicitly meaning, we dont need to use the DMS group table, just code it based on the structure). Access levels to documents could then be granted to users at the group, course, category and/or site level. Access should be able to be denied/granted on a per file, per structure level.
The User Root structure will allow for private stores to be set up per user.
Below these levels (at any level), structures should be based on user / site preferences and languages (i.e. images, documents, assignments, etc.).
Development Implications:
- Until we have implemented a more robust role/group structure around all of Moodle, using the course hierarchy seems the best structure to work with DMS.
- Access code will need to access the course student lists to handle group emulation.
What can it contain?
Everything we can currently store in the file application all defined MIME types. Plus, zip file archives and course backups. Thought should be given to other packaging options, such as Learning Objects.
For now, we may want to define a standard keyword system to describe zips or other archives. We will want to differentiate between course backups and other file collections, as a minimum.
MyDMS provides both a download and a view online function. These are both desirable features to be kept.
Development Implications:
- MyDMS uses an Apache mod, mod_rewrite. Look at this for use in Moodle.
How do users access it?
Currently, there is no direct access to file functions for students. Access to these functions needs to be provided somewhere in the interface perhaps in the My Moodle menu?
Teachers, creators and administrators will access it as it is now from the file option in the administration menus. If we use the hierarchical structure proposed above, some access will need to be provided at the category level.
Who can access it?
Everyone, according to the restrictions imposed by the authorization schemes. Limits will need to be placed on storage sizes, to control the user stores.
Development Implications:
- MyDMS currently has no size limitations built into it. Code will have to be added to control this.
How is it accessed by courses/activities?
To add these to courses, we will need to add them similarly to now, via a resource. The file upload option in resource activities will need to access the new DMS features, and allow any file accessible to the course be selected. When accessing this resource, options should be available to download it, or view it online.
Searching should be available to the course.
Development Implications:
- Can versions of the document other than the current one be accessed from a course?
- Is the resource activity the best way to access a file from the DMS?
- Need to be able to deal with changed access levels.
How are documents tagged?
MyDMS allows for keywords and comments to be attached to documents and their versions. We have these available to us as a minimum.
Development Implications:
