Use new location metadata fields

[slifty]

This PR modifies the web app to use the new location metadata fields for both reading and writing data.

Resolves #1001

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 52.08%. Comparing base (44e1116) to head (695534e).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1002      +/-   ##
==========================================
+ Coverage   51.60%   52.08%   +0.47%     
==========================================
  Files         354      354              
  Lines       12067    12085      +18     
  Branches     2172     2181       +9     
==========================================
+ Hits         6227     6294      +67     
+ Misses       5613     5561      -52     
- Partials      227      230       +3     

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[Copilot]

Pull request overview

Updates the Angular web app’s location handling to support newly introduced location metadata fields (e.g., name/sublocation/city and role/precision/raw metadata), aligning the UI formatting and client-side models with the updated location schema.

Changes:

• Extend location DTO/model types with new metadata fields (name, sublocation, city, altitudeMeters, role/precision/raw metadata).
• Map Stela location fields into the app’s LocnVOData shape, including renaming role/precision/raw to locationRole/locationPrecision/rawMetadata.
• Prefer new location fields when rendering location display strings and when creating locations from Google Places.

Reviewed changes

Copilot reviewed 4 out of 4 changed files in this pull request and generated no comments.

File	Description
src/app/shared/services/api/record.repo.ts	Adds new Stela location fields and maps role/precision/raw into the app’s renamed metadata fields during conversion.
src/app/shared/pipes/pr-location.pipe.ts	Updates display formatting to prefer sublocation, city, and name when present.
src/app/models/locn-vo.ts	Extends LocnVOData with new location metadata fields used across the app.
src/app/file-browser/components/location-picker/location-picker.component.ts	Populates sublocation, city, and name when creating a location from a selected Google Place.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated 4 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[cecilia-donnelly]

I don't see anything obviously off here! I have some questions, likely answered by your partner PRs to this one, but wanted to ask them right away.

[aasandei-vsp]

LGTM, small observations.

[github-actions]

QA Instructions

QA Testing Instructions for PR: "Use new location metadata fields"

---

Summary

This PR updates the web app to use new location metadata fields (name, line1, line2, etc.) when reading and writing location data. It replaces the use of some older, deprecated fields with these updated fields across multiple UI components (file-viewer and location-picker) and modifications in their respective pipes and tests. The goal is to align the frontend with the backend's updated data structure and maintain data compatibility.

---

Test Environment Setup

1. Ensure that the application backend is running a version that supports the new location metadata fields.
2. Start the frontend application with this branch checked out and a typical dev configuration (e.g., using proxy.conf.dev.json for API redirection).
3. Confirm the dev environment is connected to a backend service with location-related data available.

---

Test Scenarios

1. File Viewer: Display Updated Location Details

   • Steps:
     1. Navigate to a record in the file viewer that has a LocnVO object with populated name, line1, and line2 fields.
     2. Confirm that the following fields appear in the location display:
        • name is displayed in bold.
        • line1 and line2 are shown on separate lines after name.
   • Expected Result:
     • The location is displayed correctly, reflecting the new fields: name (if provided), line1, and line2.
   • Edge Case Testing:
     • If line2 is missing, only line1 is displayed. No errors or empty <span> tags should appear.
     • If name is missing, it does not result in any visual errors; only line1 and line2 are shown.
     • If both line1 and line2 are undefined, ensure the placeholder text ("Click to add location") still appears.

2. File Viewer: Fallback Behavior When Location Data is Incomplete

   • Steps:
     1. Navigate to a record in the file viewer that has an incomplete or empty LocnVO object.
     2. Confirm that the placeholder text ("Click to add location") appears for missing data.
   • Expected Result:
     • The app defaults to the placeholder state without throwing errors in the console.

