Extension:RecordAdmin

This code is in our Git repository here. Note: If there is no information in this page about this code and it's a MediaWiki extension, there may be something at mediawiki.org.

The Record Administration extension forms the heart of our Wiki Organisation system.

To export all the templates used by RecordAdmin, see wiki articles packages

RecordAdmin 1.0

For the last couple of years since RecordAdmin 0.0.1 was created in October 2007, we've kept the version numbering to 0.x to indicate it's experimental nature. Now halfway through 2010 we've been using it for our own project management and organisation and made a number of decisions about how version 1.0 should work. Here's a summary of our findings:

1. Rather than use a category of templates to determine the record-types, 1.0 uses the items in the chosen RA namespace (default is NS_FORM). This is more logical since it's the form that determines the data types and field names within a record.
2. The record creation and editing should be done from the standard edit view rather than from a special page. This will be far simpler for the user since we could then remove the "properties" or "edit with form" action.
3. The special page is hardly ever used for searching since usually records are arrived at via a portal query. Since the special page would no longer be used for editing or creation either, it seems that it would be best for it to be removed from the main extension and made into a separate sub-extension like RecordAdminIntegratePerson and RecordAdminCreateForm.
4. There should be allowed to be any number of records in a page as long as they are all of different types. And in fact as far as edit view goes, it shouldn't even have a problem with multiple of the same type. The records should all be at the beginning of the article and be removed from the standard edit box. We need to ensure that the method we use for this doesn't interfere with FCK or MCE.
5. We decided that for organisational purposes, GUID's are the best approach for naming, but I think it's still important to be able to add record types to any title, so we still need to handle the redirect issue.
6. Exporting needs to be handled as an API method, also allowing the standard lists such as JSON for AJAX queries
7. RA is very query-heavy, but a lot of the time it would be easily possible for RA to cache results and know when revisions occur which invalidate the cache - the very least of simply invalidating them all when any record changes would still offer a massive reduction in processing.

Caching

caching uses either current cache layer or bag-of-stuff to store query result list and rendered queries by key. Keys include all the record type, filter parameters and user. Rendered results also include non-filter parameters such as template. Cache directives can be included in the queries to allow additional environment attributes to add to the key, or to mark as uncacheable. Invalidation occurs on-save and applies to all queries involving the same record-type, so recordtype must not be hashed.

API

• query: returns either a standard API list of results, or rendered HTML
• create: the new "public form" method allowing records to be created without any login