Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Collection type badges on catalog search results for shared search tenants #1815

Open
laritakr opened this issue Jun 29, 2022 · 0 comments
Open
Labels

Comments

@laritakr
Copy link
Collaborator

laritakr commented Jun 29, 2022

Descriptive summary

Collection type badges on catalog search results for shared search tenants should access the collection type from the appropriate tenant.

The issue can be handled for now by manually adding any new collection type to every tenant that is part of the shared search (as well as the search tenant) but this is a cumbersome solution, and it requires that all tenants keep identical collection types to avoid incorrect badge information.

Rationale

Shared search fails with custom collection types. Commit d501210 ensures that default collection types will be added to search only tenants as they are created. However, this is still searching within the shared search tenant. If custom collection types are added and used within one of the tenants being searched, the catalog results still fail with an error finding the collection type for the badge:

ActiveRecord::RecordNotFound in CatalogController#index
Couldn't find Hyrax::CollectionType matching GID 'gid://hyku/hyrax-collectiontype/3'

The backtrace identifies several points to break into the process:

[hyrax (2.9.6) app/models/hyrax/collection_type.rb:52:in `find_by_gid!'](http://share.utk-hyku.test/catalog?utf8=%E2%9C%93&locale=en&search_field=all_fields&q=#)
[hyrax (2.9.6) app/presenters/hyrax/collection_presenter.rb:32:in `collection_type'](http://share.utk-hyku.test/catalog?utf8=%E2%9C%93&locale=en&search_field=all_fields&q=#)
[hyrax (2.9.6) app/presenters/hyrax/collection_presenter.rb:95:in `collection_type_badge'](http://share.utk-hyku.test/catalog?utf8=%E2%9C%93&locale=en&search_field=all_fields&q=#)
[hyrax (2.9.6) app/views/catalog/_index_header_list_collection.html.erb:3](http://share.utk-hyku.test/catalog?utf8=%E2%9C%93&locale=en&search_field=all_fields&q=#)

Expected behavior

Shared searches including collections from multiple tenants should return a search results page with either:

  • the correct collection type badges.
  • no collection type badges.

Actual behavior

Shared searches use collection type table from within the shared search tenant, which can either return incorrect type or fail if no collection type record exists for the specific id requested.

Steps to reproduce the behavior

  1. Create a search tenant over two or more tenants
  2. Create a new collection type in one of the tenants and create a collection with the new collection type
  3. The catalog search results on the shared search tenant returns ActiveRecord::RecordNotFound
  4. Add the new collection type to the shared search tenant
  5. Create a different collection type in another of the tenants and create a collection with the new collection type
  6. The catalog search results on the shared search tenant will mislabel the collection type because it uses the information in the shared search tenant

Related work

Link to related tickets or prior related work here.

@laritakr laritakr added the bug label Jun 29, 2022
jeremyf added a commit to scientist-softserv/palni-palci that referenced this issue Dec 15, 2023
*Background:* A search_only tenant renders SOLR documents that had home
tenants different than the search_only tenant.  Part of that rendering
includes the underlying Work's collection type.  The SOLR document
stores the `Hyrax::CollectionType`'s ID.

The search_only tenant might have the same ID for
`Hyrax::CollectionType` but it is not the same thing.  Further, the home
tenant might have an ID that is not in the search_only tenant, which
results in an `ActiveRecord::RecordNotFound` error.

Prior to this commit, we always attempted to render the badge.

With this commit, we add some guarding logic to avoid rendering the
badge when we're likely not rendering within the SOLR documents home
tenant.

Related to:

- #951
- samvera/hyku#1815
jeremyf added a commit to scientist-softserv/palni-palci that referenced this issue Dec 15, 2023
*Background:* A search_only tenant renders SOLR documents that had home
tenants different than the search_only tenant.  Part of that rendering
includes the underlying Work's collection type.  The SOLR document
stores the `Hyrax::CollectionType`'s ID.

The search_only tenant might have the same ID for
`Hyrax::CollectionType` but it is not the same thing.  Further, the home
tenant might have an ID that is not in the search_only tenant, which
results in an `ActiveRecord::RecordNotFound` error.

Prior to this commit, we always attempted to render the badge.

With this commit, we add some guarding logic to avoid rendering the
badge when we're likely not rendering within the SOLR documents home
tenant.

Related to:

- #951
- samvera/hyku#1815
jeremyf added a commit to scientist-softserv/palni-palci that referenced this issue Dec 15, 2023
*Background:* A search_only tenant renders SOLR documents that had home
tenants different than the search_only tenant.  Part of that rendering
includes the underlying Work's collection type.  The SOLR document
stores the `Hyrax::CollectionType`'s ID.

The search_only tenant might have the same ID for
`Hyrax::CollectionType` but it is not the same thing.  Further, the home
tenant might have an ID that is not in the search_only tenant, which
results in an `ActiveRecord::RecordNotFound` error.

Prior to this commit, we always attempted to render the badge.

With this commit, we add some guarding logic to avoid rendering the
badge when we're likely not rendering within the SOLR documents home
tenant.

Related to:

- #951
- samvera/hyku#1815
jeremyf added a commit that referenced this issue Dec 19, 2023
This was referenced Dec 19, 2023
This was referenced Jan 8, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

1 participant