3. Location Picker: Display Location Metadata

   • Steps:
     1. Open the location-picker component and select a location with full location metadata (name, line1, line2, etc.).
     2. Observe that the location data is displayed accurately in the panel:
        • name appears first if available.
        • line1 and line2 are displayed as additional lines after name.
   • Expected Result:
     • Correct information is displayed as per the new metadata fields.

4. Location Picker: Editable Location Metadata

   • Steps:
     1. Open the location-picker editor for a location.
     2. Check that you can edit the name, line1, and line2 fields.
     3. Save the changes and confirm that the updated data is persisted correctly (this may need backend logs or API verification).
   • Expected Result:
     • The editable fields should save changes successfully, and the updated values should be displayed after the changes persist.

5. Behavior When Google Place Data Is Received

   • Steps:
     1. Interact with the location-related features where new location metadata is populated by Google Places (e.g., through the createLocnFromPlace method in LocationPickerComponent).
     2. Verify that location data is properly parsed and converted into the new fields (e.g., name, line1, line2, city, etc.), without populating older, deprecated fields (e.g., streetNumber or locality).
   • Expected Result:
     • Location metadata conforms to the backend specification: relevant fields like name and line1 are correctly populated, while deprecated fields remain null/blank.

6. Regression Testing:

   • Retest any other features that depend on location data across the app (e.g., other views leveraging prLocation pipe or location-picker).
   • Test adding, editing, and clearing out locations using the file-viewer and location-picker.

---

Regression Risks

• Components:

  • file-viewer.component.html
  • location-picker.component.html

  These components were updated to reference new location metadata fields. Ensure all scenarios related to these components continue to work as expected.

• Pipes:

  • Test the prLocation pipe thoroughly, as transformations rely on the new name, line1, and line2 fields from LocnVO. Ensure fallback behavior works correctly (returns null when LocnVO is absent or fields are empty).

---

Things to Watch For

• Null/Undefined Field Handling:

  • Ensure the app gracefully handles missing or incomplete LocnVO objects. Focus on ensuring there are no UI rendering issues or unexpected errors.

• Backward Compatibility:

  • Confirm that legacy fields (e.g., streetName, streetNumber, etc.) are not being referenced in the updated code.

• Cross-Browser/Responsive Testing:

  • Validate these changes in multiple browsers and screen sizes to ensure rendering of location metadata is consistent.

• Unit Tests:

  • Ensure newly introduced test cases (including the createLocnFromPlace test) pass and verify compatibility with the new location metadata fields. Monitor coverage for any untested edge cases.

---

By following these steps, you should sufficiently verify the correctness of the feature and its safe integration into the application. Be on the lookout for any context where the old fields might still have been referenced, and ensure data display remains user-friendly.

---

Generated by QA Instructions Action

[slifty]

In my own testing: I'd like to wait until the stela endpoints for location creation are live before moving the frontend to use the new properties.

[omnignorant]

Not 100% sure what I am testing or what the success condition should be, but I did my best to suss it out of the QA guide. The gist seems to be "does a location properly save using the current picker UI"

Location editing seems to work inconsistently. In the screen capture attached here, I seem to have determined the following:

• location seems to save on initial selection
• for records without existing location data, the changed metadata persists after a refresh;
• for records with existing location data, the metadata does not persist;
• location metadata in profile, both general and milestone persists.

Screen.Recording.2026-05-08.at.4.50.36.PM.mov

[slifty]

@omnignorant sorry for the confusion -- I pulled this off of the QA pile since we need to do some additional changes for everything to work as expected!

[slifty]

Before we merge this I want to re-check to ensure that records with legacy location metadata work as expected.

[aasandei-vsp]

Left a few comments, but overall looks good.

Checked all location instances that I know of(manual testing):

• Sidebar
• Archive settings --> Milestones --> Location
• Group info --> Location established
• Gallery --> current archive --> info

[cecilia-donnelly]

QA findings: mostly this looks good!

An actual bug reproduction recipe:

