Valkyrie: Collection Metadata issues on existing collections

[KatharineV]

Summary

DEV NOTE: Adding properties are done via yaml files now. You will not need to adjust models. Ping a dev on Team V for guidance.

This ticket tracks issues with existing collections as they appear post-Valkyrie and version 6.

• [ ] Collections now require a Rights statement, and we can't have this be a required field for collections. We do need it to remain required for works, as we've had it established in production up to this point, but it can't apply to collections because in most cases we have collections with multiple rights statuses. Post-upgrade collection pages require copyright to be selected. Prior to the Valkyrie sprint, we only required Title on collections. The way we use collections to group periodical issues that span pre and post public domain makes it impossible to apply a single copyright statement to most of the collections in our repository, so we need the ability to make that field NOT required in collections, even though we have it required on work types (and I know we can modify this via dashboard settings).

• [ ] It looks like a metadata field from previous versions of Hyku has not made it into version 6 collections. This is the "Department, School, or Faculty" field. We used this field in most of our collections in Hyku, and we do not want to lose this metadata when we upgrade to version 6. Can you map this field in our existing version 5 collections to the newly added Source field that is available in version 6 collections? The Source field wasn't present in collections before so I don't expect any issues if we map to Source.

Acceptance Criteria

• [x] Rights statement should not be a required field for Collections
• [x] Add Department, School or Faculty property to Collection
  • [ ] ~map this field in our existing version 5 collections to the newly added Source field that is available in version 6 collections~
  • [x] We mapped it to the department field (like prod does) otherwise converting the works would be at risk of losing data
• [x] In general, the Collection form's metadata and required fields should match what is seen in Prod

Screenshots or Video

Staging (rights statement should not be required)

Department, School, or Faculty field

Example of a production collection that uses that field: https://adl.b2.adventistdigitallibrary.org/collections/0ed83a24-3553-48bf-8216-eca875cbc48b?

Screenshot of Source field in version 6 post-Valkyrie staging collection: https://adl.s2.adventistdigitallibrary.org/dashboard/collections/9c5feb14-7c90-499f-aa4e-ea5cf40baf2d

Testing Instructions

• [ ] Newly created collection should fulfill all acceptance criteria
• [ ] Collection can be edited

Additionally, metadata was also modified to fix work models so:

• [ ] All work types should be able to be created & modified

Notes

@KatharineV should create a new ticket for metadata changes based on comment regarding metadata on forms & show page. Ticket passes and this issue is complete as long as the above tests are satisfied.

[AKFosterDev]

Files: config/metadata/collection_resource.yaml hyrax-webapp/app/models/collection_resource.rb config/metadata/collection_resource.yaml config/metadata/basic_metadata.yaml

Need pairing time. LaRita

[ShanaLMoore]

QA RESULTS: ❌ NEEDS REWORK

tested on STAGING

Acceptance Criteria

• [x] Rights statement should not be a required field for Collections ✅
• [ ] Add Department, School or Faculty property to Collection ❌ this field is missing
  • [ ] map this field in our existing version 5 collections to the newly added Source field that is available in version 6 collections
• [ ] In general, the Collection form's metadata and required fields should match what is seen in Prod ❌

PROD

Required fields:

STAGING

Required fields:

[ShanaLMoore]

TODO:

make sure collection_resource.yaml contains all of these metadata properties:

["aark_id", "abstract", "access_control_id", "access_right", "alt", "alternative_title", "altlabel", "based_near", "bibliographic_citation", "collection_type_gid", "contributor", "creator", "date", "date_accepted", "date_available", "date_created", "date_issued", "date_modified", "date_published", "date_submitted", "date_uploaded", "department", "depositor", "description", "doi", "former_identifier", "funder", "head", "identifier", "import_url", "issue_number", "keyword", "label", "language", "language_code", "lat", "license", "location", "long", "managing_organisation", "note", "official_url", "orcid", "output_of", "output_of_resource_ids", "pagination", "part_of", "place_of_publication", "preflabel", "publication_status", "publisher", "rdfs_label", "refereed", "related_url", "relative_path", "remote_url", "representative_id", "resource_type", "rights_description", "rights_holder", "rights_notes", "rights_statement", "slug", "slug_for_upgrade", "source", "subject", "tail", "thumbnail_id", "title", "volume_number"] => count: 70

We need to for sure at least add department and map the label name to "Department, Faculty, School". Add AdlMetadata back to collection resource however we need to make rights_statement false for collection resource.

OR

should we add to the script? copy department to source, if department is no longer a needed metadata field?

[sjproctor]

✅ Passes QA

Tested on staging

Acceptance Criteria

• [x] Rights statement should not be a required field for Collections
• [x] Add Department, School or Faculty property to Collection
• [x] In general, the Collection form's metadata and required fields should match what is seen in Prod
  • NOTE: all fields on prod appear in staging with the addition of the following fields on staging:
  • Orcid
  • Peer reviewed?
  • Remote URL
  • Rights Holder
  • Rights description
  • Preflabel
  • Altlabel
  • Volume
  • Access Rights
  • Alternative Title
  • Arkivo checksum
  • Bibliographic citation
  • Label
  • Rights notes
  • Rights statement
  • Source
  • Owner
  • On behalf of
  • State
  • Depositor

[KatharineV]

I created a new collection and tested the metadata. https://adl.s2.adventistdigitallibrary.org/collections/851b4393-f9d1-4fa1-b1d9-31bf589c8fff?locale=en

I filled in a few fields that did not display on the public view after I saved:

• Rights Statement (with dropdown options)
• Source

Then I tried to fill in ever field to test all appearances, and I got an error message. I reopened the edit screen, tried to save again, and the error message repeated.

Now the backend shows metadata in all the fields just as I entered it, but only the ones I filled the first time are showing on the public side, minus the two that never showed the first time (Rights Statement & Source).

[ShanaLMoore]

Staging logs/error from Katharine's comment:

2024-09-25T22:39:58.658842776Z Error: ERROR: [doc=851b4393-f9d1-4fa1-b1d9-31bf589c8fff] Error adding field 'issue_number_isim'='Issue' msg=For input string: "Issue"

this may be related to #822 , PR

TODO:

revert this change?

[ShanaLMoore]

blocked until #822 is resolved

[laritakr]

Metadata spreadsheet link… https://docs.google.com/spreadsheets/d/1Xc-QRpCEw0vNwcK6yxvBlTR6uEH-xrPWxTatRWCJ070/edit?usp=sharing

I went through all of the create forms to identify what I was seeing in my development environment, alphabetized them by their form label text, and added their attribute since some weren’t clear by the label. For each one, I then marked what shows in the prod environment create forms (I did not document what is on the show page). Hopefully this spreadsheet gives you the information you need to make the decisions on what you want on the forms and show pages. Please review it and let me know what you want changed.

Based on what I found, I did some minimal cleanup to try to bring things back to being in synch (such as moving the dates back to only allowing single dates). I can’t say which ones you will want to be on your forms, or showing on the show pages. Some of the terms may have been hidden before, and some are totally new due to the Hyrax updates.

Additionally, keep in mind that if you don’t add a metadata item to a work, it won’t appear on the show page. So there is no need to remove items that are removed from the form unless you think they could come in via bulkrax imports and you don't want them showing.