ZCU-DATA/Show a per-bitstream embargo-date badge in the CLARIN file listing

[MatusBeke]

Problem

The bitstream download in the ZCU-DATA Item View gives no indication when a restricted file's embargo lifts. Fixes dataquest-dev/dspace-customers#823 (ZCU-DATA frontend portion).

Root cause / why this isn't a port of #1378

ZCU-DATA's Item View doesn't use the standard file-download-link/AccessStatusBadgeComponent path at all - the whole ds-clarin-files-item-field block is commented out in both publication.component.html and untyped-item.component.html. Instead, every item page unconditionally renders <ds-clarin-files-section> (wired directly into simple/item-page.component.html), which goes through a completely separate, CLARIN-specific component chain: clarin-files-section → preview-section → file-description, backed by its own REST endpoint (metadatabitstreams/search/byHandle → MetadataBitstreamWrapperRest) that returns a flat DTO per file rather than a HAL resource with resolvable links. This needed real new implementation, not a cherry-pick.

Change set

• MetadataBitstream model gains status/embargoDate fields, matching what the backend companion PR (ZCU-DATA/Add bitstream-level access status/embargo date REST endpoint DSpace#1380) now embeds directly in the endpoint's response - no separate link-resolution step needed here, unlike the HAL-link approach on ZCU-PUB.
• file-description.component.html renders the same visual badge (badge badge-secondary, embargo.listelement.badge i18n key) already used on ZCU-PUB (ZCU-PUB/Show a per-bitstream embargo-date badge in the Item View #1378), next to the file name, for a consistent look across both customer instances.
• New item.bitstream.showAccessStatuses config flag, defaulting to false - same reasoning as ZCU-PUB/Show a per-bitstream embargo-date badge in the Item View #1378: flip it only once the backend PR is deployed.
• i18n copy matches ZCU-PUB/vanilla exactly: "Embargo until {{ date }}" (en) / "Embargo do {{ date }}" (cs).

Backend dependency

Needs dataquest-dev/DSpace#1380 (which also fixes a real pre-existing bug found while testing this: the CLARIN file listing 500'd entirely for any item with an embargoed bitstream, anonymously, independent of this change - see that PR for details). With the flag at its default false, this frontend PR has no runtime effect either way.

Test evidence

npx ng lint --quiet                       -> All files pass linting.
npx ng build --configuration production   -> build succeeded, no budget warnings
npx ng test (file-description.component.spec.ts)
                                           -> 5/5 SUCCESS

Covers: badge hidden by default (no embargo), badge shown when embargoed + flag on, badge hidden when embargoed but flag off (fail-safe default).

Risk & rollback

Low risk: two new optional fields on an existing DTO, one new conditional badge in one template, feature-flagged off by default. Revert is a straight git revert.

Notes / assumptions

• Companion backend PR: ZCU-DATA/Add bitstream-level access status/embargo date REST endpoint DSpace#1380.
• Companion PRs for ZCU-PUB (same feature, different implementation path): ZCU-PUB/Show a per-bitstream embargo-date badge in the Item View #1378 (badge) + ZCU-PUB/Add accessible labels to the restricted-bitstream lock icon #1390 (accessibility fix, unrelated but adjacent).

[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: a5539265-82e1-4f1c-a8ab-0e2c8f9b839b

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

[MatusBeke]

Companion backend PR: dataquest-dev/DSpace#1380. Sibling PR for ZCU-PUB (different implementation path, same feature): #1378.

[Copilot]

Pull request overview

Adds feature-flagged support for displaying an embargo-until badge per CLARIN bitstream in the custom file listing path, by extending the MetadataBitstream DTO and rendering a localized badge next to the filename.

Changes:

• Extend MetadataBitstream with status and embargoDate fields to match the updated REST payload.
• Add item.bitstream.showAccessStatuses configuration (default false) and wire it into the CLARIN FileDescriptionComponent.
• Introduce embargo.listelement.badge i18n strings (en/cs) and unit tests covering the flag behavior.

Reviewed changes

Copilot reviewed 9 out of 9 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
src/environments/environment.test.ts	Adds the new item.bitstream.showAccessStatuses flag to the test environment config.
src/config/item-config.interface.ts	Extends the item bitstream config interface with showAccessStatuses.
src/config/default-app-config.ts	Defines the default value (false) for the new bitstream access-status display flag.
src/assets/i18n/en.json5	Adds the new embargo badge translation string.
src/assets/i18n/cs.json5	Adds the Czech translation for the new embargo badge string.
src/app/item-page/simple/field-components/preview-section/file-description/file-description.component.ts	Reads the new feature flag for controlling badge display in the CLARIN file listing.
src/app/item-page/simple/field-components/preview-section/file-description/file-description.component.html	Renders the embargo-until badge next to the filename when enabled.
src/app/item-page/simple/field-components/preview-section/file-description/file-description.component.spec.ts	Adds unit coverage for badge hidden-by-default and gated-by-flag behavior.
src/app/core/metadata/metadata-bitstream.model.ts	Adds status/embargoDate autoserialized fields to the metadata bitstream model.

---

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

[MatusBeke]

Manual verification against a local Docker stack

Backend: dataquest-dev/DSpace PR #1380 @ 4b4ce9fd (rebuilt from source, not the cached customer image - see note below). Frontend: this branch @ e04c31cf (includes the latest "Potential fix for pull request finding" commit tightening the badge condition to status === 'embargo' && embargoDate and adding ml-1 spacing).

Setup:

• item.bitstream.showAccessStatuses flipped to true locally only (default stays false, not committed).
• yarn build:prod against the local backend at localhost:8080, served via node dist/server/main (SSR), viewed anonymously (not logged in).
• Seeded item "Embargoed Test Item" (handle 20.500.14592/4) with a restricted restricted-document.pdf bitstream whose resource policy resolves to status: "embargo", embargoDate: "2027-06-30" via GET /server/api/core/metadatabitstreams/search/byHandle.

Full item page:

Close-up of the CLARIN file-description badge:

Renders exactly as expected: "Embargo until 2027-06-30", right next to restricted-document.pdf in the Files section, fully translated (no raw embargo.listelement.badge i18n key visible) - this is real rendered page content, not aria-only.

Note: initially hit a stale pre-built dataquest/dspace:customer-zcu-data image that predated #1380's commits (endpoint returned 200 but silently omitted status/embargoDate). Rebuilt the backend image from the actual PR branch source to get a trustworthy result - worth keeping in mind for anyone else verifying against a cached customer image.

Screenshots pushed to orphan branch pr-screenshots/1394 (unrelated history, kept out of this PR's Files Changed diff), same pattern as pr-screenshots/1378 on the sibling ZCU-PUB PR (#1378).

[MatusBeke]

Fixed: lock icon/filename now match ZCU-PUB's visual style 1:1 (3dfd44a).

Root cause of the mismatch in the previous screenshot: on ZCU-PUB, file-download-link.component.html always wraps the bitstream name in an <a> (routerLink to the download), with the lock icon conditionally prefixed inside it — the icon inherits the link's blue color from that wrapping anchor. This CLARIN file-description component previously rendered the name as plain text with the icon outside any link, so it rendered black instead of blue.

Fixed by wrapping the name (and lock icon) in a clickable element bound to downloadFile(), only for the embargoed+flagged state — non-embargoed file names are untouched (still plain text, no behavior change there).

Full item page:

Close-up:

🔒 restricted-document.pdf (blue, clickable) — Embargo until 2027-06-30, now visually 1:1 with the ZCU-PUB screenshot.