Skip to end of metadata
Go to start of metadata

Schedule

October 1-5, 2012: Scope Review and Prioritization
October 8-12, 2012: Development Sprint 1
October 15-19, 2012: Development Sprint 1
October 22-26, 2012: Documentation and QA
October 29 - Nov 2, 2012: Development Sprint 2
November 5-9, 2012: Development Sprint 2
November 12-16, 2012: QA and Release

Overview

Work to be considered for the release includes:

  • UI performance & design improvements
  • Unified configuration
  • SaaS tool development
  • SaaS Trial Two mapping, configuration, setup, and migration
  • Documentation sprint
  • Bug fixing
  • Contribution evaluation and acceptance

The main driver is to complete work scoped in the proposal, focusing on SaaS, multi-tenancy, documentation, and special projects (install, reporting).

Contents

Caching Improvements

In Version 3.1, CollectionSpace allows its resources to be much more comprehensively cached in users' browsers. In early tests, this additional caching has made page loading noticeably faster throughout much of the application.

Included in this expanded scope of caching are term lists: that is, the lists of terms that appear in drop-down menus for many fields. Because these term lists are now cached, when you update these term lists via the Administration->Term List Management tab, or via programmatic means, users will now need to clear their browsers' caches to view the updates.

CollectionSpace's mechanism for controlling caching has also changed. You can now control the length of time that any items are cached via settings in an Application layer configuration file, and you can dynamically apply changes to those settings while CollectionSpace is still running. (Formerly, caching was controlled in a Tomcat server configuration file.)

For details regarding how to control caching, see Configuring Caching in CollectionSpace.

Versioning Support

Version 3.1 added initial versioning support for records. You can configure any record type(s) to be versioned; after doing so, each past version of the record is (effectively) maintained as an archival copy whenever the record is updated.

As an initial example, the Location/Movement/Inventory service in the demonstration Lifesci tenant is configured to support versioning in an "out of the box" copy of CollectionSpace 3.1. You can configure versioning support for one or more record types in your own tenant within CollectionSpace's Services layer; refer to this section of the 'delta' (i.e. representing just changes from the default settings) tenant bindings file for the Lifesci tenant to see how this is done.

The CollectionSpace Services REST API does not yet include query support to retrieve past versions of records. Currently, you can view these records in CollectionSpace's underlying nuxeo database, and can can write reports and other SQL queries that retrieve them.

In your reports and other queries, you can exclude (filter out) past versions of records by adding NOT hierarchy.isversion to your WHERE clause. You will only need to add this to your queries if versioning has been enabled for one or more record types in your tenant, and you want to exclude past versions. hierarchy.isversion is a Boolean column; past versions of records are given a value of true, as contrasted with values of false or null for all other records.

Versions can be ordered by their collectionspace_core.updatedat timestamps. In addition - pending successful resolution of a support inquiry to Nuxeo - past versions are expected to also receive incrementing version numbers, and their major and minor version numbers can be queried via additional columns in the hierarchy table as well.

All versions of a record share the original CollectionSpace ID (CSID), so relations, etc. work as you would expect.

Issues Resolved

Issues resolved for this release