When editing an instance, use placement-map functionality for all geopoint variants

[lognaturel]

Description

When an existing instance is opened for editing, the editor needs to be able to view and manually move a previously-captured point on a map, no matter how that point was originally captured. In some cases, it might also be appropriate for them to capture their own current location. The desired functionality is equivalent to the placement-map appearance.

---

Checklist

• Does it need UI/UX design?
  • Yes. Describe the UI/UX requirements or attach a Figma link in the "Design" section.
  • No
• Does it need API design?
  • Yes. Specify the endpoints, methods, or data structures needed.
  • No
• Does it need design around state flow?
  • Yes. Outline the state flow requirements.
    Need to make a decision on when that case is identified and how it's communicated down (e.g. would manually forcing the placement-map appearance feel appropriate)
  • No
• Does it need a test plan?
  • Yes. Add the test plan as a comment in this task or attach the document.
  • No

---

User Stories

• As a project manager,
  I want view and edit any existing geopoint value on a map,
  so that I can make sense of and correct existing data.

---

Design

• Figma: [Insert URL]
• Design Docs: [Insert URL]

---

Dependencies

• Form filling: Geopoint with map #257

---

Additional Notes

---

Related Issues

• Form filling: Geopoint with no appearance #249

[lognaturel]

@alyblenkin @latin-panda I believe this one is ready. Will let you confirm and move over if you agree!

[latin-panda]

@lognaturel @alyblenkin
This refers to the scenario where a project manager locates an existing submission and chooses to edit it using Web Forms.

What about when creating a new submission where:

• A geopoint question with no appearance (default) or with a maps appearance has a default value, or a value set by a calculation, and the user wants to edit that value?
  • For instance, imagine a house assessment form being filled out in the field (on mobile) or in a nursery (on desktop), where fields are prefilled with entity data (e.g., patient's house or the user's associated health center), but the user wants to update a point on the map (because they moved houses or relocated to a new center).

In these cases, will the geopoint use the placement-map experience, or revert to the original behavior (default for no appearance, or maps for the maps appearance, respectively)?

Another scenario, if the user is creating a new submission but navigates back to edit a previous answer, will the geopoint use the placement-map experience, or revert to the original behavior (default for no appearance, or maps for the maps appearance, respectively)?

Are there any other scenarios not mentioned here for editing the answer?

[lognaturel]

This refers to the scenario where a project manager locates an existing submission and chooses to edit it using Web Forms.

Yes, exactly!

A geopoint question with no appearance (default) or with a maps appearance has a default value, or a value set by a calculation, and the user wants to edit that value?

Then the only way they can edit the value is by capturing their device location. If the form designer wants a map-based update like you describe, they need to use the placement-map appearance. What we sometimes see users do as well is have a question like "are you at the location now" and then show different geopoint appearances accordingly (separate questions with relevance).

navigates back to edit a previous answer, will the geopoint use the placement-map experience, or revert to the original behavior (default for no appearance, or maps for the maps appearance, respectively)?

It does not use the placement-map experience. If the user is in a form-filling session, the geopoint uses the appearance set in the form definition. So if you have a geopoint with no appearance, it is only ever possible to capture device location without an interactive map.

Are there any other scenarios not mentioned here for editing the answer?

I think you got all! There's one more case we might introduce one day -- opening an existing instance with some data filled in to fill out the rest of the form fields. So there's existing data but the instance is opened for filling, not for editing. If I recall correctly there's some kind of mode constant that is set when creating the top-level component that indicates that an instance is being opened for editing.