Herbarium form modal (reusable Location-creation UI)

[nimmolo]

• Generalize the "create Location" UI from the observation form so it can be used to create a location within any form that has location autocompletion. Trying it here on Fungarium first, because it's minor, so we can work out the bugs.
• Develop reusable Turbo methods to update the state of one form when another form is submitted. In this case, on successful creation of a Fungarium, Turbo populates the herbarium_record_herbarium_name and herbarium_record_herbarium_id fields of the create obs form from the Rails controller response, without writing JS (other than the reusable Turbo methods)
• Make the seldom-used "Create fungarium" link (in create obs) open a modal form, so it can be filled out right on the create obs page without interrupting flow. (I'm not sure how many people suddenly want to create a Fungarium when they're in the middle of recording an Observation... but that's what we offer)
• This is a test run for creating Locations from within the "Create Project" and "User Profile" forms

• Note here that the Fungarium form also must offer to "create a new Locality" in case your specimens are in a place we don't have. I considered yet another modal, but then settled upon generalizing the create-location UI. This PR adds the map/create-location UX to the Location autocompleter.

• [x] TODO: revert to MO Location autocompleter if "create" form text is blanked.
• [x] TODO: handle new location in Herbaria controller new/edit actions
• [x] TODO: system tests for the forms
  • [x] Regular herbarium new/edit, test that location is created when form submitted
  • [x] Observation new/edit, test that herbarium and location are created, and herbarium applied to observation herbarium_record

Successfully creating a Fungarium in the modal form now populates that new fungarium in the Observation form, and allows you to continue creating the obs.

Background: on the observation form, the "Create fungarium" link kind of interrupts the flow of creating an obs.

[coveralls]

coverage: 93.422% (-0.04%) from 93.46% when pulling 67b7a5d017f8517df37c3fed1c30bdd8b2231961 on herbarium-form-modal into 3b7e193bc94d76d2d4fad048bc30485dcdb49e83 on main.

[nimmolo]

@mo-nathan @JoeCohen Please take a minute to test this manually at two places:

• herbaria/new the usual place for creating a fungarium. The thing that needs testing is creating a new Location during the process of filling out the form.
• observations/new. If you click "has_specimen" you should see a link to "create fungarium" above the name of your default fungarium. This will open a pop-up modal form just like the above, where you should be able to
  • create a new location for a fungarium
  • create the fungarium
  • find the brand new fungarium filled in on the create obs form.

Fungaria is admittedly a minor use case, but I would like to roll this UI out also for Projects and User Profiles, potentially reducing a step in both of these forms.

[JoeCohen]

Very slick. Picks up lots of stuff automatically. Problem: clicking Create Locality does not create the Locality. So it gets stuck in the Create New Fungarium modal when trying to Create Locality while creating new Herbarium while creating an Obs. What I did:

• Create Observation
• Drag 2 photos (Love how this works with automatically getting the date & location.
• Folded Images + Details.
• In Identification + Specimen::
  • Filled in Scientific Name, selected Confidence, checked Specimen Available. Result: The section expanded.
  • Clicked Create New Fungarium. (I left the Fungarium Name ("Joseph D. Cohen personal herbarium") alone. I didn't fill in Collector's Number, Accession Number or Fungarium Record Notes.) Result: Opened Create New Fungarium modal. In that modal:
  • Filled in Name
  • Did NOT check personal fungarium box.
  • In Location, typed non-existent Location (McMinnville, Yamhill Co., Oregon, USA) Result: Create locality button appears. NIce! (Do you want to capitalize "locality"?)
  • Clicked Create locality Result: Map appears with correct bounding box. Create locality match found check icon appears. But the locality is not created. (I looked in the Rails console.)
  • Clicked Create button. Result: No visible change. (It now creates the Locality, without notifying user. It does not create the Herbarium.) What now? I'm apparently stuck in the Create New Fungarium modal, with no way out.

If I close the modal, click Create New Fungarium, I'm back to the modal, where click Create does nothing.

[nimmolo]

Joe, I heard about all that mushroom rustling up in McMinnville, and I put two and two together, and, well... this was the only way I knew to bring the suspect to justice.

I'm afraid you'll have to wait here in the modal until the sheriff comes.

[nimmolo]

Thanks Joe for all the feedback. I’m just trying out the flow you did, and i get a different result, when i click “Create” on the fungarium modal:

• A flash in the create obs form, with three success messages
• The new fungarium name now filled out in the form. (It should probably remove the “Create” button at this point, I’m realizing.)

[mo-nathan]

I spent a while on the Create Fungarium stuff inside the Create Observation stuff and my assessment is that it isn’t worth it. The use case I spent the most time on was creating an observation that I want to deposit at the MBLWHOI Library Herbarium (see https://mblwhoilibrary.org/special-collections/mblwhoi-library-herbarium/). The first issue I ran into is that it isn’t clear from the Create Observation UI whether the fungarium/herbarium even exists when I enter the name for it. Given that it doesn’t seem worth adding to the Create Observation workflow. Creating a fungarium should be a rare event. I don’t see the justification for making it really easy to do from the UI. Out of the 7477 herbaria in the system, only 1629 have any associated observations, and only 746 have more than one. Beyond that, the embedded location creation UI seems to be wonky. I can create this herbarium through the Create Fungaria UI and I can create the location itself through the create location UI. It’s only when it’s embedded in the Create Observation UI that it gets weird. I did a screen capture showing the weirdness and uploaded it through Slack since it's too big for GitHub.

[nimmolo]

I think i've resolved the Location-name-editing issue @mo-nathan discovered as well as we can.

In terms of Google Maps API's responses, our constraint here is that when we're geolocating a place name, Google only returns one (what they deem the “BEST MATCHING PLACE”) unless we use their Places API and spend an order of magnitude more credits per request.

With lat/lngs, the situation is different. Google freely returns an array of matching locations of descending specificity, and we sift through them to only show the types of locations we are interested in.

But when geolocating a place name, we don’t get any choice. If Google picks a street address, as it does when we enter

Data Library & Archives, McLean Laboratory, Woods Hole Oceanographic Institution Quissett Campus

and Google returns

360, Woods Hole Road, Woods Hole, Falmouth, Barnstable Co., Massachusetts, USA

all we can do is remove the street number component from the hash of address components. This will not change the bounding box, which is still that of the street number/address.

@mo-nathan I noticed incidentally that the mysterious number "1531" is also appended to the location if you try to geolocate "Quissett Campus" as an observation location on main, currently.

UPDATE It's the ZIP+4 code. Adding this to the list of keys ignored in recomposing addresses.

[nimmolo]

@mo-nathan @JoeCohen

I revised the PR description at the top with the actual priorities motivating all this work, and a description of what's reusable. Realized the original description overemphasized the fungarium creation aspect, which I agree is not very important or valuable.

[nimmolo]

Going to go ahead and merge this.