-
Notifications
You must be signed in to change notification settings - Fork 48
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
Labels
Comments
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
Related to Issues: - #1815 - scientist-softserv/palni-palci#951 Related to Pull Requests: - scientist-softserv/palni-palci#952
This was referenced Dec 19, 2023
This was referenced Jan 8, 2024
Merged
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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:
The backtrace identifies several points to break into the process:
Expected behavior
Shared searches including collections from multiple tenants should return a search results page with either:
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
Related work
Link to related tickets or prior related work here.
The text was updated successfully, but these errors were encountered: