Obsolete Pages{{Obsolete}}
The official documentation is at: http://docs.alfresco.com
| IMPORTANT |
| 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.
Table of Contents
Overview
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 module is implemented as a separate domain model with new mixins for records, records folders and file plans. In addition, there are JavaScript procedures located in the Data Dictionary/Scripts space with other standard scripts. There are space templates for fileplans with attached rules and actions. Finally, there are some time-based procedures for invoking various cutoff, hold and disposition actions.
DOD 5015.2 Structure
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.
Finding the DOD 5015.2 Test Data
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.
- Go to the 'Company Home'
- There you will see Records Space.
This contains:
- DOD Records Space - file plans laid out based upon the 5015.2 test suite
- A Transfer Space - area for files to be transferred or archived
- A User Space - for the users specified in the 5015.2 test suite
And as contents:
- A PDF file description of the DOD 5015.2 specification
- A word file containing the DOD 5015.2 test plan
File Plans
File Plans are a description of the plans for the following record services:
- numbering
- classification
- disposition (transfer of records and/or the ultimate destruction of the record)
- other metadata population of records. .
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 Plan Metadata
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:
| Property | Description | Datatype |
|---|---|---|
| rma:recordCategoryIdentifier | Record Category Identifier | text |
| rma:dispositionAuthority | Disposition Authority - a reference number to the regulations that govern the disposition | text |
rma ermanentRecordIndicator | 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 ?]
Vital Record Information
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.
| Property | Description | Datatype |
|---|---|---|
| rma:vitalRecordIndicator | Vital Record Indicator | boolean |
| rma:vitalRecordReviewPeriod | Vital Record Review Period | category |
Record Cutoff Information
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.
| Property | Description | Datatype |
|---|---|---|
| fileplan_cutoff.gif | ||
| rmarocessCutoff | Process Cutoff | boolean |
| rma:eventTrigger | Event Trigger | text |
| rma:cutoffPeriod | Cutoff Period | category |
| rma:cutoffOnObsolete | Cutoff When Obsolete | boolean |
| rma:cutoffOnsuperseded | Cutoff When Superseded | boolean |
Record Holding or Retention Period Information
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.
| Property | Description | Datatype |
|---|---|---|
| rmarocessHold | Process Hold | boolean |
| rma:holdPeriod | Hold Period in Years | float |
| rma:discretionaryHold | Discretionary Hold | boolean |
Records Transfer Information
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.
| Property | Description | Datatype |
|---|---|---|
| rmarocessTransfer | Process Transfer | boolean |
| rma:defaultTransferLocation | Transfer Location | text |
| rma:transferBlockSize | Transfer Blocksize in Years | float |
Records Accession Information
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.
| Property | Description | Datatype |
|---|---|---|
| rmarocessAccession | Process Accession | boolean |
| rma:accessionLocation | Accession Location | text |
| rma:accessionBlockSize | Accession Blocksize in Years | float |
Records Destruction Information
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.
| Property | Description | Datatype |
|---|---|---|
| rmarocessDestruction | Process Destruction | boolean |
Miscellaneous Lifecycle Metadata
Additional information is maintained to simplify the handling of records. This includes a counter for the records in a fileplan.
| Property | Description | Datatype |
|---|---|---|
| rma:filePlanNote | Note for presenting any other handing information for the user | text |
| rma:recordCounter | Record Counter | int |
User Defined Information
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.
Creating a File Plan v 2.0
The way to create a file plan has changed from v 2.0
To create a file plan follow these steps:
- Click the Create menu
- Select 'Advanced Space Wizard'
- Select 'From scratch' and press 'Next'
- Select the 'File Plan' space option and press 'Next'
- Fill in the name, title and description of the file plan using a name and description that helps navigation between many file plans
- Select 'Next' then 'Finish' to create the file plan
- On the new file plan, choose 'View Details'
- Click the 'Edit' button on the Properties
- Enter the metadata according to the requirements of the file plan
- Click 'OK' and the file plan is ready to process records
Records
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.
Record Metadata
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:
| Property | Description | Datatype |
|---|---|---|
| rma:recordIdentifier | Unique Record Identifier | text |
| rma:subject | Subject | text |
| rma:format | Format | text |
| rma:mediaFormat | Media Format | category |
| rma:dateFiled | Date Filed | datetime |
| rmaublicationDate | Publication Date | datetime |
| rma:dateReceived | Date Received | datetime |
rma riginator | Originator | text |
| rmariginatingOrganization | Originating Organization | text |
| rma:addressee | Addressee | text |
| rmatherAddressees | Other Addressees | text |
| rma:supplementalMarkingList | Supplemental Marking List | category |
| rma:isObsolete | Obsolete | boolean |
| rma:recordNote | Note | text |
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 |
Capturing Records
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:
- Attaches the record mixin to the document.
- Extracts any metadata from the record file, such as metadata stored in office documents or PDF.
- Runs JavaScript actions that populate the metadata and sets security based upon information stored in the file plan
- Prepends the name with the record id generated using file plan data (If the file plan id is '0031-01', then a document called 'Memorandum to All Personnel.doc' would be renamed to '0031-01-0001 Memorandum to All Personnel.doc'.)
- The life cycle of the record is calculated based upon disposition information in the file plan
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.
Using CIFS to Capture Records
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.
Capturing Microsoft Exchange E-mail Records
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.
Managing Record Lifecycles
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.
Obsolete Records
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.
Superseding Records
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.
record_supercede_properties.gif
Vital Records
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:
| Property | Description | Datatype |
|---|---|---|
| rma:isVitalRecord | Vital Record | boolean |
| rmarevReviewDate | Last Review Date | datetime |
| rma:nextReviewDate | Next Review Date | datetime |
Cutoff
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:
| Property | Description | Datatype |
|---|---|---|
| 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 |
Record Hold or Retention
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:
| Property | Description | Datatype |
|---|---|---|
| rma:holdExecuted | Hold Executed | boolean |
| rma:holdUntil | Hold Until | datetime |
| rma:holdIsDiscretionary | Discretionary Hold | boolean |
| rma:holdUntilEvent | Hold Until Event | text |
| rma:freeze | Freeze | boolean |
Transfer
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:
| Property | Description | Datatype |
|---|---|---|
| rma:transferExecuted | Transfer Executed | boolean |
| rma:transferDate | Transfer Date | datetime |
| rma:transferLocation | Transfer Location in xpath syntax; i.e. /app:company_home/cm pace/cmub_x0020_Space | text |
Accession
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:
| Property | Description | Datatype |
|---|---|---|
| rma:accessionExecuted | Accession Executed | boolean |
| rma:accessionDate | Accession Date | datetime |
Destruction
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:
| Property | Description | Datatype |
|---|---|---|
| rma:destructionDate | Destruction Date | datetime |
Records Folders
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]
Query
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.
Searching for Records
To search for records, follow these step:
- Click 'Advanced Search' in the search box on the upper right corner of the web client.
- Click the 'More search options' triangle.
- Click the 'Additional options' triangle. The metadata that begins with 'RM:' is specific to records management.
- Fill-in the criteria you are searching for.
- Press search.
The results are presented the same as any other search.
Reports
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.
Report Definition
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:
- Recent Records - records that have recently been added and sorted on the received date
- Vital Records for Review - records that are due for review in the next week sorted on the review due date
- Records Due for Cutoff - Records that are due or soon to be due are listed sorted by their cutoff date
- Records Retention Due for Expiry - These are the records whose hold is due to come off if no freeze is put in place
- Records Due for Transfer - These are the records due for transfer to a specific location (tbd: add transfer location to report)
- Records Due for Destruction - These are the records that are due for destruction in the next week or whose destruction is past due, but not deleted
Acting on the Report
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:
- ID and Properties Icon - These list the record id and link directly to the records properties for update of metadata.
- Title and Content Icon - The title of the document and its related file icon fetch the content directly into the web browser for read-only viewing of the content
- File Plan Folder and Properties Icon - The name of the file plan and properties icon next to it access the properties of the File Plan, whereas the space icon links directly to the contents of the file plan
- Originator - Currently for informational purposes only
- Date Filed - For record identification only
- Other Dates - Depending on the report, an additional due date is provided related to the action of the report
Scheduled Jobs
Coming soon.
More Information
