Automatically assign sample ids

[ljones37oet]

Uses an auto action to automatically assign the next available sample ID to sample events.

When a SAMPLE* event is submitted with the SAMPLEID* value "auto"*, the auto action retrieves the last 5* sample events for the cruise and find the maximum sample ID value. It then updates the sample ID of the event to this maximum + 1. You can't just check the most recent sample event because that will usually be the empty event created when you click an event button. Checking multiple events also allows for the case where multiple people are logging samples at the same time, though it is important to note that IDs are assigned in the order that events are submitted, not in the order that they are created.
* customizable

How to implement:

1. In Sealog, create (or update) a sample event template with a required sample ID option with the default value set to "auto"*. This should probably be of the text (if you want people to be able to manually edit if needed) or static text type
2. Copy over the new code from misc\sealog_auto_actions.py.dist into misc\sealog_auto_actions.py
3. Update the "For automated sample IDs" config section at the top of the file. At the very least, people will need to update the PATTERN_SAMPLE_ID, unless for some reason their cruise IDs also start with "NA"
4. Run the test\misc\test_sealog_auto_actions.py unit tests to check that most of your config is ok
5. Restart the auto_actions service and try submitting a sample event to confirm that your template and your config are aligned

Notes:

• I'm not sure if this will be helpful to other ships or if they already have sample IDs automated, but I thought I would push it just in case. Prior to this change, we were keeping track of sample IDs on a whiteboard and manually typing them in for each sample event.
• It is not ideal that the ID doesn't get filled out until after you submit the event, but this was the simplest method I could think of to automate sample IDs and seemed to fit in best with the existing framework. There are a lot of different ways to solve this problem
• Since there aren't any python unit tests in this repo, I tried to make the ones I added similar to the OpenRVDAS ones

Preview:
Event template example:

After submitting event:

[webbpinner]

This has been a feature request for some time and I've been debating how best to implement it. Most of the groups requesting this feature would like to see the field populated with the suggested next ID number and have the option to change it prior to submission.

I like what you've come up with but I think my preference is to implemented this within the HAPI server routes. My current thoughts are to add several new parameters to event template event_options such as:

• regex validation (similar to cruise/lowering id)
• placeholder text
• auto increment syntax
• auto increment reset (by cruise, by lowering or never)

In the case of auto increment, the most recent use of the event_option would be saved back to the event_template record. When the event is triggered the value is incremented (and saved) as it is pushed to the client. When the event is submitted the templates uid will be included in the API call. If the template matching the uid has auto-incremented event_option fields then the auto-incremented value(s) submitted with the event are saved back to the template record as the last value used.

I'm hoping that with this approach the user will see the auto-incremented ID when submitting the event and have the option to manually override it. It should also gracefully handle rapid use of the template, i.e. 3 people click it in rapid succession. In this case each template click will generate an incremented value.

It's certainly not fool-proof but I'm hopeful it will meet most of the user's needs.

As for extending the python_sealog wrapper... I see no issue with those changes.

[ljones37oet]

@webbpinner thanks for reviewing!

That sounds good to me! I agree that it would be better to be able to see/edit the automated ID before you submit the event. We tested this on the last dive of the cruise that I was on in July, and it worked fine. The Nautilus will be sampling again in another week or two, so we're going to do some more user testing.

A downside with assigning IDs before submission is that you would end up in a gap in the IDs if two people had the sample event modal open at the same time (e.g. they both went to log the same event) and the person who clicked first canceled. The person who does end up submitting the event would just need to know that they have to manually set the value.

Another reason I did it this way is that there were no js changes that had to be compiled. Our internet in the middle of the ocean is too slow to update npm packages without a lot of hassle, so we don't really want to pull in client-side changes from github during the season. If the change were ready by the late fall, we could implement it while the ship is in port.

[webbpinner]

There will always be edge-cases but I think a gap is preferred to a malformed IDs or worse, duplicates.

Implementing this the way I described is going to take awhile so I think the auto_action approach in the short-term was the best approach.