Mark multi-records (multi-specimen sheets & multi-sheet specimens)

[PipBrewer]

Two concepts seemingly opposed, but that may be similar in implementation are the multi-specimen sheets and multi-sheet specimens, or multi-records for short (until @PipBrewer thinks up better terms).

Both entail catalog numbers (in series) that need to be linked together somehow, the easiest way being a common identifier. The multi-sheet specimens could have been grouped under a single catalog number but NHMD botany staff wanted the different sheets presumably stemming from a single specimen to receive individual catalog numbers, even though the label is only on one of the sheets. These cases could both be solved in Specify using containers.

We need a way to have these marked out somehow, but differently so, to distinguish the two concepts.

In the app, we could add a radio button control instead of the checkbox with the following options:

• Single specimen (default)
• Multi specimen object (MSO) - several specimens on one container
• Multi object specimen (MOS) - One specimen covering several containers

Depending on the chosen option a specific prefix is added to the common identifier and a flag to indicate the selection (Subsuming #344 ). It should also revert back the focus back to the barcode field every time, so that it is not need to physically click on the barcode field before scanning In Specify, the identifier would be mapped to container name and the flags to corresponding customized yesno fields.

Tasks:

• [x] Investigate Specify support for this and customize
• [x] Customize the app to support this on its end

App radio buttons

• [x] Add radio buttons to the UI
• [x] Align the boxes
• [x] Radio button must show activated depending on the container type selected.
• [x] change column name from 'multispecimen' to 'container'
• [x] single specimen objects should be kept out of container type
• [x] prefix 'container' with abbr. values MSO , MOS instead of the didactic names 'Multiple specimens on one object' and 'One spec...'
• [x] Persist the value in the container ID field AND in the DB.
• [x] Grey out container ID field on single specimen object Radio button activate AND have it default greyed out.
• [x] App UI: multispecimen object label renamed 'container type'
• [x] Process by tab: if case single specimen = then ordinary tab order is observed on first run else multi-anything = jump directly to barcode!
• [x] Each radio button is tab-able.
• [x] Single specimen radio button is persisted, and should not have a single specimen name or ID.
• [x] Prepend containerID on radiobutton action - not at saveform()
• [x] Radiobutton must follow the value of the record when stepping backward or forward.

Specify name

Container.name

Least priority:

SOUND/AUDIO WARNING when multi-stuff is active or popup box. RESEARCH!!!!!

[jlegind]

Level of effort: 'Medium'.

[FedorSteeman]

@PipBrewer Could you come with a decision on prefixes already so we could perhaps initiate import of data into the live Specify DB of those data sets containing mss?

[PipBrewer]

Single specimen object Multispecimen object Multiobject specimen

Does this work?

[FedorSteeman]

OK so container names would become

• Multispecimen_object61874620423890
• Multiobject_specimen98432453264341

Is that OK???

[FedorSteeman]

BTW in Specify, the container only has the following fields available:

• number - integer
• type - picklist with the following options already there for Vascular Plants:
  • Specimen
  • Sheet
  • Folder
  • None

The "Specimen"-type implies to cover the multiobject specimen and the "Sheet" types the multispecimen object.

Therefore the app and/or post-processing script should be adapted to record this value in a new column "containertype".

I also suggest the container name prefixes to correspond, so e.g.:

• Sheet61874620423890
• Specimen98432453264341

How about that?

[PipBrewer]

I think this is going to be an issue for multiple collections, not just Botany. It might be worth making a consistent naming system for containers. I actually think sheet and specimen is confusing when no other qualifiers, but we should ask collection managers and curators what they think.

[FedorSteeman]

Of course this could be applied to any collection. The only issue is that containers are not yet supported in Specify7 and it's unclear when they are, but we could really push the envelope if it's important.

[FedorSteeman]

Pun not intended...

[FedorSteeman]

I have finished the Specify leg of this ticket, so it is now a question of adapting the app and perhaps post-proc script.

I will therefore de-assign myself.

[jlegind]

The decision is that multisheet specimens are grouped under "containers" with the container type being : 'specimen'.

The decision is that multispecimen sheets are grouped under "containers" with the container type being : 'sheet'.

[FedorSteeman]

What about container name prefixes?

[jlegind]

Based on the visit to Priorparken and discussion with the digitizer staff, Bhupjit is convinced that the terms 'Multi specimen object' and 'multi object specimen' are too confusing for the digitizers. The suggested replacements are 'multiple specimens on one object' and 'one specimen on multiple objects'.

[jlegind]

The radio buttons are now implemented and the containerID (multispecimen) are prefixed with the containerType.

[jlegind]

The 'Warning sound' option is not fit for purpose IMHO. It requires that the workstation has a built in speaker system AND that the sound is turned on. I believe the #274 ticket takes care of the multi specimen active problem.

[jlegind]

If a warning sound is required, then this code snippet might come in handy:

import winsound

frequency = 2500  # Set Frequency To 2500 Hertz
duration = 1000  # Set Duration To 1000 ms == 1 second
winsound.Beep(frequency, duration)