Skip to content

Render license labels under flexible metadata - #7575

Open
ShanaLMoore wants to merge 4 commits into
mainfrom
flexible-metadata-semantic-renderers
Open

Render license labels under flexible metadata#7575
ShanaLMoore wants to merge 4 commits into
mainfrom
flexible-metadata-semantic-renderers

Conversation

@ShanaLMoore

Copy link
Copy Markdown
Contributor

What

On flexible-metadata apps, a work's license renders as a bare auto-linked URI ("https://creativecommons.org/licenses/by/4.0/") instead of its authority label ("Creative Commons BY Attribution 4.0 International").

Why

Attribute rendering under flexible metadata follows the m3 profile's view options, and the profiles Hyrax ships (engine default, koppie, dassie) mark license as render_as: external_link. Every app seeded from those profiles also carries the setting in its stored flexible schema, so fixing the profiles alone would not heal existing apps.

Fix

  • AttributesHelper#conform_options applies the semantic renderer for the two authority-backed fields (license -> :license, rights_statement -> :rights_statement), overriding a profile-supplied render_as. The semantic renderer's label still links out to the URI, so an external_link rendering is strictly worse than the label - which is why overriding the stored value is safe, and why this heals existing stored schemas without a migration.
  • The three shipped m3 profiles change license's view to render_as: license so newly seeded schemas agree with the code. related_url keeps its external_link, and the helper leaves fields without a semantic mapping untouched (covered by spec).

Testing

Spec additions in the existing #conform_options block cover both semantic fields, the override of a stored external_link, and non-semantic fields passing through unchanged. Written and verified downstream first: this fix originated as a Hyku decorator (samvera/hyku#3212), verified live against seeded flexible-metadata tenants where the license row now shows the authority label; upstreaming it here per review feedback since the helper and the profiles are Hyrax's. I could not run the full engine suite locally, so leaning on CI for the suite run.

Downstream note: once this lands, the Hyku decorator in samvera/hyku#3212 becomes redundant and that PR slims to nothing (its profile fix is Hyku's own copy, also being handled).

🤖 Generated with Claude Code

Under flexible metadata, attributes render per the m3 profile's view
options, and the shipped profiles mark license as
render_as: external_link - so licenses render as bare auto-linked URIs
instead of their authority labels, and every app seeded from those
profiles carries the setting in its stored flexible schema.

conform_options now applies the semantic renderer for the
authority-backed fields (license, rights_statement), overriding a
profile-supplied render_as: the label still links to the URI, so an
external_link rendering is strictly worse, and forcing it here heals
existing stored schemas without a migration. The shipped m3 profiles
(engine, koppie, dassie) are updated to render_as: license so new
schemas agree. related_url keeps its external_link.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
ShanaLMoore added a commit to samvera/hyku that referenced this pull request Aug 10, 2026


Per review, the conform_options fix belongs in Hyrax and is now open
upstream; the decorator stays only until the pinned hyrax revision
includes it, then gets deleted along with its spec.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@github-actions

github-actions Bot commented Aug 10, 2026

Copy link
Copy Markdown

Test Results

    17 files  ± 0      17 suites  ±0   3h 31m 58s ⏱️ + 10m 27s
 8 025 tests + 6   7 718 ✅ + 6  307 💤 ±0  0 ❌ ±0 
27 443 runs  +20  26 844 ✅ +20  599 💤 ±0  0 ❌ ±0 

Results for commit 7abe834. ± Comparison against base commit c57d5bb.

This pull request removes 443 and adds 449 tests. Note that renamed tests count towards both.
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplate:0x00007f0c22ceb910>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplate:0x00007f0f08418c00>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplate:0x00007f707ef65dd8>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplate:0x00007fa4cf2e94d0>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplateAccess:0x00007f0c2e77bcd0>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplateAccess:0x00007f0f09daf290>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplateAccess:0x00007f707ebeb540>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplateAccess:0x00007fa4d9850f18>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to destroy AdminSet: 35f059f3-a919-44fb-b4df-bff39220a615
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to destroy Hyrax::AdministrativeSet: 8b838429-befa-41db-8912-ca6aeb8a43a9
…
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplate:0x00007f600f4f03c8>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplate:0x00007f6fdbfff788>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplate:0x00007f9a3bd77e40>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplate:0x00007feb7026ce48>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplateAccess:0x00007f600f545288>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplateAccess:0x00007f6fdc058d60>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplateAccess:0x00007f9a432b26d8>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to create #<Hyrax::PermissionTemplateAccess:0x00007feb702626c8>
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to destroy AdminSet: f6eb17b3-a269-4821-ad87-38016d5d87b3
spec.abilities.ability_spec ‑ Hyrax::Ability AdminSets and PermissionTemplates a user without edit access is expected not to be able to destroy Hyrax::AdministrativeSet: 3d1b8dbb-bb40-45c4-a095-1b0e5c2d45b9
…

♻️ This comment has been updated with latest results.

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull request overview

Adjusts flexible-metadata attribute rendering so authority-backed URI fields (license and rights_statement) render via their semantic renderers (showing human-readable labels) instead of falling back to a bare auto-linked URI when profiles/schemas specify render_as: external_link.

Changes:

  • Force AttributesHelper#conform_options to override render_as for license and rights_statement to their semantic renderers.
  • Update shipped m3 metadata profiles (engine + koppie + dassie) so license uses render_as: license for newly seeded schemas.
  • Add specs covering semantic renderer application, override behavior (for license), and passthrough for non-semantic fields.

Reviewed changes

Copilot reviewed 5 out of 5 changed files in this pull request and generated 1 comment.

Show a summary per file
File Description
app/helpers/hyrax/attributes_helper.rb Forces semantic renderers for authority-backed fields regardless of stored/profile render_as.
spec/helpers/hyrax/attributes_helper_spec.rb Adds coverage for conform_options semantic renderer behavior and passthrough behavior.
config/metadata_profiles/m3_profile.yaml Updates default m3 profile to render license using the license renderer.
.koppie/config/metadata_profiles/m3_profile.yaml Aligns koppie’s m3 profile license rendering with semantic license renderer.
.dassie/config/metadata_profiles/m3_profile.yaml Aligns dassie’s m3 profile license rendering with semantic license renderer.

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

Comment thread spec/helpers/hyrax/attributes_helper_spec.rb
ShanaLMoore and others added 2 commits August 10, 2026 15:37
Copilot review: the stored-external_link override was only specced for
license; rights_statement takes the same path and deserves the same pin.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
@ShanaLMoore
ShanaLMoore requested a review from orangewolf August 11, 2026 15:16
@ShanaLMoore
ShanaLMoore marked this pull request as ready for review August 11, 2026 15:16
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants