Bug 33092 - Add ability to search within a list
Summary: Add ability to search within a list
Status: NEW
Alias: None
Product: Koha
Classification: Unclassified
Component: Lists (show other bugs)
Version: Main
Hardware: All All
: P5 - low enhancement (vote)
Assignee: Bugs List
QA Contact: Testopia
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2023-02-28 18:09 UTC by Donna
Modified: 2024-05-03 01:13 UTC (History)
5 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Donna 2023-02-28 18:09:04 UTC
It would be really helpful to be able to search within a list in both the OPAC and the staff interface.  For instance, in both the staff interface, if you are viewing a public list with a lot of items on it, you do not have the ability to see if a specific item appears on the list.  This is a needed functionality with larger lists.
Comment 1 Marie-Luce Laflamme 2023-06-27 15:21:12 UTC
It would be nice to add the ability to search within a list. Maybe some facets could help to filter the list content.
Comment 2 mg 2024-03-22 16:43:38 UTC
I am setting up koha on my server, adding like specific genre of books, say 1000 books (records). Then open the website to users (I was told they could be made patrons so they can add the books they own to their own list).  It would be great if it is possible for a user with list of 50 books for example to search just inside his own list.
Comment 3 David Cook 2024-04-29 00:06:46 UTC
If I understand the above commenters, you would want to search a list like you search the catalogue? However, the catalogue search is done by the search engine, while lists are managed only in the database. 

Technically, with few changes, you could create a search query that contains every record in a list by including every biblionumber for every record in the list in a query, but large lists would create very large query lengths, which might even be too long for the search engine to manage. 

A more robust change would be to add lists to the search engine. This would mean storing the list ID in the actual bibliographic record itself. Since a bib record can belong to many lists, this would need to be a repeatable subfield. This subfield would then be added to search engine indexes. I suppose something like the 999$l (lowercase l) could be used, but I don’t know if other Koha community developers would be agreeable to that solution. 

Alternatively, an Elasticsearch only solution could probably be developed that doesn’t require changing the MARC, but again I don’t know if anyone would be agreeable to that solution.
Comment 4 David Cook 2024-04-29 00:09:04 UTC
This also means that changes to lists would require re-indexing records.

Refactoring all the list code could take a fair bit of work.
Comment 5 Katrin Fischer 2024-04-29 06:46:39 UTC
Maybe it would be enough to use a datatables based search here instead of the full search engine one.
Comment 6 David Cook 2024-04-29 07:13:07 UTC
(In reply to Katrin Fischer from comment #5)
> Maybe it would be enough to use a datatables based search here instead of
> the full search engine one.

I think that would be my preference - at least in the short-term.

I'd like to hear how people would like to search these lists. It might be that we can offer some search fields (e.g. title, author).
Comment 7 Christopher Brannon 2024-04-29 14:54:44 UTC
To my knowledge, in this example given, if you are looking to see if an item is in a list, if you go to the item record, it will show what list it is in.  I don't know if this relies on a system preference, but we can see the lists that it is in.
Comment 8 Katrin Fischer 2024-04-29 15:04:14 UTC
You can see on the record, that's correct. But that's by database lookup, not coming from the MARC record.
Comment 9 Christopher Brannon 2024-04-29 15:06:57 UTC
(In reply to Katrin Fischer from comment #8)
> You can see on the record, that's correct. But that's by database lookup,
> not coming from the MARC record.

I'm not sure what that has to do with this request.  The request isn't to find out if an item is on a list via MARC record. It is to find out if an item is on a list.  I was simply trying to offer an existing method.
Comment 10 Katrin Fischer 2024-04-29 15:08:22 UTC
(In reply to Christopher Brannon from comment #9)
> (In reply to Katrin Fischer from comment #8)
> > You can see on the record, that's correct. But that's by database lookup,
> > not coming from the MARC record.
> 
> I'm not sure what that has to do with this request.  The request isn't to
> find out if an item is on a list via MARC record. It is to find out if an
> item is on a list.  I was simply trying to offer an existing method.

If you look at David's comment he was suggestion to add the information to the MARC record in able to be able to do a search on what is on a list or to allow Zebra/Elasticsearch based searches within a list, I thought you were referring to that.
Comment 11 Christopher Brannon 2024-04-29 15:12:47 UTC
No, simply offering an existing method for the author of the bug.
Comment 12 Marie-Luce Laflamme 2024-04-29 15:52:11 UTC
So, adding this feature would make life easier when you're sifting through a massive list of items (think 80+). Being able to search by title and author would be a game-changer for quickly finding what you need.

Someone suggested in Bugzilla #27690 that we could just pop a search box at the top of the list, like how it's done on the opac-course-details.pl course-reserves page. Simple and effective!
Comment 13 David Cook 2024-05-03 01:13:43 UTC
(In reply to Marie-Luce Laflamme from comment #12)
> So, adding this feature would make life easier when you're sifting through a
> massive list of items (think 80+). Being able to search by title and author
> would be a game-changer for quickly finding what you need.
> 
> Someone suggested in Bugzilla #27690 that we could just pop a search box at
> the top of the list, like how it's done on the opac-course-details.pl
> course-reserves page. Simple and effective!

So the Course reserves work differently because they're a client-side DataTable. 

--

I'm thinking that we add a JOIN to the biblio table, and that should allow us to search for title and author. It looks like there's already a join for items, so it should be easy enough to search for things like barcode and itemcallnumber.

Before starting on this, I'd want a clear idea of what we're going to do though. 

I'm thinking a "Search list" search box under "This list contains X titles" and above the toolbar beginning with "New list".

Then we could take the search query and search it against a set number of database fields. 

We'd have to make sure that we pass the query in the pager buttons, but that should be doable.