Crates and other mobile containers
Needed by whom and when
Basic statements about who needs the functionality and by when.
PAHMA: Some functions needed by the time they move to CollectionSpace as their production system
Overview
PAHMA, like many collections holders, stores groups of objects in crates and other containers. PAHMA staff do not think of these as storage locations (though in fact they might be modeled that way). They have attributes that are different from other storage locations. Not only do they themselves move more often, but their contents can change. It is possible that what is desired is some intelligence around storage locations that are mobile vs. fixed. For example, if you move a crate from one location to another, it would be nice if the system prompted you "Are you sure you want to move all objects in this container?"
Questions:
- What are the physical containers of interest to PAHMA?
- Are trays another example?
- What are other examples of system intelligence based on handling of crates and other containers? Please develop statements into user stories below.
- Would UCJEPS use this for folios and folders of specimen sheets?
Note: PAHMA's current system has some specialized screens for containers and moving containers.
Crates and Mobile Containers UCB user stories for prioritization
Crates and other containers: User can identify and describe movable object containers such as crates.
Crates and other containers: User can manage contents (i.e., objects) stored in crates and other containers.
Crates and other containers: User can move crates and other containers to storage locations and place them at different hierarchical levels in storage controlled vocabulary.
Crates and other containers: System will have intelligence to know how to handle moving of crates (e.g., when you move a crate from one location to another, the system prompts you "Are you sure you want to move all objects in this container?")
Prioritization of user stories
As definitions and priorities are clarified, the user stories above should be moved into relative order below.
Must have for 1.x-MUSEUM (when they go live in system)
Placeholder for required functionality. As a general rule, functionality that you need and use now should go here or where you have existing data. However, this is up to the museum. We will have to balance requirements against resources and timelines.
Placeholder
MUSEUM could wait six to twelve months
What could wait? These will be re-prioritized at a later date.
Placeholder
MUSEUM would like to have this eventually
These are nice to have but not a near term requirement.
Placeholder