|
|
| (2 intermediate revisions by one other user not shown) |
| Line 1: |
Line 1: |
| | {{#pagetitle: Accession module }} | | {{#pagetitle: Accession module }} |
| − |
| |
| | [[Main Page]] > [[Development]] > [[Development/Accession module]] | | [[Main Page]] > [[Development]] > [[Development/Accession module]] |
| | | | |
| | + | On this page you'll find historical development documentation about the the accession module in earlier versions of ICA-AtoM, information about development enhancements added to 2.x, and discussions about future development considerations for enhancing the accessions module. |
| | | | |
| − | '''This page contains the historical development documentation for the accession module in ICA-AtoM and AtoM.'''
| + | <admonition type="seealso"> |
| − | | + | For information on the current functionality of the accessions module in AtoM, please see the Accessions page, in the "Add/Edit content" section of the AtoM [https://accesstomemory.org/docs User Manual.] |
| − | =Introduction=
| + | </admonition> |
| − | The Accession Module is designed to establish basic intellectual and physical control over a new accession at the time it is received by the repository. By creating an accession record, information is recorded about the accession transaction, the contents of the accession and management events related to the accession. The accession record is not aimed at end-user description, such as a finding aid for the repository's archival resources.
| |
| − | | |
| − | =Resources=
| |
| − | Research into creating an Accession Module led us to the following websites and specific documents:
| |
| − | *[http://archiviststoolkit.org/ Archivists' Toolkit] and the [http://archiviststoolkit.org/http%3A/%252Farchiviststoolkit.org/support/AT1_5_User%20Manual User Manual v.1.5/1.9].
| |
| − | *[http://www.archon.org/index.php Archon] and the [http://www.archon.org/UserManualv2.2.pdf User Manual v.2.2]
| |
| − | *[http://archivesspace.org/ ArchivesSpace] and their [http://archivesspace.org/documents/Accession%20Specification-FINAL--20100421.pdf Accession Specification] and their [http://archivesspace.org/documents/Deaccession%20specification--FINAL--20100605.pdf Deaccession Specification]
| |
| − | | |
| − | =Minimum Accessions Workflow=
| |
| − | | |
| − | *'''All fields are mandatory'''
| |
| − | | |
| − | #Select option to add new accession record or to edit an existing accession record.
| |
| − | #Record accession unique identifier.
| |
| − | #Record date of acquisition of accession.
| |
| − | #Record source of acquisition.
| |
| − | #Record location.
| |
| − | #Save accession record.
| |
| − | | |
| − | =Optional Accessions Workflow=
| |
| − | | |
| − | #Select option to add new accession record or to edit an existing accession record.
| |
| − | #Record accession unique identifier.
| |
| − | #Record date of acquisition of accession.
| |
| − | #Record location.
| |
| − | #Record additional administrative information:
| |
| − | #*Donor information
| |
| − | #*Type of accession (e.g., Deposit, Gift, Purchase, Transfer)
| |
| − | #*Source of Acquisition
| |
| − | #*Record title of accession.
| |
| − | #*Custodial/Archival History
| |
| − | #*Physical content of accession
| |
| − | #*Physical condition of accession
| |
| − | #*Physical Inventory of accession (e.g., box list)
| |
| − | #*Processing Note
| |
| − | #Add or link additional information to accession record:
| |
| − | #*Extent Information
| |
| − | #*Location Information
| |
| − | #*Rights Information
| |
| − | #*Deaccession Information
| |
| − | #Link accession record to one or more:
| |
| − | #*Archival Descriptive records
| |
| − | #*Name access points
| |
| − | #*Subject access points
| |
| − | #Save Accession record
| |
| − | | |
| − | ==Deaccessioning Workflow==
| |
| − | *'''All Fields are Mandatory'''
| |
| − | #Create Deaccession Record
| |
| − | #Record Deaccession Scope (Whole or Part)
| |
| − | #Record Deaccession Date
| |
| − | #Record Deaccession Description
| |
| − | #Save Deaccession Record
| |
| − | | |
| − | ==Optional Deaccessioning Workflow==
| |
| − | #Create Deaccession Record
| |
| − | #Record Deaccession Scope (Whole or Part)
| |
| − | #Record Deaccession Date
| |
| − | #Record Deaccession Description
| |
| − | #Record Deaccession Extent
| |
| − | #Record Deaccession Reason
| |
| − | #Record Deaccession Disposition
| |
| − | #Indicate Deaccession Notification
| |
| − | #Save Deaccession Record
| |
| − | #Cancel Deaccession Record
| |
| − | #Modify existing Deaccession Record
| |
| − | | |
| − | =Functional Requirements=
| |
| − | *The software must manage accession workflow from creation to deaccession.
| |
| − | | |
| − | *The software must allow the option to create a new accession record or edit an existing accession record.
| |
| − | | |
| − | *Every accession must be documented by one and only one accession record. An accession may be comprised of a single item or an aggregation of materials.
| |
| − | | |
| − | *The software requires a unique accession identifier. The system will automatically generate an Identifier based on Administrator template.
| |
| − | | |
| − | *The software requires a date of acquisition of accession for each record. Note: The date of the acquisition of accession materials is the date of receipt that is added during the donation process. A timestamp should be generated by the system when the accession record is started.
| |
| − | | |
| − | *The software should capture the type of resource represented by the accession. (e.g., Public Record Transfer or Private Records)
| |
| − | | |
| − | *'''The software must provide the option to indicate if the record is public enabled.''' ''This item is under review. Why would the Accession Record need to be made available to the Public? Artefactual team has decided that the Accessioning Record will not be made public, and the feature of enabling will not be included in the module.''
| |
| − | | |
| − | *'''The software should capture donor restrictions.''' ''If possible, FOIPPA restrictions should be captured for individual record and sets of records. Could this be captured in the Accession Record Rights area and be linked to the Descriptive Record? This requirement was requested by City of Vancouver Archives as a High Priority.''
| |
| − | | |
| − | *'''The software should capture Copyright Holder and Copyright Status.''' ''This information is captured in descriptive, but once the records become Public Domain it is erased from descriptive record. Could this be dealt with in the Accession Record? This requirement was requested by City of Vancouver Archives as a High Priority.''
| |
| − | | |
| − | *The software must link accession records to descriptive records (and vice versa). Each accession record may be linked to zero or more resources.
| |
| − | | |
| − | *'''The software should list the accession records linked to an archival description and should include all accession records linked to lower levels of description in the same descriptive hierarchy. (optional)'''
| |
| − | | |
| − | *The software must allow navigation between accession records and descriptive records.
| |
| − | | |
| − | *The software should provide the option to restrict public access to records according to rights restrictions (e.g., copyright or FOIPPA).
| |
| − | | |
| − | *The software must save the accession record.
| |
| − | | |
| − | *The software must enable pre-populated descriptive record with accessions record information.
| |
| − | | |
| − | *The software must enable deaccessioning. The linked descriptions would require manual deletion by the Administrator to remove from public view.
| |
| − | | |
| − | *'''The software must provide customizable reports (eg., Accession or Donor Form.)''' ''This requirement was requested by City of Vancouver Archives as a High Priority.''
| |
| − | | |
| − | = Metadata Requirements =
| |
| − | | |
| − | ==Accession record==
| |
| − | | |
| − | * [http://code.google.com/p/qubit-toolkit/source/browse/trunk/plugins/qtAccessionPlugin/config/schema.yml schema definition]
| |
| − | | |
| − | {| cellpadding="5"
| |
| − | | |
| − | |-
| |
| − | | colspan="6" style="background: #ffdead; font-weight: bold;" | Accession record edit area
| |
| − | | |
| − | |-
| |
| − | ! Field
| |
| − | ! Values
| |
| − | ! Definition
| |
| − | ! Validation
| |
| − | ! Status
| |
| − | ! Review
| |
| − | | |
| − | |-
| |
| − | | Accession number
| |
| − | | Unique identifier
| |
| − | | Accession number should be a combination of values recorded in the field and should be a unique accession number for the repository
| |
| − | | Required
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Acquisition date
| |
| − | | day/month/year
| |
| − | | Accession date represents the date of receipt of the materials and is added during the donation process.
| |
| − | | Required
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Source of acquisition
| |
| − | |
| |
| − | | Identify immediate source of acquisition or transfer, and date and method of acquisition IF the information is NOT confidential
| |
| − | | Required
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Location information
| |
| − | |
| |
| − | | A description of the physical location in the repository where the accession can be found. Free text field.
| |
| − | | Required
| |
| − | |
| |
| − | |
| |
| − | | |
| − | | |
| − | |-
| |
| − | | colspan="6" style="background: #ffdead; font-weight: bold;" | Donor / Transferring body area
| |
| − | | |
| − | |-
| |
| − | | colspan="6" style="background: #eee; font-size: 11px;" | Dialog?
| |
| − | | |
| − | |-
| |
| − | ! Field
| |
| − | ! Values
| |
| − | ! Definition
| |
| − | ! Validation
| |
| − | ! Status
| |
| − | ! Review
| |
| − | | |
| − | |-
| |
| − | | Name
| |
| − | |
| |
| − | | This is the legal entity field and provides the contact information for the person(s) or the institution that donated or transferred the materials. It has the option of multiple instances and provides the option of creating more than one contact record using the same form.
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | | |
| − | | |
| − | |-
| |
| − | | Contact information
| |
| − | |
| |
| − | | Mailing address, phone and email of the donor, the transferring body and/or the contact person(s).
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | colspan="6" style="background: #ffdead; font-weight: bold;" | Administrative area
| |
| − | | |
| − | |-
| |
| − | ! Field
| |
| − | ! Values
| |
| − | ! Definition
| |
| − | ! Validation
| |
| − | ! Status
| |
| − | ! Review
| |
| − | | |
| − | |-
| |
| − | | Acquisition type
| |
| − | |
| |
| − | * Deposit
| |
| − | * Gift
| |
| − | * Purchase
| |
| − | * Transfer
| |
| − | | Term describing the type of accession transaction and referring to the way in which the accession was acquired.
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Type of resource of accession
| |
| − | |
| |
| − | * Public transfer
| |
| − | * Private transfer
| |
| − | | Select the type of resource represented in the accession, either public or private.
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Title
| |
| − | |
| |
| − | | The title of the accession, usually the creator name and term describing the format of the accession materials.
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Creator / Department
| |
| − | |
| |
| − | | The name of the creator of the accession or the name of the department that created the accession
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Custodial / Archival history
| |
| − | |
| |
| − | |Information on the history of the accession. When the the accession is acquired directly from the creator, do not record an archival history but record the information as the Immediate Source of Acquisition
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | | |
| − | |-
| |
| − | | Scope and content
| |
| − | |
| |
| − | | A description of the intellectual content and document types represented in the accession
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Physical condition
| |
| − | |
| |
| − | | A description of the physical condition of the accession and if any preservation or special handling is required
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Received extent units
| |
| − | |
| |
| − | | The number of units as a whole number and the measurement of the received volume of records in the accession
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Processing priority
| |
| − | |
| |
| − | * High
| |
| − | * Medium
| |
| − | * Low
| |
| − | | Indicates the priority the repository assigns to completing the processing of the accession
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Processing status
| |
| − | |
| |
| − | * Complete
| |
| − | * Incomplete
| |
| − | * In-Progress
| |
| − | | An indicator of the accessioning process.
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Processing notes
| |
| − | |
| |
| − | | Notes about the processing plan, describing what needs to be done for the accession to be processed completely.
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |}
| |
| − | | |
| − | | |
| − | {| cellpadding="5"
| |
| − | | |
| − | |-
| |
| − | | colspan="6" style="background: #ffdead; font-weight: bold;" | Optional fields under consideration
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | ! Field
| |
| − | ! Values
| |
| − | ! Definition
| |
| − | ! Validation
| |
| − | ! Status
| |
| − | ! Review
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Expected completion date
| |
| − | |
| |
| − | | Include day/month/year that accession process should be completed
| |
| − | |
| |
| − | |
| |
| − | | Not needed by CVA. Not to be included in accession module.
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Retention Schedule
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | Not needed by CVA. Not to be included in accessions module.
| |
| − | |
| |
| − | |
| |
| − | | |
| − | | |
| − | |-
| |
| − | | Inventory
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | Not added to MockUps yet
| |
| − | | Under review
| |
| − | | |
| − | | |
| − | |-
| |
| − | | Notes
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Linked subjects
| |
| − | | terms
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Linked names
| |
| − | | authority records (actors)
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Linked resources
| |
| − | | archival descriptions
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |}
| |
| − | | |
| − | ==De-accession==
| |
| − | | |
| − | {| cellpadding="5"
| |
| − | | |
| − | |-
| |
| − | | colspan="6" style="background: #ffdead; font-weight: bold;" | Deaccession area
| |
| − | | |
| − | |-
| |
| − | ! Field
| |
| − | ! Values
| |
| − | ! Definition
| |
| − | ! Validation
| |
| − | ! Status
| |
| − | ! Review
| |
| − | | |
| − | |-
| |
| − | | Deaccession scope
| |
| − | |
| |
| − | * Whole
| |
| − | * Part
| |
| − | | Identify if the whole accession is being deaccessioned or if only a part of the accession is being deaccessioned
| |
| − | | Required
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Date
| |
| − | |
| |
| − | | Date of deaccession
| |
| − | | Required
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | | |
| − | | |
| − | |-
| |
| − | | Description
| |
| − | |
| |
| − | | Identify what materials are being deaccessioned
| |
| − | | Required
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | | |
| − | |-
| |
| − | | Extent
| |
| − | |
| |
| − | | The number of units as a whole number and the measurement of the records to be deaccessioned
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |-
| |
| − | | Reason
| |
| − | |
| |
| − | | Provide a reason why the records are being deaccessioned
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | |
| |
| − | | |
| − | |}
| |
| − | | |
| − | ==Rights==
| |
| − | Like an Accession Record, Rights are their own individual entity in the Qubit data model. See [[Rights]].
| |
| − | | |
| − | Rights entities can be linked to accession records, information object (intellectual entity) records, and digital object (manifestations) records.
| |
| − | | |
| − | When the 'Create Archival Description' option is selected, a copy of each of the rights records linked to the accession record are made for the new archival description, i.e. rights may be revised over course of archival description but original rights records remained versioned against the accession record.
| |
| − | | |
| − | =Record Linking/ Data Relationships=
| |
| − | | |
| − | *Accession Records to Archival Description (Many to Many)
| |
| − | *Accession Records to Donor Name (Many to Many)
| |
| − | *Accession Records to Authority Records (Many to Many)
| |
| − | | |
| − | *Accession Records to Deaccession Record (One to Many)
| |
| − | *Accession Record to Extent subrecords (One to Many)
| |
| − | *Accession Record to Date subrecords (One to Many)
| |
| − | *Accession Record to Rights subrecords (One to Many)
| |
| − | *Accession Record to Location subrecords (One to Many)
| |
| − | | |
| − | == Copying fields from accession records to information objects ==
| |
| − | {| cellpadding="4"
| |
| − | |-
| |
| − | ! Field
| |
| − | ! RAD
| |
| − | ! ISAD
| |
| − | ! DC
| |
| − | ! MODS
| |
| − | |-
| |
| − | | '''Title'''<br />(title)
| |
| − | | Title
| |
| − | | Title
| |
| − | | Title
| |
| − | | Title
| |
| − | |-
| |
| − | | '''Creator'''<br />(QubitRelation)
| |
| − | | QubitEvent
| |
| − | | QubitEvent
| |
| − | | QubitEvent
| |
| − | | QubitEvent
| |
| − | |-
| |
| − | | '''Physical condition'''<br />(physical_characteristics)
| |
| − | | Physical condition
| |
| − | | Physical characteristics and technical requirements
| |
| − | | <span style="color: Red;">There is not any correspondence</span>
| |
| − | | <span style="color: Red;">There is not any correspondence</span>
| |
| − | |-
| |
| − | | '''Scope and content'''<br />(scope_and_content)
| |
| − | | Scope and content
| |
| − | | Scope and content
| |
| − | | Description
| |
| − | | <span style="color: Red;">There is not any correspondence</span>
| |
| − | |-
| |
| − | | '''Archival history'''<br /> (archival_history)
| |
| − | | Archival history
| |
| − | | Custodial history
| |
| − | | <span style="color: Red;">There is not any correspondence</span>
| |
| − | | <span style="color: Red;">There is not any correspondence</span>
| |
| − | |}
| |
| − | | |
| − | =UI Design=
| |
| − | | |
| − | <gallery widths=300px perrow=3>
| |
| − | File:Acc_HP_Add.png| Add Accession Record
| |
| − | File:Acc_Edit2.png| Accession Record Edit Area
| |
| − | File:Acc_Edit3.png| Donor/Transferring Body Area
| |
| − | File:Acc_Edit4.png| Administrative Area
| |
| − | File:Acc_Edit5.png| Rights Area
| |
| − | File:Acc_ShowPage.png| View Accession Record
| |
| − | File:Dea_PopUp.png| Deaccession PopUp
| |
| − | File:ADR_ACshowISAD.png| ISAD(G) Descriptive Record with Accessions links
| |
| − | File:ADR_ACshowRAD.png| RAD Descriptive Record with Accessions links
| |
| − | </gallery>
| |
| − | | |
| − | = User Feedback for enhancing Accession feature =
| |
| − | | |
| − | The Accession module was introduced into ICA-AtoM release 1.2 in November 2011. Following release a number of questions were asked on the ICA-AtoM user forum and over the support forum regarding the functionality of the new accession feature and suggestions were made in response to use cases. The purpose of this section is to document accession-related discussions and issues in order to provide a platform for future development, when funding can be obtained.
| |
| − | | |
| − | '''LINKING'''
| |
| − | *Link accessions to existing fonds.
| |
| − | *Link existing fonds to existing accession records. (This relates specifically to legacy data).
| |
| − | | |
| − | *Link to physical storage interface that is available for archival descriptions should be available for accessions. Relationship needs to be one to many (one accession to one or many boxes or physical objects). (The current ICA-AtoM accession template offers "location information" field, but this does not allow for printing a box location list report). See Redmine Issue [https://projects.artefactual.com/issues/4540 4540]
| |
| − | | |
| − | '''SEARCHING'''
| |
| − | *The current Accessions search interface only allows searching by accession identifier. A new feature suggestion is to allow searching within the accession records, provided through the search box accessible from the Browse Accession screen. SFU has suggested an advanced search screen, which would give access to individual fields and their drop-down values.
| |
| − | | |
| − | '''ACCRUALS'''
| |
| − | *Accruals is a data entry field in Archival description template (ISAD and RAD); however, accruals is not a data entry field in the accession template. Add a dedicated field (Accrual status) with a customizable value list, suggested by SFU.
| |
| − | *What is the relationship between an accession record and accruals? See User Forum string: [https://groups.google.com/d/topic/ica-atom-users/U-SNSKh1FeA/discussion Adding Accruals]
| |
| − | *Provide accrual workflow examples in User Manual.
| |
| − | *See comment below suggesting Unit of description field.
| |
| − | | |
| − | '''RIGHTS'''
| |
| − | *Suggestion made by SFU that current rights module in accession template is too granular. Donors cannot typically transfer copyright to ALL items in accession (third-party copyright); cannot limit to series/file/item level until material is arranged and described; and typically only make detailed determination of copyright as needed (i.e., on receiving request for reproduction).
| |
| − | | |
| − | ====SUGGESTED ADDITIONAL DATA ENTRY FIELDS====
| |
| − | | |
| − | *'''Legal transfer date field''': ICA-AtoM does not distinguish transfer of physical custody only from transfer of both custody and control (legal ownership). (Current ICA-AtoM accession data entry template provides Acquisition date only.)
| |
| − | **Use case: donor wants to transfer material and also wants tax receipt; monetary evaluation must be done in same year as transfer,but typically only after arrangement and description complete; but may not be able to process within same year. Need ability to take material in, capture some descriptive info, and bring under physical control in the storage system; but treat as "pending accessioning", i.e. ownership remains with donor until Archives is ready to process and sign off formal paperwork. Add dedicated field Accession date. Alternatively, allow repeating set of Action/Date fields: Action (Transfer of custody, Transfer of ownership, Processed), Date, Staff name.
| |
| − | ***An alternative to the Action/Date fields, would be to create two new fields "Processed date" and "Processed by".
| |
| − | *'''Staff acquisition field''': Needed for accountability, could include drop-down value list with staff names. (Current ICA-AtoM accession data entry template has a Processing Notes field - free text, which could be used for this purpose).
| |
| − | | |
| − | *'''Control area field''': Track database record creation and revision with "Date record created, Last modified date, Last modified by"
| |
| − | | |
| − | | |
| − | *'''Appraisal, destruction and scheduling field''': Could be mapped to ISAD in generated information object, but not mapped to RAD (since field does not exist in RAD).
| |
| − | **Disposal authority field: Could be included in "Appraisal, destruction and scheduling field" or be a dedicated field with a link to a url of schedules if these are available online. SFU suggests it would be useful for scheduling transfers of university records, as well as Agreements to Transfer with private organizations that stipulate regular accessions.
| |
| − | | |
| − | *'''Creator copyright transfer field''': yes/no toggle (see discussion above regarding granular rights)
| |
| − | *'''Conditions governing reproduction field''': free-text
| |
| − | *'''Conditions governing access field''': free-text
| |
| − | | |
| − | *'''Unit of description field''': This field would link accession to fonds or series (highest level). Could allow multiple values for cases in which accession contains records from multiple fonds.
| |
| − | | |
| − | *'''Date range, Start and End field'''s: Populate start and end number fields automatically from Date range text field. needed for management and access purposes. SFU e.g., backlog reduction grants require date range information; occasionally we may provide access to unprocessed holdings.
| |
| − | | |
| − | *'''Forms of material field''': Customizable value list; allow multiple values. This would be useful for flagging materials that may have special storage/processing requirements, and for occasions when we provide access to unprocessed holdings; easier to search if there is a dedicated field using controlled terms (e.g., RAD GMD terms).
| |
| − | | |
| − | *'''Language of material field''': value list for individual languages; allow multiple values.
| |
| − | | |
| − | ====SUGGESTED ADDITIONAL TEMPLATE====
| |
| − | *Create separate Appraisal Table: linking an appraisal action (appraisal for acquisition, appraisal for selection, monetary appraisal and deaccession) to an accession or a unit of description or both.
| |
| − | **Use Case provided by SFU: Monetary appraisals typically done after processing and may map to more than one accession; probably best handled separately from both the Accession and Description record.
| |
| − | | |
| − | ====DEACCESSION FEEDBACK LINKING====
| |
| − | *Currently one deaccession maps to one accession; but typically a single deaccession may map to 0, 1 or many accessions (e.g., deaccessioning material that was never formally accessioned).Need to de-couple Accession and Deaccession records. Suggestion - add "Accession field" and allow multiple values. See note above regarding Appraisal table: If deaccessions were de-coupled from accessions, could be re-configured as an appraisal entity; deaccessions would be only one type of Appraisal. Appraisal record could be linked to 0,1, or many Accessions, descriptions and boxes.
| |
| − | *Link to boxes: Should be able to select individual boxes if they already are registered in the system.
| |
| − | | |
| − | ====DEACCESSION FEEDBACK ADDITIONAL FIELDS====
| |
| − | | |
| − | *Unit of description field: with interface for searching/ navigating to/ selecting unit: allow multiple values. Should be able to select the descriptive unit to which the deaccessioned material belongs if it has already been arranged and described. (In current ICA-AtoM this can be added to the "description" field in the deaccession record).
| |
| − | | |
| − | *Unique deaccession ID field: sound auto-generate a unique ID (Current deaccession number in ICA-AtoM template is a text field and is user generated not auto-entered).
| |
| − | *Deaccession by field: customizable value list for staff. This is needed to support accountability requirements for some institutions. (This info could be included in the Description field in current ICa-AtoM template).
| |
| − | | |
| − | ====ACCESSIONS USER INTERFACE====
| |
| − | | |
| − | *Structure accession fields into areas. Proposed areas: Summary, Donor/transferring body, Actions/dates, Terms of transfer, Description, Appraisal and processing, Control
| |
| − | *Add Context menu that provides links to: Donor, Creator, Fonds, and Physical storage
| |
| − | | |
| − | ====ACCESSIONS NEW FEATURES====
| |
| − | | |
| − | *'''Support import of accession records'''
| |
| − | **Use case: accession records are currently automated using another database. There should be a method for exporting accession records as text or xml files to be uploaded in ICA-AtoM.
| |
| − | *'''Support export of accession records'''
| |
| − | **Use case: export accessions data for statistical analysis in other programs (e.g., Excel, Filemaker)
| |
| − | *Print accession form needs improvement (current report is not attractive or user-friendly)
| |
| − | *Generate statistical reports (currently not supported by ICA-AtoM). E.g., how many accessions, how many meters of materials, how many MB of materials, totals broken down by: creator, fonds, acquisition type, disposal authority etc.
| |
| − | | |
| − | == User submitted mock-ups for enhancement ==
| |
| − | *The following mock-ups were submitted by Simon Fraser University's Richard Dancy and Paul Hebbard.
| |
| − | *[[File:2012_SFU_AccessionMockup.png|300px]]
| |
| − | *[[File:2012_SFU_AppraisalMockup.png|300px]]
| |
| − | | |
| − | </div>
| |
| − | | |
| − | == 1.3 Release Accessions Enhancements Introduced ==
| |
| − | | |
| − | <div class="clearfix">
| |
| − | | |
| − | * Edit Accession record template has new "Information object area" added (in production version ICA-AtoM 1.3 the language for this area will be changed to "Archival description area"). This new area provides a data entry field with autocomplete widget to select new archival descriptions, and allows the authenticated user to link and view existing archival descriptions to a new accession record. There is still the option to create a new accession record, save it, and then generate an archival description using the create archival description button in the button block at the bottom of the edit page. (All screengrabs are from 1.3 trunk version and use the generic Qubit language of information object instead of archival description). [[File:1.3AccessionCreate.png|thumb|none|Create new accession record]]
| |
| − | | |
| − | </div> | |
| − | | |
| − | <div class="clearfix">
| |
| | | | |
| − | *Here is an example of the new "Information object area" in an accession record that is linked to an existing archival description. [[File:1.3AccessionEdit.png|thumb|none|Edit accession record with linked archival description]]
| + | __TOC__ |
| | | | |
| − | </div>
| + | ===[[Development/Accession module/Historical|Historical development documentation]]=== |
| | | | |
| − | <div class="clearfix">
| + | Early development documentation, copied from the now-defunct Qubit-Toolkit wiki, which was originally used to capture development focused resources and documentation for AtoM development. For users interested in the initial design considerations that went into the accession module, this is a good place to start. |
| | | | |
| − | *If an authenticated user wants to create an accrual for an existing accession record that is already linked to an archival description, they will select the original accession record and in the View accession record page they click on the new "Add accrual" button in the button block on the bottom of the page.[[File:1.3AccessionAddAccrual.png|thumb|none|Add accrual]] | + | * [[Development/Accession module/Historical]] |
| | | | |
| − | *ICA-AtoM presents a notice at the top of the edit accession record page "You are creating an accrual of the accession YYY-NN-DD/#."[[File:1.3AccessionAddAccrualEdit.png|thumb|none|Edit accrual]]
| |
| | | | |
| − | </div>
| + | ===[[Development/Accession module/2.x development|2.x development]]=== |
| | | | |
| − | <div class="clearfix">
| + | This page will capture a brief summary of bug fixes and enhancements added to the accession module since the AtoM 2.0.0 release |
| | | | |
| − | *When the authenticated user views the new accession record (for the accrual) a new data field "Accrued to" is listed in the Administrative area.Note: "Accrued to" will be changed into "Accrual to", see Issue 2375. [[File:1.3AccessionViewAccrual.png|thumb|none|Accrual to]] | + | * [[Development/Accession module/2.x development]] |
| | | | |
| − | </div>
| |
| | | | |
| − | <div class="clearfix">
| + | ===[[Development/Accession module/Future development|Future development]]=== |
| | | | |
| − | *When the authenticated user views the original accession record a new data field "Accruals" is listed in the Administrative area.[[File:1.3AccessionNewAccruals.png|thumb|none|New accruals field]]
| + | This page is a place to document feature requests, add wishlist items, consider implementation challenges, add requirements, and other considerations and content related to possible future development of the accession module in AtoM. Note that considerations posted here '''do not guarantee inclusion in a future release.''' |
| | | | |
| − | </div>
| + | * [[Development/Accession module/Future development]] |
| | | | |
| − | <div class="clearfix"> | + | <admonition type="seealso"> |
| | + | You can check our [[Releases/Roadmap|Project roadmap]] to see if there is any upcoming accessions development! |
| | + | </admonition> |
| | | | |
| − | *When DELETING an accession record, a warning is shown if there are accruals linked to the accession record. An authenticated user may deaccession the records with no warnings. [[File:1.3AccessionDelete.png|thumb|none|Delete accession record warning]]
| |
| | | | |
| − | *NOTE: In the View accession record page, if the accession record is an accrual, the "Add accrual" button is not available in the button block. In the View accession record page, if the accession record is an original, the "Add accrual" button is available in the button block.
| |
| | | | |
| | [[Category:Development documentation]] | | [[Category:Development documentation]] |
On this page you'll find historical development documentation about the the accession module in earlier versions of ICA-AtoM, information about development enhancements added to 2.x, and discussions about future development considerations for enhancing the accessions module.
Early development documentation, copied from the now-defunct Qubit-Toolkit wiki, which was originally used to capture development focused resources and documentation for AtoM development. For users interested in the initial design considerations that went into the accession module, this is a good place to start.
This page will capture a brief summary of bug fixes and enhancements added to the accession module since the AtoM 2.0.0 release
This page is a place to document feature requests, add wishlist items, consider implementation challenges, add requirements, and other considerations and content related to possible future development of the accession module in AtoM. Note that considerations posted here do not guarantee inclusion in a future release.
