data entry collection-specific requirements

[dustymc]

Ok, to solve one problem (and other similar attributes being accidentally
forgotten problems) how about in the customization of data entry tools we
have the option to make some fields required? So they would fail data entry
checks if forgotten?

This won't solve the problem of someone accidentally typing different
values in the individual count attribute field from the whole organism part
field but it will at least make it impossible for one of my techs to forget
to fill in the attribute individual count value.

-Derek

Originally posted by @DerekSikes in #4382 (comment)

[dustymc]

Splitting this off for its own discussion.

customization of data entry tools

Maybe, but I can't quite (yet, I hope) envision a mechanism for that. Maybe #4361 will reveal something.

fail data entry checks if forgotten

That seems actionable - each collection could require (sex, coordinates, whatever) in some way the checker could access. I think I could actually hard code that for now - I can check into that if you're sure it's an all-time rule - but ideally/eventually we'd find a way to put that in the UI (with manage collection, maybe).

[dustymc]

AWG:

needs more discussion

maybe: make actual required very minimal, let UIs reflect that, implement this to allow collections to require (by failing validation) whatever they want

[dustymc]

There's now a stable target. I still don't know what an eventual UI might look like, but if anyone wants collection-specific entry requirements post them here and I'll add to the checker.

This should be tabled if there are no requests in ~a month.

[DerekSikes]

For UAM:Ento it would be good to require attribute -> life stage and individual count

[dustymc]

require attribute -> life stage and individual count

That's probably not impossible, but it would be tricky - can those be required in specific places, eg

• attribute_1_type==onething and attribute_1_value not null
• attribute_2_type==onething and attribute_2_value not null

??

[DerekSikes]

Yes, & I don't care which are attribute 1 or 2 - and in fact, it would be nice if the same attribute type could ALWAYS be #1, 2 etc. so we don't end up with attribute 1 being 'life stage' for some records and being 'individual count' for others. Checking over records in the bulkloader is made much harder by this weird inconsistency.

[dustymc]

same attribute type could ALWAYS be ...

I don't think there's any way that can scale, but I can definitely set it up for specific collections. (Sorta the theme of this Issue...)

Here's what's there now:

 attribute_1_type | attribute_2_type | attribute_3_type | attribute_4_type | attribute_5_type | attribute_6_type | attribute_7_type | attribute_8_type | attribute_9_type | attribute_10_type 
------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+------------------+-------------------
 individual count | age class        |                  |                  |                  |                  |                  |                  |                  | 
 age class        | individual count |                  |                  |                  |                  |                  |                  |                  | 
 age class        | individual count |                  |                  |                  |                  |                  |                  |                  | 
 age class        | sex              | individual count |                  |                  |                  |                  |                  |                  | 
 age class        | individual count | caste            |                  |                  |                  |                  |                  |                  | 
 individual count | age class        |                  |                  |                  |                  |                  |                  |                  | 
 individual count | age class        |                  |                  |                  |                  |                  |                  |                  | 

Whichever of those that aren't wherever they're supposed to be will cause load fails once this is implemented, pausing and loading everything (or downloading/massaging/implementing/reloading or whatever) might be worthwhile.

I suspect this is more complicated than it needs to be because https://github.com/ArctosDB/code-table-work/issues/62 has been dragging out for THREE YEARS now (and somehow https://arctos.database.museum/info/ctDocumentation.cfm?table=ctattribute_type#life_stage appeared?!) and - ugh.

ANYWAY - I think I can turn any sort of rules on at any time - this doesn't have to be a whole solution before we get started - just let me know when I can do something in some way that's not too disruptive.

[dustymc]

closing for lack of interest