[PER-10758] [Merge only if access role makes it on prod] Map the stela accessRole values to the old v1 shape

[aasandei-vsp]

Merge only if access role makes it on prod

Until we will be able to change all the mappings in the app to the new version from stela, we have to make sure that we make all stela properties backwards compatible, so the web-app does not break.

In the case of the accessRole, up until now, because it was omitted in the stela responses, it was always overriden by values from the old backend. But now, the accessRole comes back from stela as well, the web-app recognises the property, but it breaks because it does not recognise the value. Mapping it to the old version solves the issue.

Issue: PER-10758

Manual test cases

The change: the caller's role from Stela is now translated into the app's
access.role.* form instead of being passed through raw.

Warning

This affects permission-gated controls across the whole file browser, not just one
screen — 12 code paths feed the two converters that changed. Any earlier test plan
that recorded a missing action button as expected behaviour needs re-running.

---

The reported bug ⭐

(this is the symptom that prompted the change — run it first)

Scenario — upload and create stay enabled

1. Go to /private and enter a folder that has no display date set.
   • EXPECTED: The folder contents load.
2. Click empty space in the file list to clear any selection.
   • EXPECTED: The sidebar shows the current folder's info.
3. Look at the Upload button and the Create Folder action.
   • EXPECTED: Both are enabled. Before this change they intermittently went
     disabled together at exactly this point.
4. Navigate out to /private and back into the same folder, then clear the selection again.
   • EXPECTED: Still both enabled, repeatedly.

---

Owner keeps every action

Scenario — folder and record actions

1. In /private, click on a folder
   • EXPECTED: Rename, Copy, Move, Share, Publish and Delete
     are all present.
2. Click on a record row.
   • EXPECTED: The same write actions, plus Download.
3. Select a single item and check the sidebar actions.
   • EXPECTED: Edit and share actions available.

Scenario — after a refresh cycle

1. Rename a record, click outside, click the record again
   • EXPECTED: All write actions still present.
2. Upload a file, wait for the list to update, then click the newly added row.
   • EXPECTED: All write actions still present.

---

Roles other than owner ⭐

Scenario — viewer stays restricted

1. Sign in as the second account and open the folder shared to it as Viewer.
2. Click an item inside the folder.
   • EXPECTED: Rename and Delete are not offered.
3. Try to upload into that folder.
   • EXPECTED: Upload is unavailable.

Scenario — curator enables functionality

1. Open a folder shared to the second account as Curator.
2. Click a row and check the top actions
   • EXPECTED: Curator-level actions are available — the account is not treated as anything lower.

---

Newly reached: anonymous and public access

Scenario — logged-out share link

1. Open an unlisted share link to a folder while logged out.
   • EXPECTED: The folder and its contents render.

Scenario — public archive(cannot test on local, need to see if I can test on dev)

1. Open a public archive page while logged out and browse into a folder.
   • EXPECTED: Contents render, no write actions, no console errors.

---

Scenario — share dialog

1. As the owner, open the share dialog on a folder already shared with another archive.
   • EXPECTED: The other archive's role displays correctly. This is a different field
     and its mapping is unchanged.

Scenario — archive-level permissions

1. Open archive settings and member management.
   • EXPECTED: Unchanged. Archive role still comes from the legacy endpoints.

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 52.36%. Comparing base (8295f4c) to head (f6a62ae).

Additional details and impacted files

@@            Coverage Diff             @@
##             main    #1139      +/-   ##
==========================================
+ Coverage   52.30%   52.36%   +0.06%     
==========================================
  Files         355      355              
  Lines       12108    12114       +6     
  Branches     2189     2191       +2     
==========================================
+ Hits         6333     6344      +11     
+ Misses       5547     5542       -5     
  Partials      228      228              

☔ 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.

[slifty]

Code looks good -- let's get claude to stop commenting so much; we should generally try to write self-documenting code and use commit messages if needed.

If something truly needs a comment then it probably needs to have a better name or a function with a better name + a docblock!

[Copilot]

Pull request overview

This PR restores backwards compatibility for Stela’s newly-populated accessRole by translating Stela’s role vocabulary (e.g., "owner", "manager") into the web-app’s existing AccessRoleType strings (e.g., "access.role.owner"), preventing permission-gated UI from breaking across the file browser.

Changes:

• Introduces ArchiveMembershipRoleType plus a dedicated translation map/function to convert Stela roles into AccessRoleType.
• Updates Stela folder/record converters to translate accessRole instead of passing the raw Stela value through.
• Adds unit coverage for the new translation behavior in model, folder repo, and record repo specs.

Reviewed changes

Copilot reviewed 6 out of 6 changed files in this pull request and generated 3 comments.

Show a summary per file

File	Description
src/app/shared/services/api/record.repo.ts	Translates Stela record accessRole to legacy AccessRoleType during conversion.
src/app/shared/services/api/record.repo.spec.ts	Adds tests to verify record role translation and merge/update behavior.
src/app/shared/services/api/folder.repo.ts	Translates Stela folder accessRole to legacy AccessRoleType during conversion (including children).
src/app/shared/services/api/folder.repo.spec.ts	Adds tests to verify folder role translation and regression coverage for updates/children.
src/app/models/access-role.ts	Adds Stela-role type and translation map/function into app roles.
src/app/models/access-role.spec.ts	Adds unit tests ensuring translation coverage and compatibility with getAccessAsEnum.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[aasandei-vsp]

Code looks good -- let's get claude to stop commenting so much; we should generally try to write self-documenting code and use commit messages if needed.

If something truly needs a comment then it probably needs to have a better name or a function with a better name + a docblock!

Totally agree with that. Will add a rule to make sure we only add comments that are truly needed from now on.

[omnignorant]

Upload and Create Folder no longer stay disabled after repeat navigation (the reported bug), and role-gated permissions hold correctly for Viewer (Download only) and Curator (matches owner-level file actions, but not Share/Publish). Owner permissions were also confirmed unaffected on both a folder and a record selection. I didn't get to the anonymous/logged-out scenarios (share links, public archive) but I think risk to unauthenticated share behavior looks low. Approving.