When search limited to single repository, typeahead results return entries from full database
|Assignee:||Dan Gillean||% Done:|
|Category:||Search / Browse|
|Target version:||Release 2.1.0|
|Google Code Legacy ID:||Tested version:|
- starting at York University page, make sure search is scoped to that institution
- do a search for "fonds"
- from the typeahead results, choose "all matching descriptions"
- Results from several institutions; institutional facet not set
- Search limited to York University
On the other hand, individual typeahead results do appear to be from the correct institution.
For descriptions, I'm wondering if it's as simple as changing "realm" to "repos" in the search parameters. In this example, the resulting URL was:
got the expected result.
The same thing happens for authority records, but since there is currently no institutional facet for authority records, this was not surprising. Similarly, institutions should be excluded if the search is limited to a single repository.
#1 Updated by Tim Hutchinson over 8 years ago
I meant to include the starting URL: http://archivescanada.accesstomemory.org/york-university-clara-thomas-archives-special-collections
#4 Updated by Dan Gillean over 8 years ago
A good point - looking again at your suggested short-term fix implies that we could handle this pretty easily, and reopen a separate ticket for future development. Tentatively assigning to 2.0.1 for now.
Part of my thinking was that I'm aware we already have 25 outstanding issues on 2.0.1, and 92 on 2.1, many/most? of which are feature development/improvement ideas, and all of which are unsponsored - I know that unless they are sponsored, it's likely that many will get bumped forward, but I'd rather see them bumped than left without a target release and lost in the ether. The other part of it is that yes, I'd ideally like to tie this to an internal conversation we're having about the increasing need to be able to associate specific authority records, physical locations, and terms/taxonomies with specific repositories - and that in my mind, I keep trying to associate improvements to the search bar with the discussions begun on #5277, as a way to improve searching overall.
That said, there's no reason why a more simple fix couldn't occur just for descriptions/repositories based on the fix you've proposed, and implemented much earlier. Ultimately, such broader changes merit a different issue ticket at future date. I was just trying to keep the developers from yelling at me for assigning too much to 2.0.1 ;)
#6 Updated by Tim Hutchinson over 8 years ago
Thanks, Dan. My assumption around limiting authority record searches to a repository (for #5968) is that the search would return authority records linked to a repository with the relevant repository_id. I'm hoping that adding the institutional facet to authority records would also take care of the typeahead search, but I haven't looked at those details.
#10 Updated by Dan Gillean over 8 years ago
- Status changed from QA/Review to Verified
Tim, we've fixed the results for archival descriptions when the search is limited to a single repository - it appears you were correct, it was merely a matter of changing "realm" to "repos" in the URL. Since this is a simple fix, we've addressed it quickly, and and will include it in the next minor release.
The rest involves a bit more complexity, and should perhaps be dealt with in a separate issue ticket, more along the lines of a feature request. As you've noted, there is currently no way to associate an authority record with a repository in AtoM - and were one added, it needs to be flexible enough to allow authority records to be associated with multiple (or no) repositories, for portal/network use where one pool of authority records is maintained across a number of interrelated institutions, thereby avoiding potential duplication. If USask would like to include this as part of the developments under discussion for #5968, that would be great!
Similarly, at the moment, other institution results will still appear in the typeahead, even when the delimiter is set. It would be great to address this, but I'd rather see this fix included sooner than later and another issue ticket opened, than many different elements bogging this ticket down and keeping what's been done from making it into a release. Hope that makes sense!