https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33092 Marie-Luce Laflamme <marie-luce.laflamme@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marie-luce.laflamme@inlibro | |.com --- Comment #1 from Marie-Luce Laflamme <marie-luce.laflamme@inlibro.com> --- It would be nice to add the ability to search within a list. Maybe some facets could help to filter the list content. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33092 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #3 from David Cook <dcook@prosentient.com.au> --- 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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33092 --- Comment #5 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- Maybe it would be enough to use a datatables based search here instead of the full search engine one. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33092 Christopher Brannon <cbrannon@cdalibrary.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |cbrannon@cdalibrary.org --- Comment #7 from Christopher Brannon <cbrannon@cdalibrary.org> --- 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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33092 --- Comment #9 from Christopher Brannon <cbrannon@cdalibrary.org> --- (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. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33092 --- Comment #11 from Christopher Brannon <cbrannon@cdalibrary.org> --- No, simply offering an existing method for the author of the bug. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33092 --- Comment #13 from David Cook <dcook@prosentient.com.au> --- (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. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.