ZCU-PUB/Show a per-bitstream embargo-date badge in the Item View

[MatusBeke]

Problem

The bitstream download link in the Item View gives no indication when a restricted file's embargo lifts. Fixes dataquest-dev/dspace-customers#823 (the ZCU-PUB bitstream portion; ZCU-DATA needs separate work - its file listing goes through a completely different, CLARIN-specific component that doesn't reuse file-download-link at all, tracked separately).

Root cause

This feature already exists in vanilla DSpace and on this fork's DSpace 9.x lines (e.g. customer/mendelu), but was never ported to the 7.x line customer/zcu-pub is on.

History note (why this branch was rebuilt)

Earlier revisions of this PR shipped two things that turned out to be wrong and have been corrected:

1. An item-level dc.description.embargo/dc.date.embargoend metadata display - wrong data source (item metadata instead of the bitstream's actual resource policy) and wrong granularity. Reverted.
2. A standalone EmbargoBadgeComponent, copied from upstream commit 5f83139 (PR dataquest-dev/dspace-angular#3882, Jan 2025) - but vanilla abandoned that design; stable 9.3/main/customer/mendelu use a unified AccessStatusBadgeComponent that handles both Item and Bitstream. The standalone component also had a real bug: it read bitstream._links.accessStatus.href synchronously, which throws an uncaught TypeError on any backend that doesn't yet expose that link (i.e. this one, until MENDELU/Fix header/nav widget shift on SSR->CSR hydration #1377 below deploys) - catchError never got a chance to catch it because the throw happened before the Observable pipe was constructed.

This branch has been rebuilt from scratch off customer/zcu-pub to fix both issues and to split out an unrelated accessibility fix (aria-label/role/sr-only on the lock icon, previously bundled into this same branch) into its own PR: #1390. The old Copilot review threads on this PR no longer match the current diff - the underlying commits they were reviewing were replaced by this rebuild.

Change set (current, correct version)

Aligned with customer/mendelu's existing implementation:

• Bitstream model gains an accessStatus HAL link (same shape as the existing thumbnail/format links).
• AccessStatusObject gains embargoDate.
• AccessStatusBadgeComponent's object input widens from Item to Item | Bitstream; it resolves the accessStatus link lazily via LinkService.resolveLink(..., followLink('accessStatus', { isOptional: true })) instead of eagerly reading _links.accessStatus.href. The isOptional: true is required here specifically (mendelu's own code doesn't need it, because mendelu's 9.x backend already always has the link) - without it, resolveLink() throws for every bitstream on this backend today.
• file-download-link.component.html renders <ds-themed-access-status-badge [object]="bitstream">, gated by item.bitstream.showAccessStatuses.
• That flag now defaults to false (matching upstream/mendelu), not true - flip it only once the backend companion PR is deployed.
• i18n copy matches vanilla/mendelu exactly: "Embargo until {{ date }}" (en) / "Embargo do {{ date }}" (cs).
• Deleted the standalone EmbargoBadgeComponent/ThemedEmbargoBadgeComponent and the now-unused findBitstreamAccessStatusFor().

Backend dependency

Needs a companion REST endpoint - GET /bitstreams/{id}/accessStatus returning {status, embargoDate} - which doesn't exist yet on customer/zcu-pub. That's dataquest-dev/DSpace#1377. This frontend PR does not crash without it: with the flag at its default false the badge never runs at all; even if the flag were flipped early, the lazy+optional link resolution fails closed (verified below).

Test evidence

npx ng lint --quiet                       -> All files pass linting.
npx ng build --configuration production   -> build succeeded, no budget warnings
npx ng test (access-status-badge.component.spec.ts, file-download-link.component.spec.ts,
             thumbnail.component.spec.ts)
                                           -> 39/39 SUCCESS

Includes a new regression test for the exact crash this PR fixes: constructs a real Bitstream with no accessStatus in _links, asserts ngOnInit doesn't throw, the file list renders, and no badge appears.

Manual verification against a live local Docker stack running the current (pre-#1377) customer-zcu-pub backend image, with showAccessStatuses temporarily forced to true:

• Embargoed item's file list rendered normally, zero console errors.
• No accessStatus network request was even attempted - LinkService detects the missing _links key and returns EMPTY before making a call.
• (Item without an embargo, and the accessibility-only concerns, are covered by unit tests and PR ZCU-PUB/Add accessible labels to the restricted-bitstream lock icon #1390 respectively.)

Risk & rollback

Low risk, fails closed by construction (see above). Revert is a straight git revert.

Notes / assumptions

• Companion backend PR: ZCU-PUB/Add bitstream-level access status/embargo date REST endpoint DSpace#1377.
• Companion accessibility PR (split out of this branch's earlier history): ZCU-PUB/Add accessible labels to the restricted-bitstream lock icon #1390.
• ZCU-DATA needs its own implementation (different file-listing component entirely) - not covered here, tracked as a follow-up on dataquest-dev/dspace-customers#823.

[coderabbitai]

Important

Review skipped

Auto reviews are disabled on base/target branches other than the default branch.

Please check the settings in the CodeRabbit UI or the .coderabbit.yaml file in this repository. To trigger a single review, invoke the @coderabbitai review command.

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: c025dacc-06ea-402e-9a47-f8ef5249785a

You can disable this status message by setting the reviews.review_status to false in the CodeRabbit configuration file.

Use the checkbox below for a quick retry:

• 🔍 Trigger review

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Copilot]

Pull request overview

Improves Item View bitstream download accessibility by adding descriptive accessible labels for restricted/embargoed bitstreams and introducing i18n keys for those labels.

Changes:

• Adds an aria-label to the bitstream download link that includes the bitstream name.
• Adds an accessible restricted-state label for the lock icon.
• Adds i18n keys for the new labels (EN + CS) and updates the unit test module to include TranslateModule.

Reviewed changes

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

Show a summary per file

File	Description
src/app/shared/file-download-link/file-download-link.component.html	Adds aria-labels/keyboard semantics for the download link and restricted lock indicator
src/app/shared/file-download-link/file-download-link.component.ts	Injects DSONameService for bitstream name usage in accessible labels
src/app/shared/file-download-link/file-download-link.component.spec.ts	Adds TranslateModule.forRoot() to support translate pipe in the template
src/assets/i18n/en.json5	Adds new English i18n keys for download/restricted labels
src/assets/i18n/cs.json5	Adds/updates Czech i18n keys for download/restricted labels

---

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

[MatusBeke]

Addressed all 3 Copilot review comments in 945ad93:

1. Whitespace-dependent aria-label concatenation — the space between the translated "Download" prefix and the bitstream name is now explicit in the template (+ ' ' +), and the trailing space was removed from the en.json5 source string, so it no longer depends on translation-specific whitespace (cs.json5 had none, which produced "Stáhnoutname.pdf").
2. aria-label on a plain <span> — switched to the sr-only pattern already used elsewhere in this codebase (e.g. view-mode-switch.component.html): the lock icon is now aria-hidden="true" (decorative) and the restricted-state text lives in an adjacent <span class="sr-only">.
3. Missing test coverage — added spec assertions for the download link's aria-label and for the restricted-state sr-only text / aria-hidden icon.

Re-verified locally: lint ✅, circular-deps ✅, production build ✅ (no budget warnings), file-download-link.component.spec.ts 7/7 ✅.

[MatusBeke]

Manual verification screenshots (local Docker stack, seeded item with an embargoed bitstream, anonymous user):

Item view (full page):

Files section close-up — lock icon next to the restricted bitstream:

Visually nothing changed (as expected — this is an accessible-name-only fix). Confirmed via the accessibility tree / DOM inspection:

• Lock icon: aria-hidden="true", no aria-label of its own.
• Adjacent <span class="sr-only">Restricted bitstream</span> — exposed to assistive tech as generic: Restricted bitstream.
• Download link: aria-label="Download restricted-document.pdf" — single clean space, verified at the character level.

The pr-verification/ folder is for review reference only — happy to drop it in a follow-up commit before merge if preferred.

[MatusBeke]

Scope correction: the earlier commits only added an accessible-name (screen-reader-only) label to the lock icon — that's a real accessibility improvement, but it doesn't surface any visible embargo information, which is what #823 actually asks for.

Added in 40b07c8: the item view (publication + untyped-item, both src/app and the custom theme) now shows `dc.description.embargo` ("Delayed publication") and `dc.date.embargoend` ("Available after" + date) when present on the item — the same display already shipped for VSB-TUO in #1258, translated onto zcu-pub's current templates.

ds-generic-item-page-field no-ops when the metadata field is empty, so this has no effect on items without an embargo.

Re-verified: lint ✅, 64/64 relevant specs ✅ (including publication/untyped-item components), production build ✅ (no budget warnings).

[MatusBeke]

⚠️ Deployment note — required manual step before this is visible in production:

The two metadata fields this PR renders (`dc.description.embargo`, `dc.date.embargoend`) are not registered anywhere in the DSpace backend codebase — not in `dublin-core-types.xml`/`local-types.xml` on `customer/zcu-pub`, and not on `customer/vsb-tuo` either (checked both, where #1258 already ships this same display). They must have been registered manually on the VSB-TUO instance via Administer → Registries → Metadata (or the REST API) after deploy — it's an operational step, not something this frontend PR or any backend migration currently handles.

Before/when this ships to ZCU-PUB, someone needs to register on the backend:

• `dc.description` / qualifier `embargo`
• `dc.date` / qualifier `embargoend`

Confirmed via local testing: patching an item with these fields fails with 400 until they're registered; once registered, the frontend renders them correctly (see screenshot in the earlier comment above... will follow up with the visible-text screenshot too).

Happy to open a companion PR on the backend repo to register these via a proper migration instead of a manual admin step, if that's preferred — let me know.

[MatusBeke]

Visible-text screenshot for commit 40b07c8 (after manually registering the two metadata fields on the test backend — see deployment note above):

Rendered text (English UI):

• Delayed publication — "Delayed publication due to publisher agreement"
• Available after — "2027-06-30"

This is real page content (not aria-only), confirming the fix now surfaces actual embargo information as #823 asks for.

[MatusBeke]

Scope correction, round 2: the real fix

Further review (thanks for catching this) surfaced that neither the earlier accessibility fix nor the item-level metadata fields actually matched what #823 asks for: a per-bitstream embargo badge sourced from that bitstream's own resource policy, not item metadata.

Reverted (b01c0e6): the item-level dc.description.embargo / dc.date.embargoend display added earlier — wrong data source, wrong granularity.

Added (2ea2af5, 5f13be6): the real vanilla DSpace feature, ported from upstream commit 5f83139fcd (present on this fork's DSpace 9.x lines, e.g. customer/mendelu; absent on the 7.x line zcu-pub is on) — translated onto zcu-pub's older NgModule-based Angular architecture rather than cherry-picked, since upstream uses standalone components this codebase doesn't have:

• Bitstream model gains an accessStatus HAL link.
• AccessStatusObject (both the canonical copy and a pre-existing duplicate under object-list/) gains embargoDate.
• AccessStatusDataService.findBitstreamAccessStatusFor().
• New EmbargoBadgeComponent / ThemedEmbargoBadgeComponent, rendered inside file-download-link.component.html next to each restricted bitstream.
• New item.bitstream.showAccessStatuses config flag (enabled by default here).

UX pass (5f13be6) after a design review: the date is now formatted with Angular's date:'longDate' pipe instead of a raw ISO string, and the copy changed from "embargo until {{date}}" to "Available from {{date}}" (en) / "Dostupné od {{date}}" (cs). Badge color/style intentionally left matching the existing access-status-badge styling for visual consistency, per request.

Screenshot (Files section, anonymous user, after the fixes above):

Renders: "Available from June 30, 2027".

Backend dependency

This needs a companion backend change — GET /bitstreams/{id}/accessStatus returning {status, embargoDate} doesn't exist yet on customer/zcu-pub's backend (only the item-level equivalent does). That's being opened as a separate PR against dataquest-dev/DSpace; without it, this badge fails closed (renders nothing) rather than erroring, so this FE PR is safe to merge independently, but the feature won't be visible until both land.

Verification

• Lint ✅, production build ✅ (no budget warnings).
• embargo-badge.component.spec.ts (new, 6 tests) ✅, file-download-link.component.spec.ts ✅, thumbnail.component.spec.ts (needed a _links fixture update for the new accessStatus field) ✅.
• Manually verified end-to-end against a local Docker stack with a seeded embargoed item (screenshot above).

[MatusBeke]

Companion backend PR: dataquest-dev/DSpace#1377 (needed for this badge to actually render data — this FE PR fails closed without it).

[MatusBeke]

⚠️ This branch was force-pushed to a clean, corrected implementation. The previous commits (item-level metadata detour, the standalone EmbargoBadgeComponent, and the accessibility fix) have been replaced/split out - see the updated PR description above for the full story.

Summary of what changed and why:

• The standalone EmbargoBadgeComponent copied from an abandoned upstream design (commit 5f83139, Jan 2025) is gone. Replaced with the same unified AccessStatusBadgeComponent(object: Item | Bitstream)pattern already live oncustomer/mendelu`, matching current vanilla DSpace.
• Fixed a real crash bug: the old code read bitstream._links.accessStatus.href synchronously, which throws (uncaught by any catchError) on any backend lacking that link - i.e. this one, until Add an Item Thumbnail bitstream in  DSpace/dspace-angular#1377 deploys. Now uses LinkService.resolveLink(..., { isOptional: true }), which fails closed without even attempting a network call.
• showAccessStatuses now defaults to false (was true), matching upstream.
• i18n copy now matches vanilla exactly ("Embargo until {{ date }}") instead of a bespoke rewording.
• The accessibility fix (aria-label/sr-only on the lock icon) is now its own PR: ZCU-PUB/Add accessible labels to the restricted-bitstream lock icon #1390.
• Removed the committed pr-verification/*.png screenshots from the branch.

The 3 previously-resolved Copilot review threads on this PR are now stale (they reviewed commits that no longer exist in this branch) - a fresh review pass would be appreciated.

[MatusBeke]

Final, working screenshot — earlier attempts in this thread had raw untranslated `embargo.listelement.badge` text due to an unrelated local build-env bug (`NODE_ENV=production` wasn't set when I ran the Angular build manually, so the i18n asset hash baked into the JS bundle didn't match the copied file's actual name → 404 → translation fell back to the raw key). Not a code issue — fixed by using the project's own `yarn build:prod` script, which sets that correctly via `cross-env`.

Close-up:

Renders exactly as expected: "Embargo until 2027-06-30", same visual style as the existing access-status badge elsewhere on the site.

Reviewed against the actual customer ask (not just the diff) - verdict: approved to ship, with two non-blocking notes for a follow-up: (1) locale-format the date (e.g. "30 June 2027" / "30. června 2027") instead of the raw ISO string, (2) consider a short explanation of the "embargo" term for non-academic visitors. Neither blocks merge.