JCU/feat(access-status): show the embargo label on files and access statuses in result lists

[Kasinhou]

An anonymous visitor looking at an embargoed file in the Item View gets a lock icon and no reason
for it — no date, no label. And the search and browse lists say nothing about access at all. Both
labels exist in DSpace and the backend already serves the data; the frontend just never turned them
on for JCU.

Two flags, both false in src/config/default-app-config.ts, neither of them set in
config/config.yml:

Flag	Where it shows
item.bitstream.showAccessStatuses	per-file label in the Item View — Embargo until <date>
item.showAccessStatuses	per-item badge in search / browse / recent items — Open Access, Embargo, Restricted, Metadata only

Why nothing was shown

AccessStatusBadgeComponent returns before rendering anything unless the flag is on:

private handleBitstream() {
  this.showAccessStatus = environment.item.bitstream.showAccessStatuses;
  if (!this.showAccessStatus) {
    // Do not show the badge if the feature is inactive.
    return;
  }
  ...

/assets/config.json on the JCU stack served:

"item": { "showAccessStatuses": false, "bitstream": { "pageSize": 5, "showAccessStatuses": false } }

Nothing else was missing. The backend endpoints
(/server/api/core/{items,bitstreams}/<uuid>/accessStatus, ItemAccessStatusLinkRepository /
BitstreamAccessStatusLinkRepository) answer correctly, and the frontend fails closed if they do
not — so this is a config change only.

Verified

Local Docker DSpace 9.3 with the JCU configuration. Test item with two files in ORIGINAL:
verejny-dokument.pdf (inherited anonymous READ) and embargovana-priloha.pdf (anonymous READ with
startDate = 2030-01-01). REST agrees the file is embargoed for an anonymous caller, before and
after this PR:

GET /core/bitstreams/e144905d-…/accessStatus   ->  {"status":"embargo","embargoDate":"2030-01-01"}

Item View, anonymous:

	Files section
before	verejny-dokument.pdf (74 B) / 🔒 embargovana-priloha.pdf (74 B)
after	verejny-dokument.pdf (74 B) / Embargo until 2030-01-01 🔒 embargovana-priloha.pdf (74 B)

Search / browse / home, anonymous — .access-status-list-element-badge on each page goes from
0 → 4 (one per item), reading Item Metadata only for the records with no files and
Item Embargo for the test item once its primary bitstream is the embargoed one. Switch the
primary bitstream back to the open file and the same item reads Open Access, which is the
documented behaviour — the item-level status comes from the primary bitstream, or the first one in
ORIGINAL if none is primary.

In both cases the visible text is preceded by an sr-only Access status:, so screen readers get
Access status: Embargo until 2030-01-01 rather than a bare date.

Cost: no extra requests

Both call sites already ask for the data whether or not a badge is rendered —
FileSectionComponent.findAllByItemAndBundleName(..., followLink('accessStatus')) and
SearchComponent, which appends followLink('accessStatus') when the flag is on. Counted on the
wire, the status arrives embedded in requests that were being made anyway, and there are zero
standalone /accessStatus calls on either page:

/core/bundles/09dbb341-…/bitstreams?page=0&size=5&embed=accessStatus
/discover/search/objects?sort=score,DESC&page=0&size=10&embed=thumbnail&embed=item%2Fthumbnail&embed=accessStatus

Two things worth knowing before this hits production data

A file that is merely restricted still shows no label in the Item View. The component renders one
only when there is a date:

this.accessStatus$ = this.embargoDate$.pipe(
  map(date => hasValue(date) ? 'embargo.listelement.badge' : null),
);

So restricted — a READ policy with no start date, or no anonymous READ at all — produces the lock
icon and nothing else. Only a genuine embargo, a future policy start date, produces the label. (The
item-level badge in the result lists does have a Restricted state; the per-file one does not.)

Every record without files gets a Metadata only badge in the result lists. That is accurate,
but on a repository where metadata-only records are common it is a lot of new badges — worth a look
at the real data before merging.

Related

dataquest-dev/DSpace#1394 — backend companion. With access.status.for-user.bitstream = current in
dspace.cfg, the status is computed for the current user, so an administrator, who can read the
file, is told open.access and sees no label. That PR switches it to anonymous so the label
describes the file rather than the viewer.

Same flags as ZCU (#1403 / #1404, bitstream only) and MENDELU (#1243, both).

How to see it

1. Item View of an item with an embargoed file, and /search, logged out.
2. <host>/assets/config.json must show both flags true — the file is read at UI startup, so
   restart the UI after deploying, and check that no mounted config.prod.yml or
   DSPACE_ITEM_SHOWACCESSSTATUSES / DSPACE_ITEM_BITSTREAM_SHOWACCESSSTATUSES env var overrides
   it.

🤖 Generated with Claude Code

[Copilot]

Pull request overview

Enables the existing access-status UI features for the JCU deployment by turning on the two configuration flags that gate rendering of access status labels/badges (item-level in lists and bitstream-level in the Item View).

Changes:

• Enable per-item access status badges in search/browse/recent-items via item.showAccessStatuses: true.
• Enable per-bitstream access status labels in the Item View via item.bitstream.showAccessStatuses: true.
• Add inline config comments documenting where each flag is surfaced and the related REST endpoints.

---

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