Skip to content

Conversation

@mikejritter
Copy link
Contributor

@mikejritter mikejritter commented Oct 15, 2025

What does this do?
Adds display name support for Authorities in order to provide a standard name to the services layer
Update authorities to include a display name
Update authority vocab titles to match cspace-ui.js or the respective profile plugin

Why are we doing this? (with JIRA link)
Jira: https://collectionspace.atlassian.net/browse/DRYD-1837

This is a requirement for the above ticket in order to better align the backend and frontend display names for authorities and their instances (vocabularies). Currently I only have the location authority updated to show how the display name for the authority can be updated as well as the authority instances.

How should this be tested? Do these changes have associated tests?
Testing this is kind of awkward because the display names are still defined in multiple places, but we should be able to check the tenant bindings compared to the ui or dev sites to verify consistency. I used xq in order to get information out of the bindings.

For the authority display names

  • For each tenant binding, get the display names, e.g.
cd ${tomcat}/cspace/config/services/tenants
xq '."tenant:TenantBindingConfig"."tenant:tenantBinding"."tenant:serviceBindings" | map(select(."@id" | contains("authorit"))) | map([."@id", ."@name", ."@displayName"]) ' anthro/tenant-bindings.merged.xml
# or if csv output is easier
xq '."tenant:TenantBindingConfig"."tenant:tenantBinding"."tenant:serviceBindings" | map(select(."@displayName")) | map([."@id", ."@name", ."@displayName"]) | .[] | @csv' anthro/tenant-bindings.merged.xml
  • Verify each output is found in the ui
  • Also a small note - I noticed some tenants have authorities enabled in their bindings but not in the ui. We should follow up on this.

For the authority vocabs

  • Similar to the above, but get the authority with a list of authority vocabs
cd ${tomcat}/cspace/config/services/tenants
xq '."tenant:TenantBindingConfig"."tenant:tenantBinding"."tenant:serviceBindings" | map(select(."@displayName")) | map({authority: ."@displayName", vocabs: [."service:AuthorityInstanceList"."service:AuthorityInstance"[]."service:title"]}) ' anthro/tenant-bindings.merged.xml
  • anthro - authority display name
  • anthro - authority vocabs
  • bonsai - authority display name
  • bonsai - authority vocabs
  • core - authority display name
  • core - authority vocabs
  • fcart - authority display name
  • fcart - authority vocabs
  • herbarium - authority display name
  • herbarium - authority vocabs
  • lhmc - authority display name
  • lhmc - authority vocabs
  • materials - authority display name
  • materials - authority vocabs
  • publicart - authority display name
  • publicart - authority vocabs

Dependencies for merging? Releasing to production?
It would be good to double check that the title field for authorities isn't being used. I know it gets stored in the database, but I don't believe anything is ever actually done for it.

Has the application documentation been updated for these changes?
Documentation on the csmake tool needs to be updated or started if it does not exist.

Did someone actually run this code to verify it works?
@mikejritter tested locally

@mikejritter mikejritter marked this pull request as ready for review October 20, 2025 21:19
@mikejritter
Copy link
Contributor Author

Bonsai
Has extra concept and place authority vocabularies. I created a Jira for this but I'm not sure how much of an issue it actually is.

Core
Has extra concept authority vocabularies. No Jira yet, same issue as bonsai.

FCART
Concept authority vocabularies need to be updated.

Herbarium
Extra concept and place authority vocabs. In addition it has a repeating title for one of its Material Concept vocabs. I'll need to double check here.

LHMC
Has extra concept and place authority vocabs.

PublicArt
Has extra org, person, place, and worth authority vocabs.

@spirosdi spirosdi self-requested a review October 31, 2025 13:50

<services-tenant-auth-singular>Locationauthority</services-tenant-auth-singular>
<services-tenant-auth-plural>Locationauthorities</services-tenant-auth-plural>
<services-tenant-auth-display-name>Storage Location</services-tenant-auth-display-name>
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@spirosdi I was considering adding this to every authority to be explicit about what the name is. It's a little redundant for the others, but not much work to do. Thoughts?

Copy link

Choose a reason for hiding this comment

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

I think it makes sense to add it to every authority. We might also need to change the value set at any time, so it is good to have the property already set. To easily spot what should be changed.

@spirosdi
Copy link

spirosdi commented Nov 4, 2025

I compared the tenant bindings to the UI. I confirm the mismatches mentioned here #325 (comment).

Just a few more mismatches:

FCART

  • Extra place vocab "Archaeological"

Botgarden (even though I understand that Botgarden is a special case, I add the mismatches just for the record)

  • Concept vocabs need to be updated.
  • Place extra vocab "Archaeological"
  • Location vocabs need to be updated. Location display name is "Garden Location" in UI.

@spirosdi
Copy link

spirosdi commented Nov 4, 2025

Regarding double checking that the title field for authorities isn't being used, I couldn't find any usage of it.

Copy link

@spirosdi spirosdi left a comment

Choose a reason for hiding this comment

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

Just some more mismatches spotted, but since they will be tackled in follow-up tasks, I approve

@mikejritter mikejritter merged commit 56ab2ff into collectionspace:develop Nov 4, 2025
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.

2 participants