Location input should allow to manually extends the address

[TheSlimvReal]

The location input only allows to select an existing address.

Sometimes it might be necessary to extend this address with additional information (while still keeping the coordinates) e.g. to save street number 6b instead of just 6.

---

Als Projektkoordinator:in muss ich manchmal Zusatzinformationen zu einer Adresse angeben oder eine Haus-/Wohnungsnummer speichern, die nicht im offiziellen Adress-Register vorhanden ist (das für die Kartenfunktion abgefragt wird).

To implement:

• UI for address field type, so that there always is an option to write additional address details of any text (while only configuring this single field)
• Import module saves the exact address string imported in the extra details, even if the address cannot be found and mapped on the location API. (currently invalid address details are not imported at all)

[sleidig]

We would need to store (and display) an "extraAddress" text in addition to the lookup GeoResult. This leads to a number of variations to consider regarding UX. We might either display two form fields or smartly combine things into one (if we can figure out a good way for that).

User stories & edge cases (assuming two strings: address and extraAddress):

• [x] address = lookup location (existing cases to set / edit); no additional extra_address defined
• [ ] set extraAddress to non-existing location
• [ ] edit extraAddress from non-existing to existing location
• [ ] edit address from existing location to non-existing location

---

The easiest implementation would be to just have an independent additional text field:

Address: ..address.. [map icon] Additional address details: ..extraAddress.. [?]

[?] tooltip --> Make sure to enter and select the full address in the field above. The additional details can hold details like apartment number or navigation instructions but will not update the map visualization or the address field.

[sleidig]

This has similarities to adding an "other" text input for configurable-enum (dropdown) fields: #1677 Maybe we can design a generic approach covering both.

[aam-digital-ci]

:tada: This issue has been resolved in version 3.38.3-master.4 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket:

[aam-digital-ci]

:tada: This issue has been resolved in version 3.39.0 :tada:

The release is available on GitHub release

Your semantic-release bot :package::rocket: