Barcode workflows

Needed by whom and when

UCJEPS: Needed probably from day one.  The following notes should be translated into user stories and prioritized.

Overview

Provide workflow support for data entry using barcodes and barcode wands.

Dick Moe says: We currently wand barcodes into accession_id fields in SMASH. We try never to type accession_ids in. The trigger on accession_ids checks for duplicates, but does not restrict anything else. The smasch pages all open with the focus on the accession_id field, so they are ready for wanding directly. The wands are settable for appending a character or string to what they scan, so it is possible to program in a character that will cause the page focus to hop to the next field, if desired. Outside of smasch we wand ids into text files to provide input for bulk upload scripts. I presume we'd want something analogous in CS.

We keep track of outgoing loans by wanding into a field one by one (Susan Stone made this). We don't have now, but it would be useful eventually, to have a loan return check-in form where returned specimens would be wanded in (with a check made against
the outgoing loan, since it sometimes happens that people mix up loans when they return them).

Andrew Doran says: Not that i have any experience with SMASCH but we would want it to be wanded into the field and may want for CollectionSpace to check that the barcode fits our institutional pattern. Other areas where they would be needed would be when processing a loan. We would have a loan of say 300 specimens and wand them in. Also bacodes would be a good way of physically linking specimens mounted on the same sheet or 'sheet 2 of 3' being a specimen in alcohol.

Question: For scope clarification, list questions here.

User stories for definition

Please feel to rewrite these or eliminate completely!  Then move to the prioritized headings below.

Barcode workflow: To be written

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