Feature Request - Batch update for "dates: collecting vs. collector"

[wellerjes]

Issue Documentation is http://handbook.arctosdb.org/how_to/How-to-Use-Issues-in-Arctos.html

Is your feature request related to a problem? Please describe.
Now that our agent records have been flushed out, we are seeing a lot more records that have dates out of range in "dates: collecting vs. collector". There's a way to batch update agents; is there a way to batch update the dates of specimen records? If not, is this tool feasible?

Describe what you're trying to accomplish

These records did not have precise dates when entered into Arctos, because we did not have information about the collector. Now that the agent record has been updated, we now have a smaller range of dates in which the specimens could have been collected. Rather than updating 63 individual specimen records (just for this agent), I would like to be able to batch edit them.

Describe the solution you'd like
A batch editor, similar to https://handbook.arctosdb.org/how_to/How-to-Batch-Update-Agents.html

Describe alternatives you've considered
Use the Transarctos Unified Reporting Directive to identify each catalog record and update it individually.

Additional context
Add any other context or screenshots about the feature request here.

Priority
Please assign a priority-label. Unprioritized issues gets sent into a black hole of despair.

[dustymc]

I don't think this is an agent-problem.

The event (especially a "before now" event) might be attached to lots of records this update wouldn't change, in addition to the one or more than it would. I think this would therefore be a matter of cloning the event, changing the dates, and then swapping the specimen-event to use the newly-made collecting event. (Then waiting for the Arctos merger to eventually put any duplicates back together.) Some records might have many specimen-events, only one (at a time, at least) of which would need to change for this sort of update. Therefore I'm not sure that this is possible without some sort of exposed specimen_event_id.

Please let me know what I'm not understanding, if there's some better path I haven't seen, etc.

I'm not sure that ID would need to be particularly stable - partID isn't and AFAIK has been working well enough - but if there's some use case for that, now's the time to spell it out.

#5497 should be entirely addressed first - I don't want some great new things to live only long enough for everyone to learn it.

[dustymc]

merge-->#7419