The official documentation is at: http://docs.alfresco.com
|The module described here is NOT the interface recently certified against DOD 5015.2. |
If you're looking for the certified module, please start here: Records_Management
Note: The Alfresco Record Management AMP is an example implementation and is unsupported.
Alongside Release 1.4, the Alfresco Records Management module is an extension of the core Alfresco Enterprise Content Management system for managing the life cycle of electronic and other types of records. The records management capabilities are accessible from all Alfresco interfaces, such as the web client, virtual file system and file serving servlets, because the functionality is implemented as extensions to the core content services.
The Alfresco Records Management capabilities are modeled to support the US Department of Defense 5015.2 Records Management standards. These standards are used to evaluate the capabilities of Records Management Applications and define the requirements for managing records within the department.
The software is distributed in the file alfresco-recordsmanagement.amp which can be downloaded from: http://sourceforge.net/project/showfiles.php?group_id=143373
The DOD 5015.2 test suite is made available as an example of how to use the Alfresco records management module.
Test data is automatically loaded after MMT on the AMP file, and restarting the alfresco server.
And as contents:
File Plans are a description of the plans for the following record services:
Records are usually grouped according to their file plan, so file plans are implemented as folders (extended spaces) with a 'rma:filePlan' type. This type contains all the metadata definitions for implementing the life cycles of the records contained in the folders. The file plan also carries with it a set of rules for evaluating new records that are entered into the file plan.
Please note: (as of v1.3) Fileplans seem not intended to be cascading. So a fileplan may contain records and record folders.
File plans are modeled using the metadata of the space, so the values are set using the Properties dialog of the file plan. The metadata type for the rma:filePlan mixin includes the following core data:
|rma:recordCategoryIdentifier||Record Category Identifier||text|
|rma:dispositionAuthority||Disposition Authority - a reference number to the regulations that govern the disposition||text|
|rmaermanentRecordIndicator||Permanent Record Indicator - should never be deleted||boolean|
|rma:dispositionInstructions||Disposition Instructions - a human readable description of how the records associated with the file plan will be handled||text|
|rma:containsRecordFolders||Contains Records Folders||boolean|
|rma:defaultMediaType||Default Media Format - made available to simplify data entry for the record and is usually electronic or paper||category|
|rma:defaultMarkingList||Default Marking List - handling and classification information that are printed at the bottom of the record, such as UNCLASSIFIED or NOCONTRACT||category|
|rma:defaultOriginatingOrganization||Default Originating Org - made available to simplify data entry for the record and assumes that originating organizations are the same for the information in the file plan||text|
[ToDo : What about the 'permanent record id' checkbox next to ?]
The rma:fileplan type can mark files stored in it as vital records. Vital records must be reviewed on a periodic basis such as annually or quarterly.
|rma:vitalRecordIndicator||Vital Record Indicator||boolean|
|rma:vitalRecordReviewPeriod||Vital Record Review Period||category|
Records in a file plan are cutoff periodically to simplify the handling of records for lifecycle management. File plan specifies whether the records are to be cutoff or not, what event might trigger the cutoff. The event can be a timer or a discretionary action, i.e. obsolescence or being superseded. After being cutoff, records may be held for a period, transferred or destroyed.
|rma:cutoffOnObsolete||Cutoff When Obsolete||boolean|
|rma:cutoffOnsuperseded||Cutoff When Superseded||boolean|
After being cutoff, records may be held for a period of time before further disposition is handled. Normally this period is measured in years. Metadata in rma:fileplan indicates whether to process a hold or not. If a hold is not process, further disposition is handled immediately, such as destruction. A hold can be discretionary, such as after a change of command, and thus must be monitored manually. The discretionary hold flag allows the records management module to track these manual checks.
|rma:holdPeriod||Hold Period in Years||float|
After being held for the mandatory period of time or upon the lifting of a records freeze, a record manage may be transferred to a records holding area or other records retention area. The rma:fileplan determines how and where a record will be transferred and in what size blocks for organizational purposes. Upon execution of records transfer, the records and their metadata are moved to the space indicated where upon the agency can use the space export to move the records to the appropriate authority.
|rma:transferBlockSize||Transfer Blocksize in Years||float|
Records to be held permanently must be ultimately be transferred to the national records authority. In the US, this is the National Archives and Records Administration or NARA. The rma:fileplan specifies an area for accession transfer and the size of blocks in years for organizational purposes.
|rma:accessionBlockSize||Accession Blocksize in Years||float|
If records in a file plan are to be destroyed, they are marked in the Alfresco system to be permanently destroyed so that all information, metadata and physical trace is removed and cannot be recovered.
Additional information is maintained to simplify the handling of records. This includes a counter for the records in a fileplan.
|rma:filePlanNote||Note for presenting any other handing information for the user||text|
A simple user defined mixin for records called rma:userSpecifiedData. The base definition has privacy act information used in the DOD 5015.2 tests. Any data can be specified.
The way to create a file plan has changed from v 2.0
To create a file plan follow these steps:
Records are content items entered into a file plan. Records can be of any mime type and can be of any content type. In addition, other aspects are also allowed. Rules attached to the file plan automatically attach a 'rma:record' aspect to the record and fill in metadata according to the definitions in the file plan.
Managing record life cycle is done through the file plan properties and the metadata associated with the record. The Records Management Module adds aspects for each stage of the lifecycle and this data, mainly dates, can be managed using the standard properties dialog, which has been extended for records aspects.
The record metadata adds classification information to the record, and controls the lifecycle of the record. Some of the lifecycle behavior comes from the file plan, and some from the aspects attached to the record. According to the disposition instructions stored in the file plan, records are retained or destroyed. Aspects attached to the record can cutoff the record for processing, hold the record for future reference and ultimately either transfer the record to another authority or destroy it.
The core aspect for holding metadata for records is the rma:record aspect. This aspect describes the subject matter of the record, the content of the record, handling and processing information of the record. The metadata stored in the rma:record aspect is:
|rma:recordIdentifier||Unique Record Identifier||text|
|rma:supplementalMarkingList||Supplemental Marking List||category|
In addition, there are a number of mandatory mixins that get attached as a result of attaching the rma:record mixin. The purpose of these mixins is automatically capture information retrieved from metadata extraction actions and to take advantage of other Alfresco actions such as auditing. The additional aspects include:
|cm:auditable||Auditing for changes to the record|
|cm:author||Tracking the author and auto-capture of metadata|
|cm:referencing||Tracking when a record references another|
|rma:superseded||Tracking when a record is superseded by another|
|rma:userSpecifiedData||Mixin for user defined information|
In order to enter records into the system, the clearest way is to simply navigate in the web client to the specific file plan into which the record is to be entered and use the 'Add Content' button to add the record. Assign the name, type and content type as normal. Leave the 'Modify all properties when this page closes' checkbox checked.
After clicking OK, a set of rules in the file plan are executed. These rules modify the record in the following ways:
After storing the record and all information is pre-populated, then the properties dialog is presented to the user to fill-in all relevant record information. It is possible to have all record information pre-populated if sufficient information is stored in the file plan.
It is also possible to create a record by dragging and dropping information using the CIFS interface. This makes it easy to move large numbers of documents and make them records. However, it is not possible to enforce mandatory capture of metadata using this method and is only recommended if there is sufficient information in the file plan to pre-populate record metadata. In addition, the web client URL link in the CIFS interface can be used to view or update record information.
Using the CIFS interface, you can drag and drop e-mails from Microsoft Outlook into the file plan space. The Alfresco system will extract the metadata from e-mail files and populate information such as who the e-mail is from, who the recipients are and the subject of the email. It is recommended that the file plan contain all other information or that a workflow be set up to capture any remaining information.
To recover e-mails from the records repository, use the CIFS interface to drag the e-mail files back into Microsoft Outlook.
When the record is entered into the repository and all record properties (from rma:record aspect) have been set, the lifecycle of the record is computed. The lifecycle determines the disposition of the record. This includes events such as when the records will be cutoff or grouped together, how long the records will be held, and what happens to the record after the hold period expires, such as being transferred to a records holding area or whether they should be destroyed.
The records management module refers to information in the file plan whenever an event occurs to a record. These events can be based upon a timed-event such as an expiry date, an update event such as being marked obsolete or superseded, or a combination of timed and updates events.
A record can be marked obsolete either manually (through the UI), or through instructions in the file plan. To mark a record as obsolete, check the 'Is Obsolete' flag in the properties dialog and save. Upon save, if the file plan determines that records are to be cutoff or deleted, then they will be handled as such.
One record may supersede another. When this happens, the record that is superseded should be marked referring to the superseding record. This is a two step process. First, click 'Superceded' Action to the right of the record.
The record will be marked superceded, and a new properties section will appear. Use the search to select the record that supersedes this one. Upon save, the file plan determines whether the record should be cutoff or deleted.
If the file plan indicates that records associated with it are vital records, then a vital record review aspect is added and computed to the record. The aspect manages the previous and next review period. When the previous review is set, on update the next review period is automatically computed for the next date. This period is determined by the file plan. A report or query is used to determine which vital records in a file plan are due for review.
The information contained in the rma:vitalrecord aspect includes:
|rmarevReviewDate||Last Review Date||datetime|
|rma:nextReviewDate||Next Review Date||datetime|
The cutoff of a record is determined by the definition in the file plan. If the process cutoff flag is set in the file plan, then the record is cutoff when its time has expired, if it is obsolete or if it has been superseded, depending on the information in the file plan.
If the process cutoff flag has been set in the file plan, the file plan adds and computes the rma:cutoffable aspect to the record. The aspect stores what criteria are required to cut a record off and when a cutoff has been processed.
A cutoff can be executed either by a timed process that looks for expiry periods in the cutoff date, a cutoff as a result of a record being marked as obsolete or superseded, or by a discretionary cutoff. A discretionary cutoff, such as cutting off a record upon change of command, can be executed by marking the cutoff now flag and saving. For records to be removed or transferred immediately, the cutoff period should be set to zero and records will be cutoff immediately leading to the next lifecycle state.
When a record has been cutoff, the Alfresco records management module determines the next state based upon the file plan associated with the record: hold, transfer or destruction. The aspect for that lifecycle state is applied and calculated by the records management module.
The rma:cutoffable aspect contains the following metadata:
|rma:cutoffExecuted||Cutoff Executed - whether cutoff has been executed||boolean|
|rma:cutoffNow||Cutoff Now - flag to execute cutoff now||boolean|
|rma:cutoffDateTime||Cutoff Date - the time at which cutoff is scheduled - usually measured in months or years||datetime|
|rma:cutoffEvent||Cutoff Event - event that forces cutoff||text|
|rma:cutoffObsolete||Cutoff On Obsolete - flag to determine whether to cutoff when record is obsolete||boolean|
|rma:cutoffSuperseded||Cutoff On Superseded - flag to determine whether to cutoff when record is superseded||boolean|
A record may be held for a certain period of time prior to being deleted or transferred. Whether the record is held is determined by the file plan. After the cutoff, if a hold is applicable, then the rma:holdable aspect is applied to the record and the hold date is calculated based upon data in the file plan. If the period of the hold is discretionary, such as being based upon a human interpreted event, then a flag is set to track whether these events have occurred.
A hold can be extended at the discretion of those responsible for managing the record. This is set by setting the freeze flag on the hold aspect.
If a hold is not discretionary and no freeze is in effect, a timer will expire the hold and move the record to the next phase of the lifecycle which is either transfer or destruction.
The metadata in the rma:holdable aspect includes:
|rma:holdUntilEvent||Hold Until Event||text|
If after a hold, a record is to be transferred according to its file plan, then records management module automatically moves the record to a temporary holding area awaiting transfer. Typically records are transferred to a central records management location or another agency. After completion of the hold, the rma:transferable aspect is attached to the record and the transfer location and date for transfer are computed. A timed process is used move records to the transfer area.
Transferring the record is a manual step from the holding area. The standard Alfresco export mechanism or a JCR export can be used to package records in a form that is easy to load in a central location.
The metadata associated with the rma:transferable aspect includes:
|rma:transferLocation||Transfer Location in xpath syntax; i.e. /app:company_home/cmpace/cmub_x0020_Space||text|
Accession is the transfer of records to the national records archive for permanent storage. Very similar to the transferable aspect, the rma:accessionable aspect tracks what records have been transferred and on what date it is due.
The metadata associated with rma:accessionable includes:
For records that are due for destruction, the file plan attaches a rma:destructable aspect that computes the date for destruction. This date is generally calculated after the expiry of a hold or cutoff. The aspect manages a destruction date, after which a timer process removes all traces of the record.
In order to ensure complete removal, the sys:temporary aspect is attached, which informs the Alfresco system to remove all traces of the record.
The metadata for rma:destroyable includes:
Sometime records are grouped together due to sharing common cases or studies. To support this, spaces created inside of file plans are considered Record Folders. Record folders can store individual records that are related together. However, lifecycle information and aspects are not applied to the individual records, but to the records folder.
Record folders are created as an ordinary space in a file plan just as individual records are created in the file plan. The record folder space has the rma:record aspect applied to it and all lifecycle stages are calculated on that space. In addition, the records folder is given a unique record id as well. In this way, all records related to a case or study are handled as a whole and either archived or deleted as a whole.
Records associated with a case or study are then stored in the records folder. These records will also have the rma:record aspect added to them, but lifecycles are not calculated on the individual records. The name of the files are automatically generated just as they would be if they were placed in the file plan. However, the record id is derived from the records folder, not the file plan directly. Disposition of records in the record is handled by the record folder.
[ToDo: What happens, if 'Contains records Folders' is not checked in Fileplan metadata]
Metadata from various records aspects is included in the search form to help search for specific records based upon records processing information. Since records are aspects, the original metadata is still searchable.
To search for records, follow these step:
The results are presented the same as any other search.
A report is automatically set-up as part of the file plan template in the space templates of the data dictionary. The records report is presented whenever the user enters the file plan space using the FreeMarker Template Engine.
This report is defined in /Company Home/Data Dictionary/Presentation Templates/records_report.ftl. This report can also be applied to spaces that contain multiple file plans and aggregate results across multiple file plans. This file can be used as an example of how to set up your own records reports.
The report is broken up into six main areas:
In the following example, the report lists out a record due for vital record periodic review. The record has a number of icons and links to perform actions on the records.
The purpose of the links and icons are as follows:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.