1. Choose a record with no location
2. Set the location to an actual street address (I used 1600 Pennsylvania Avenue South, Minneapolis, MN, USA) and save.
3. I refreshed; this might not be critical
4. Change the location to one without a street address. I used Colorado National Monument, Grand Junction, Colorado.
5. Refresh (this one is definitely necessary)
6. After refresh, observe that the street number and name are now the previous values, so in my example I see "1600 Pennsylvania Avenue South
   Grand Junction, Colorado"

Since location updates are broken altogether on main (PER-10630) this is definitely an improvement, but if we can fix it that would be ideal.

Probably related but not critical: If I search for Acadia National Park, the location that appears in the editing view (sidebar and full) is "ME, US, US"

I followed these tests, for posterity:

## Test 1 — Set a location on a file for the first time

1. Open the file browser and click on a single file that does not currently have a location set (the sidebar on the right should say "No location" or "Click to set location" next to "Location").
2. Click the "Location" row in the sidebar.
3. In the map dialog that opens, type a real address into the search box (e.g. your office address or a well-known landmark) and select it from the suggestions.
4. Confirm a pin drops on the map at the correct spot and a short address preview appears.
5. Click "Save".

**Expected result:** The dialog closes, and the sidebar now shows the address you picked next to "Location," along with a small map thumbnail.

---

## Test 2 — Set a location on a folder for the first time

1. Repeat Test 1, but select a folder instead of a file.

**Expected result:** Same as Test 1 — the folder's sidebar shows the new location and map thumbnail.

---

## Test 3 — Change an existing location

1. Select a file or folder that already has a location set (from Test 1 or 2).
2. Click the "Location" row again.
3. Search for and select a different address.
4. Click "Save".

**Expected result:** The sidebar updates to show the new address, not the old one.

---

## Test 4 — View a location in the full file details page

1. Double-click a file that has a location set to open its full details page.
2. Find the "Location" row in the details table.

**Expected result:** The same address and map thumbnail shown in the sidebar also appear here. Clicking it opens the same map dialog for editing.

---

## Test 5 — Cancel without saving

1. Select a file or folder with a known location already set.
2. Click "Location" to open the map dialog.
3. Search for and select a different address, but click "Cancel" instead of "Save."

**Expected result:** The dialog closes and the original location is unchanged — the new address you searched for was not saved.

---

## Test 6 — Set a location with limited address information

1. Select a file or folder without a location.
2. Open the location picker and search for a broad place name that doesn't have a specific street address (e.g. a city name or a large park/landmark rather than a full street address).
3. Select it and click "Save".

**Expected result:** A reasonable location still displays afterward (e.g. city and country, or coordinates) — it should not show blank, "undefined," or an error.

---

## Test 7 — Location persists after refresh

1. Set a location on a file (per Test 1) or use one already set.
2. Refresh the browser page, or navigate away to a different folder and then back.

**Expected result:** The location you set is still shown correctly — nothing reverts or disappears.

---

## Test 8 — No location set

1. Find or create a file/folder that has never had a location set.

**Expected result:** The sidebar and full details page clearly show "No location" or "Click to set location" (not blank, not an error, not leftover data from another item).

[slifty]

Apparently the way I was trying to update locations didn't align with the backend -- fixed that up so now we're properly creating a new location instead of trying to update an existing one (which in turn was triggering some location reprocessing in the PHP side).

I also made two other little changes:

1. Location name is now rendered in the detail view in a way that matches the map view (it's bolded / treated as a title). This is because sometimes the name is very similar to the sublocation and this helps convey the semantic role rather than looking like a duplication bug

2. I added some belt-and-suspenders support for legacy data since we won't be re-processing past location data for some time (once we do we'll consistently only have the new metadata fields, but for now we need the front end to gracefully fall back to the old values if new ones aren't present).

[cecilia-donnelly]

This looks great! Thanks for addressing my earlier comments, @slifty .

Many changes have happened since this review.