Use stela endpoints for getRecord

[slifty]

This PR updates our getRecord call to use stela. This improvement is necessary to support unlisted share functionality, which only exists on stela.

This PR represents a modest refactor from the one opened at #630; the primary difference is that we re-package v2 results so that the object returned is the same type as before (e.g. a RecordResponse vs a RecordVO). This should prevent the need to refactor our components to have v1 and v2 versions as part of the unlisted shares improvements.

Related to #683

[codecov]

Codecov Report

❌ Patch coverage is 63.33333% with 11 lines in your changes missing coverage. Please review.
✅ Project coverage is 45.16%. Comparing base (27e2042) to head (685be13).
⚠️ Report is 9 commits behind head on main.

Files with missing lines	Patch %	Lines
src/app/shared/services/api/record.repo.ts	63.33%	6 Missing and 5 partials ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #669      +/-   ##
==========================================
+ Coverage   45.14%   45.16%   +0.02%     
==========================================
  Files         370      370              
  Lines       11256    11284      +28     
  Branches     1855     1860       +5     
==========================================
+ Hits         5081     5096      +15     
- Misses       6006     6012       +6     
- Partials      169      176       +7     

☔ View full report in Codecov by Sentry.
📢 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.

[cecilia-donnelly]

Very exciting! I was able to share a file and create a share link, and the site worked as expected, so it looks like this is working. Google Maps didn't load locally, but I suspect that's a local environment problem.

[slifty]

@cecilia-donnelly I'm doing some local QA and saw keywords acting funny -- going to go through with a fine-toothed-comb to see what similar "mocking" needs to be done to turn StelaRecords to RecordVos but overall the approach is still gonna be great

[slifty]

@cecilia-donnelly ready for a re-review!

[slifty]

It looks like tests may be actually failing! Taking a look now.

This needs to be reviewed/QA'd more deeply.

[slifty]

Fixed the tests (I had to update the test fixture response to reflect stela return format).

I also fixed some leaking tests while I was in the area, and added that as another commit.

[cecilia-donnelly]

We talked about this a little bit elsewhere, but to recap here:

• Tags are not appearing specifically in the side/detail view on the file list (what you see when you single click an item in a workspace)

The other problems I saw resolved, so were likely related to queuing. I focused on QA-ing folder and record actions, so only lightly touched account, archive, and billing related aspects of the app. It's always possible that those are related in arcane ways, but seems less likely.

Here is my QA notes doc (sorry, not public): https://docs.google.com/document/d/1khJX_VNwCcES9dGHXDRwIsUXcnW06_uIuXi7L6oTrRM/edit?tab=t.0

[slifty]

I'll be adjusting this PR to use stela for both of these endpoints (rather than just record).

I'm also going to split each migration to a separate commit.

[cecilia-donnelly]

QA finding on dev: a subtle confusion in the custom metadata. We can look at this together, but here's what I see:

1. On a record, open the side detail view with a single click
2. Under "Custom Metadata," click the "Click to add" and add a "field:value" (e.g. color:orange)
3. See that the metadata is populated (yay!) but only with the "value"
4. Refresh the page
5. Open the "Manage Custom Metadata" modal in Archive Settings (or from the detail sidebar)
6. See that the fields and values are populated correctly (also yay)

So I think everything is working fine, but the display is not showing the "field" part of the "field:value" pair. This is true in both the detail sidebar and the full page view.

Let me know if this makes sense.

[cecilia-donnelly]

Okay, another tiny thing but it feels like we're getting to the end of it!

1. Click into the side detail view for a record
2. Click into "custom metadata"
3. Choose an existing field:value pair from the dropdown (I think this happens with new ones too though ETA: it does not)
4. See that the metadata is applied and appears correctly, and that the dropdown stays open (as it should) and the selected metadata tag now shows up twice in that dropdown

The double tag persists through refresh but it (correctly) cannot be added to the record, so far as I can tell.

[slifty]

OK! I think that last bug was because stela returns tag id as a string, but PHP returns it as a number -- this means if there are interfaces that are combining some tags that were loaded by PHP endpoints + this record's tags it will treat them as two distinct tags!

Added a type cast so stela tag IDs are converted to numbers.

[cecilia-donnelly]

Can confirm that the last problem I found is fixed!

[liam-lloyd]

I found a handful of IDs that are numbers here but strings in stela

[slifty]

@slifty given that you gave this a pretty deep QA do you think could count as QA from a process PoV?

[cecilia-donnelly]

I went through my QA list again in full in @omnignorant's absence.

The only QA problem I have may or may not be related to these changes, but when trying to open a link to a public item, I am consistently redirected to the public gallery main page.

To reproduce:

1. Log in to an archive with one or more public items.
2. Select an item and click "Get Link" at the top menu.
3. Choose "View on web" and notice that the app cycles indefinitely. Alternatively, copy the link and open it in a new tab. See that you are redirected to the public gallery main page.

This might just be a dev problem with redirection in general, but it is not happening on staging (or prod).

[slifty]

Strange... Public urls works locally (I had tested it / had to make some fixes to support it) but not in dev.

I'm going to dig in more closely now to see what might be going on.

[slifty]

Fixed up (the issue was that my Stela type didn't account for the fact that tags can be null.)

Time for a new round of QA! Going through the document.

[cecilia-donnelly]

Thanks @slifty !