[Bug 25870] New: Add a q_ccl query parameter to /biblios
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Bug ID: 25870 Summary: Add a q_ccl query parameter to /biblios Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs@lists.koha-community.org Reporter: tomascohen@gmail.com It would be great if we could just pass a CCL query to the /biblios route -- 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=25870 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen@gmail.com Assignee|koha-bugs@lists.koha-commun |nick@bywatersolutions.com |ity.org | -- 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=25870 Kyle M Hall <kyle@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |kyle@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |paul.derscheid@lmscloud.de --- Comment #1 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Should this be a public route? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #2 from Paul Derscheid <paul.derscheid@lmscloud.de> --- There's another thing: I think that the only Content-Type that makes sense for the return value is 'application/marc-in-json' because we return 1..n records instead of a single one. Additionally I can't imagine a use-case in which you wouldn't want JSON as a return value for that route. Is there any sane way to discern marc records from one another in an api response? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #3 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Paul Derscheid from comment #2)
There's another thing: I think that the only Content-Type that makes sense for the return value is 'application/marc-in-json' because we return 1..n records instead of a single one.
Additionally I can't imagine a use-case in which you wouldn't want JSON as a return value for that route.
Is there any sane way to discern marc records from one another in an api response?
All of the accepted formats in GET /biblio/{biblio_id} have their plural representations [1] BUT I think we could start with 'application/marc-in-json'. and add things 'as-needed'. So if you want to work on this, it'd be ok to just implement marc-in-json for now. [1] "application/json" => this is the biblio + biblioitem table, plural is an arrary, "application/marcxml+xml" => there's '<collection>' for multiple records, "application/marc-in-json" => as you said, an array, "application/marc" => concatenated usmarc records would work, "text/plain" => double new line separator would work. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|nick@bywatersolutions.com |paul.derscheid@lmscloud.de -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #4 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 138123 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=138123&action=edit Bug 25870 - Add a q_ccl query parameter to /biblios This patch adds new functionality to the existing /public/biblios route. Instead of specifying a biblio by a biblionumber as a path parameter, you can use the new q_ccl query parameter to run a query on the endpoint. To test: 1) Apply the patch 2) Pick an endpoint tester of your choice, e.g. Insomnia or the ThunderClient if you use VSCode or derivatives. 3) Run a query while using Zebra. 4) Observe the marc-in-json response and check for validity. 5) Run a query while using Elasticsearch. 6) Again, observe the marc-in-json response and check for validity. 7) I'd love to say: 'Sign-Off' but the unit tests need work and I need help with that, so.. an attachment or guidance would be great. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #5 from Paul Derscheid <paul.derscheid@lmscloud.de> --- The other issue is that this route can be abused for DOS-attacks which must be handled somehow. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #6 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Paul Derscheid from comment #5)
The other issue is that this route can be abused for DOS-attacks which must be handled somehow.
Wouldn't the simplest solution be to make it *not* public, and just require the catalogue permission? Another option would be to bake in a rate limiting middleware such as https://metacpan.org/pod/Plack::Middleware::Throttle or https://metacpan.org/pod/Plack::Middleware::Throttle::Lite -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #7 from Paul Derscheid <paul.derscheid@lmscloud.de> --- That's right but at LMSCloud we need this as a public route and tcohen also wants this to be public, so the simple approach doesn't fly. Thanks for the pointers, I'll have a look in a bit. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #8 from Kyle M Hall <kyle@bywatersolutions.com> --- Also https://metacpan.org/pod/Plack::Middleware::Cerberus We need something that throttles by the minute or even second if possible. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #9 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Another question is what a sane 'number of requests/interval' would look like. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #10 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Paul Derscheid from comment #9)
Another question is what a sane 'number of requests/interval' would look like.
I think that depends on the power of the server, and your use case. What will you be using this API for? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #11 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Paul Derscheid from comment #5)
The other issue is that this route can be abused for DOS-attacks which must be handled somehow.
Isn't that already the case for bots hitting opac-search.pl? I think we need to introduce some tool for throttling, but not necessarily as part of this dev, as it is really tricky (e.g. it will be common for campus sites to be queried many times from a transparent proxy on the LAN so we will also need to be able to configure exceptions...). -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #12 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Tomás Cohen Arazi from comment #11)
(In reply to Paul Derscheid from comment #5)
The other issue is that this route can be abused for DOS-attacks which must be handled somehow.
Isn't that already the case for bots hitting opac-search.pl?
What I meant to say is that introducing this route just adds another place we need to take care of. But the solution is needed in general. Maybe at Apache level. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #13 from Kyle M Hall <kyle@bywatersolutions.com> --- (In reply to Tomás Cohen Arazi from comment #11)
(In reply to Paul Derscheid from comment #5)
The other issue is that this route can be abused for DOS-attacks which must be handled somehow.
Isn't that already the case for bots hitting opac-search.pl?
I think we need to introduce some tool for throttling, but not necessarily as part of this dev, as it is really tricky (e.g. it will be common for campus sites to be queried many times from a transparent proxy on the LAN so we will also need to be able to configure exceptions...).
That is a good point. Now, we just need to add throttling to this api, then use that api in opac-search.... ;) Tomas, at this time I think you have the ultimate authority to declare throttling "out of scope" and move it to a new bug report. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #14 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Paul Derscheid from comment #7)
That's right but at LMSCloud we need this as a public route and tcohen also wants this to be public, so the simple approach doesn't fly.
We can have both, really. And when we say 'public' we mean 'unprivileged access' which could or not imply authentication. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #15 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Kyle M Hall from comment #13)
That is a good point. Now, we just need to add throttling to this api, then use that api in opac-search.... ;)
Tomas, at this time I think you have the ultimate authority to declare throttling "out of scope" and move it to a new bug report.
I think we should file a separate bug, yes. And I wouldn't make this one dependent on the new one. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #16 from Kyle M Hall <kyle@bywatersolutions.com> --- I'd really like to see us get away from Apache based solutions, but at the same time it's a very practical way to handle it that works for 99.9% of Koha users. If there exists middleware that would work for Koha, that would be a better solution IMO, especially because we can bake the throttling settings directly into Koha. Now, I think we've done enough bike-shedding. We should move this discussion to a throttling specific bug report! -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #17 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Comment on attachment 138123 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=138123 Bug 25870 - Add a q_ccl query parameter to /biblios Review of attachment 138123: --> (https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=25870&attachment=138123) ----------------------------------------------------------------- ::: Koha/REST/V1/Biblios.pm @@ +160,5 @@
+ my $record_processor = Koha::RecordProcessor->new( + { + filters => 'ViewPolicy', + options => { + interface => 'opac',
I think you could implement only a list() method, and rely on $c->stash('is_public') to choose staff vs. public. And later check the OpacHiddenItems stuff accordingly. @@ +177,5 @@
+ } + ); + } + + sub format_record_by_content_type {
This inline subs look really untidy. @@ +243,5 @@
+ } + + my $response = + format_record_by_content_type( + { content_type => $requested_content_type, records => \@records } );
It feels like this method call should be placed in the data => portion of the respond_to, with the right parameters for each case instead of 'detecting it' inside format_record_... But as I said, I'm still not convinced by those subs. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #18 from David Cook <dcook@prosentient.com.au> --- (In reply to Kyle M Hall from comment #16)
I'd really like to see us get away from Apache based solutions, but at the same time it's a very practical way to handle it that works for 99.9% of Koha users. If there exists middleware that would work for Koha, that would be a better solution IMO, especially because we can bake the throttling settings directly into Koha.
I've just raised bug 31242 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #19 from David Cook <dcook@prosentient.com.au> --- (In reply to Tomás Cohen Arazi from comment #14)
(In reply to Paul Derscheid from comment #7)
That's right but at LMSCloud we need this as a public route and tcohen also wants this to be public, so the simple approach doesn't fly.
We can have both, really. And when we say 'public' we mean 'unprivileged access' which could or not imply authentication.
I know I struggle to wrap my head around how the API is organised as well... If I recall correctly, I think the majority of API endpoints are for admin/staff users and the "public" APIs are for public/OPAC users. Public users don't have authorizations (hence "unprivileged access"). Some public APIs require authentication and some don't. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #20 from David Cook <dcook@prosentient.com.au> --- (In reply to Paul Derscheid from comment #7)
That's right but at LMSCloud we need this as a public route and tcohen also wants this to be public, so the simple approach doesn't fly.
Thanks for the pointers, I'll have a look in a bit.
I'd like this as a public route as well, as I'd like to point a third-party at it, so that they can search Koha in an event-driven way. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #21 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #20)
(In reply to Paul Derscheid from comment #7)
That's right but at LMSCloud we need this as a public route and tcohen also wants this to be public, so the simple approach doesn't fly.
Thanks for the pointers, I'll have a look in a bit.
I'd like this as a public route as well, as I'd like to point a third-party at it, so that they can search Koha in an event-driven way.
Although for my use case I could go with a non-public route and just give them a "catalogue" authorized user like Kyle suggested. But that wouldn't work if we wanted opac-search.pl to use it. But... we could start with non-public and then add public later if we're concerned. They could probably share the controller even. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #138123|0 |1 is obsolete| | --- Comment #22 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 139452 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=139452&action=edit Bug 25870 - (follow-up) Add a q_ccl query parameter to /biblios I refactored the controller code but unfortunately still haven't figured out why Koha::Biblios->search doesn't work properly. For the time being I still use Koha::Biblios->find. That aside I think it has become much cleaner now. To test: 1) Apply the patch 2) Pick an endpoint tester of your choice, e.g. Insomnia or the ThunderClient if you use VSCode or derivatives. 3) Run a query while using Zebra. 4) Observe the marc-in-json response and check for validity. 5) Run a query while using Elasticsearch. 6) Again, observe the marc-in-json response and check for validity. 7) Not ready for sign-off but please leave a comment or help me on the Koha::Biblios->search thing. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #139452|0 |1 is obsolete| | --- Comment #23 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 139469 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=139469&action=edit Bug 25870 - (follow-up) Removed Data::Dumper + call I refactored the controller code but unfortunately still haven't figured out why Koha::Biblios->search doesn't work properly. For the time being I still use Koha::Biblios->find. That aside I think it has become much cleaner now. To test: 1) Apply the patch 2) Pick an endpoint tester of your choice, e.g. Insomnia or the ThunderClient if you use VSCode or derivatives. 3) Run a query while using Zebra. 4) Observe the marc-in-json response and check for validity. 5) Run a query while using Elasticsearch. 6) Again, observe the marc-in-json response and check for validity. 7) Not ready for sign-off but please leave a comment or help me on the Koha::Biblios->search thing. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #139469|0 |1 is obsolete| | --- Comment #24 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Created attachment 139491 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=139491&action=edit Bug 25870 - (follow-up) Raw MARC-XML records from Zebra now get appropriate treatment To test: 1) Apply the patch 2) Pick an endpoint tester of your choice, e.g. Insomnia or the ThunderClient if you use VSCode or derivatives. 3) Run a query while using Zebra. 4) Observe the marc-in-json response and check for validity. 5) Run a query while using Elasticsearch. 6) Again, observe the marc-in-json response and check for validity. 7) Not ready for sign-off but please leave a comment or help me on the Koha::Biblios->search thing. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |27113 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27113 [Bug 27113] Elasticsearch: Autocomplete in search -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Caroline Cyr La Rose <caroline.cyr-la-rose@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |caroline.cyr-la-rose@inlibr | |o.com, | |hammat.wele@inlibro.com, | |philippe.blouin@inlibro.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #138123|1 |0 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #139452|1 |0 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #139469|1 |0 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED --- Comment #25 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Paul, please redo on top of bug 32734. Let me know if you cannot work on it, so we trace a path. This needs tests as well. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |32734 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32734 [Bug 32734] REST API: Add a list endpoint for Biblios -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #26 from Paul Derscheid <paul.derscheid@lmscloud.de> --- I'll estimate the workload and get back to you, Tomas. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #27 from Paul Derscheid <paul.derscheid@lmscloud.de> --- Tomas, I'll continue working on this next week if that's alright with you. I'd love to do it immediately but I'm really swamped this week. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Hammat wele <hammat.wele@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #138123|0 |1 is obsolete| | Attachment #139452|0 |1 is obsolete| | Attachment #139469|0 |1 is obsolete| | Attachment #139491|0 |1 is obsolete| | --- Comment #28 from Hammat wele <hammat.wele@inlibro.com> --- Created attachment 148117 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148117&action=edit Bug 25870: Add a q_ccl query parameter to /biblios To test: 1) Apply the patch 2) Pick an endpoint tester of your choice, e.g. Insomnia or the ThunderClient if you use VSCode or derivatives. 3) Run a query while using Zebra. 4) Observe the marc-in-json response and check for validity. 5) Run a query while using Elasticsearch. 6) Again, observe the marc-in-json response and check for validity. 7) Not ready for sign-off but please leave a comment or help me on the Koha::Biblios->search thing. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #29 from Hammat wele <hammat.wele@inlibro.com> --- Redoing this bug on top of the bug 32734 -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #30 from Tomás Cohen Arazi <tomascohen@gmail.com> --- A few comments on the preliminary code: * An empty query should return an empty resultset, not a 404 * Koha::SearchEngine::Search->extract_biblionumber should be used instead of reinventing it * Pagination information is missing on the headers. It should be extracted from the query and added. Please look at $c->add_pagination_headers -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #31 from Hammat wele <hammat.wele@inlibro.com> --- Created attachment 148247 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148247&action=edit Bug 25870: (follow-up) Adding pagination information on the headers, returns an empty result when the query is empty -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #32 from Tomás Cohen Arazi <tomascohen@gmail.com> --- (In reply to Hammat wele from comment #31)
Created attachment 148247 [details] [review] Bug 25870: (follow-up) Adding pagination information on the headers, returns an empty result when the query is empty
Well :-D You are extracting pagination parameters from the (HTTP) query, good. But they are not being passed to the backend (in the form of offset + limit I think, as they should. Also, you need to know that the add_pagination_headers helper needs two totals: - the page total if the query is paginated (it would always be the case) - the total records from which the page was taken (base_total). -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Hammat wele <hammat.wele@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #148247|0 |1 is obsolete| | --- Comment #33 from Hammat wele <hammat.wele@inlibro.com> --- Created attachment 148446 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=148446&action=edit Bug 25870: (follow-up) Adding pagination information on the headers, returns an empty result when the query is empty -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #34 from Hammat wele <hammat.wele@inlibro.com> --- I still need help with Koha::Biblios->search thing. how to use it to search biblio hidden_in_opac. With the Koha::Biblios->search adding the pagination would be more easier. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Bug 25870 depends on bug 32734, which changed state. Bug 32734 Summary: REST API: Add a list endpoint for Biblios https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32734 What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Paul Derscheid <paul.derscheid@lmscloud.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|paul.derscheid@lmscloud.de |hammat.wele@inlibro.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Jonathan Druart <jonathan.druart+koha@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart+koha@gmail. | |com --- Comment #35 from Jonathan Druart <jonathan.druart+koha@gmail.com> --- (In reply to Hammat wele from comment #34)
I still need help with Koha::Biblios->search thing. how to use it to search biblio hidden_in_opac. With the Koha::Biblios->search adding the pagination would be more easier.
How that? You need to rewrite ->hidden_in_opac, to build a parameter hashref from the syspref, then pass it to ->search I haven't had a deep look but I think it is possible and should work. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #36 from Tomás Cohen Arazi <tomascohen@gmail.com> --- You really need to perform the search against the search engine, with any implicit filtering like OpacHiddenItems added to the CCL query. Otherwise you would kill the interesting bit of searching on the backend. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #37 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #35)
(In reply to Hammat wele from comment #34)
I still need help with Koha::Biblios->search thing. how to use it to search biblio hidden_in_opac. With the Koha::Biblios->search adding the pagination would be more easier.
How that? You need to rewrite ->hidden_in_opac, to build a parameter hashref from the syspref, then pass it to ->search
I haven't had a deep look but I think it is possible and should work.
I don't know if all item DB fields have matching index names/aliases, so that would be something that needs reviewing. (In reply to Tomás Cohen Arazi from comment #36)
You really need to perform the search against the search engine, with any implicit filtering like OpacHiddenItems added to the CCL query. Otherwise you would kill the interesting bit of searching on the backend.
Yeah, it'll need both OpacSuppression, OpacSuppressionByIPRange, and OpacHiddenItems checking. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #38 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- As this is blocking the much desired 27113 - what can we do to help move this along? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Marcel de Rooy <m.de.rooy@rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.de.rooy@rijksmuseum.nl --- Comment #39 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- Any plans to get this moving again ? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #40 from Blou <philippe.blouin@inlibro.com> --- This is a rabbit hole. We are now in the time of the year where we prepare our next release AND it's coincidently relevant to what's on master. Bug 27113 is stuck behind this, which is big, complicated and involves many parties with more experience than we do. I need to determine now if we put 27113 straight up on our pile, or it's worth Hammat investing some time on this. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #41 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Blou from comment #40)
This is a rabbit hole.
We are now in the time of the year where we prepare our next release AND it's coincidently relevant to what's on master. Bug 27113 is stuck behind this, which is big, complicated and involves many parties with more experience than we do.
I need to determine now if we put 27113 straight up on our pile, or it's worth Hammat investing some time on this.
Maybe it would be worth adding this one to the agenda for the next dev meeting to get some attention and more direction. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Magnus Enger <magnus@libriotech.no> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |magnus@libriotech.no --- Comment #42 from Magnus Enger <magnus@libriotech.no> --- This is still blocking bug 27113. Any chance of getting it moving again? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #43 from David Cook <dcook@prosentient.com.au> --- Since we're progressively moving to Elasticsearch, do we really want a query parameter called q_ccl? CCL is legacy at this point... Personally, I think what we really is an endpoint like "/search". The REST purists might say "but 'search' isn't a resource", but I think it can still be treated as a resource in terms of the API. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #44 from Magnus Enger <magnus@libriotech.no> --- Whatever works, if you ask me. :-) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Blou <philippe.blouin@inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |27428 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27428 [Bug 27428] Show the number of records in the bibliographic record detail page with ElasticSearch -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #45 from Blou <philippe.blouin@inlibro.com> --- This non-discussion is very hurtful to the development of ANY other feature trying to make the best use of ES capabilities. The fact that Koha still has no autocomplete in the search bar reminds me it took us 4 years to get a reset password mecanism in the OPAC. "Expected" features should be railroaded to completion. This bug needs to move ahead, or the blocked bugs (here Bug 27113) should be allowed to move ahead without it. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #46 from David Cook <dcook@prosentient.com.au> --- (In reply to Blou from comment #40)
This is a rabbit hole.
(In reply to Blou from comment #45)
This non-discussion is very hurtful to the development of ANY other feature trying to make the best use of ES capabilities.
Going to have to disagree with you there. I think there's quite a bit of useful/helpful discussion here. I think most of us have actually been waiting for a developer response here. (See Marcel's comment especially.) I think we'd all like to see this development move forward, but there really is a lot to consider too.
The fact that Koha still has no autocomplete in the search bar reminds me it took us 4 years to get a reset password mecanism in the OPAC. "Expected" features should be railroaded to completion.
The lack of a password reset was painful for sure, but railroading things is also how we got into a lot of trouble in the past. Perhaps what you mean is that functionality that should be seen as central/core to Koha (e.g. search) should be prioritised? I'd agree with that (although it's easier said than done). I think the API is particularly difficult to change, because it's an API. It's not something that's super easy to change once you've created it, so you want to get it right the first time. There's heaps of stuff - especially for security - that I'd love to add to Koha, but I haven't polished it enough for the global community Koha yet. The frustrating but also great thing about the community process is that others can point out the mistakes or shortcomings in our code. It's the whole "if you want to go fast, go alone. If you want to go far, go together" thing.
This bug needs to move ahead, or the blocked bugs (here Bug 27113) should be allowed to move ahead without it.
It looks like Caroline moved bug 27113 to blocked in April 2024. Perhaps after comments from Tomas and Katrin. After skimming through the comments, I don't understand why bug 27113 would need to depend on bug 25870? Isn't it completely different functionality? I'll add a comment on that bug asking about that... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #47 from David Cook <dcook@prosentient.com.au> --- (In reply to Blou from comment #40)
I need to determine now if we put 27113 straight up on our pile, or it's worth Hammat investing some time on this.
That is certainly a challenge. I have the same problem. Difficult committing my time to large changes which move slowly... Sounds like bug 27113 is the goal? Honestly, I'm a bit surprised not to see this first as a Koha plugin. I'm guessing there must be some reason for now doing that though. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #48 from Jonathan Druart <jonathan.druart@gmail.com> ---
(In reply to Blou from comment #40) The fact that Koha still has no autocomplete in the search bar reminds me it took us 4 years to get a reset password mecanism in the OPAC. "Expected" features should be railroaded to completion.
Aware of the roadmap? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Mathieu Saby <mathsabypro@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mathsabypro@gmail.com -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Add a q_ccl query parameter |Add a q_ccl query parameter |to /biblios |to /biblios (ie add search | |API endpoint) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #49 from David Cook <dcook@prosentient.com.au> --- Yesterday, I was talking to a third-party developer who was mentioning how they have to use opac-search.pl in RSS mode to do searches against Koha, and that it was unfortunate that there was no search API. It seems like it's one of the biggest gaps in the API at the moment. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #50 from David Cook <dcook@prosentient.com.au> --- Yesterday, I was talking to a third-party developer who was mentioning how they have to use opac-search.pl in RSS mode to do searches against Koha, and that it was unfortunate that there was no search API. It seems like it's one of the biggest gaps in the API at the moment. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |Failed QA --- Comment #51 from David Cook <dcook@prosentient.com.au> --- Marking "Failed QA". Unless I'm mistaken, it looks like this honours OpacHiddenItems - but not OpacSuppression, which is arguably the easier to do with the API search... -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #52 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #50)
Yesterday, I was talking to a third-party developer who was mentioning how they have to use opac-search.pl in RSS mode to do searches against Koha, and that it was unfortunate that there was no search API.
It seems like it's one of the biggest gaps in the API at the moment.
I think getting an API endpoint right here would probably involve refactoring opac-search.pl so that the two locations use the same code. The third-party developer mentioned how library users hate when an app search (ie app search) differs from an OPAC web search. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #53 from Magnus Enger <magnus@libriotech.no> --- (In reply to David Cook from comment #50)
Yesterday, I was talking to a third-party developer who was mentioning how they have to use opac-search.pl in RSS mode to do searches against Koha, and that it was unfortunate that there was no search API.
It seems like it's one of the biggest gaps in the API at the moment.
Why not use SRU? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #54 from David Cook <dcook@prosentient.com.au> --- (In reply to Magnus Enger from comment #53)
(In reply to David Cook from comment #50)
Yesterday, I was talking to a third-party developer who was mentioning how they have to use opac-search.pl in RSS mode to do searches against Koha, and that it was unfortunate that there was no search API.
It seems like it's one of the biggest gaps in the API at the moment.
Why not use SRU?
Because it's direct to the search engine. It bypasses all of Koha's business logic. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #55 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #54)
(In reply to Magnus Enger from comment #53)
(In reply to David Cook from comment #50)
Yesterday, I was talking to a third-party developer who was mentioning how they have to use opac-search.pl in RSS mode to do searches against Koha, and that it was unfortunate that there was no search API.
It seems like it's one of the biggest gaps in the API at the moment.
Why not use SRU?
Because it's direct to the search engine. It bypasses all of Koha's business logic.
(In reply to David Cook from comment #52)
The third-party developer mentioned how library users hate when an app search (ie app search) differs from an OPAC web search.
Besides bypassing Koha's business logic as a technical problem, it's also a UX problem because it would create a different result than the OPAC web search. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #56 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #54)
(In reply to Magnus Enger from comment #53)
(In reply to David Cook from comment #50)
Yesterday, I was talking to a third-party developer who was mentioning how they have to use opac-search.pl in RSS mode to do searches against Koha, and that it was unfortunate that there was no search API.
It seems like it's one of the biggest gaps in the API at the moment.
Why not use SRU?
Because it's direct to the search engine. It bypasses all of Koha's business logic.
It would be OK if you just need access to Koha's backend, but for third-parties trying to create additional front-ends it's just not feasible. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #57 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- In the meantime another year has passed ;) I was wrestling again with ways to use what is currently available like: /api/v1/biblios?q=[{"title":"Learning Perl \/"}] This is an exact search. Not very attractive but it works. /api/v1/biblios?q=[{"title":{"-regexp":"perl"}}] /api/v1/biblios?q=[{"title":{"-like":"%25perl%25"}}] These kind of work, but they are not the same as title searches on the OPAC. This would need things like: /api/v1/biblios?q=[{"title":{"-regexp":"(\\W|^)perl\\W"}}] Which obviously is very tedious.. It would be nice if we could do a title search or keyword search, something like: /api/v1/biblios?title=perl Which should imho be interpreted as a starts_with word search. And should be possible to configure with _match? /api/v1/biblios?keyword=perl I agree that we should not refer to CCL anymore here. And I also think that we should not add this to public but run it with a simple api user having catalogue perms. The fact that we still dont have a more intuitive way to search the biblio records in the API apart from these ugly json constructs, is a bit disappointing? -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #58 from Blou <philippe.blouin@inlibro.com> --- (In reply to Marcel de Rooy from comment #57)
is a bit disappointing?
I respect the understatement. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #59 from David Cook <dcook@prosentient.com.au> --- (In reply to Blou from comment #58)
(In reply to Marcel de Rooy from comment #57)
is a bit disappointing?
I respect the understatement.
@Blou: If someone wants it, they can build it -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #60 from David Cook <dcook@prosentient.com.au> --- Ok, so there are many people interested in being able to send a search query to the REST API and get back search results. But I think that different people have different use cases here, and that's why the "one size fits all" approach clearly isn't working. -- I'm interested in providing Koha's OPAC search function to third-party discovery systems. (I imagine that's the same use case as Tomas and Paul?). The SOLUS Library App is very popular in Australia, and currently when they integrate with Koha they end up using opac-search.pl in RSS XML mode to get biblionumbers and then they use the REST API to get information about each record. It's not ideal. inLibro are very keen to get bug 25870 pushed because it's a dependency for "Bug 27113 - Elasticsearch: Autocomplete in search", which requires both Private Authenticated endpoints and Public Unauthenticated endpoints. Let's look at a proposed request: /api/v1/biblios?q=[{"title":"Learning Perl \/"}] Does that look like a search request to you? To me, it looks like a string of JSON being sent to a HTTP REST style biblios endpoint. It just doesn't make sense. What we need is /api/v1/search and /api/v1/public/search. And the inputs needs to be the same as the existing "Advanced search" and faceted/filtered/refined search. Basically, we need to be able to do a Staff interface search or an OPAC search via the API. We do not need to be dogmatic. It doesn't matter that there isn't a "search" table in the MySQL database. A "catalogue search" is still "a thing". Personally, I would recommend POSTing a search to the search endpoint, but I can understand why people would want to do a GET. That's fine. Re-use the same query parameters from the HTML search. That's fine. Think about every other search API you've ever used anywhere else. You've probably used a "/search" endpoint. For example: https://developer.spotify.com/documentation/web-api/reference/search Yes, there is a "/tracks" endpoint where you can look up one or more tracks by ID. But to do a "search", you use the "/search" endpoint. It's OK. -- When we have that /api/v1/public/search and /api/v1/search, it would be trivial to do autocomplete, to provide a search service to third-party apps like mobile apps or discovery layers, or to do all kinds of programmatic interrogation of the Koha catalogue. If we did POSTs instead of GETs, bots would be less likely to abuse the endpoint. It is doable. -- And if that sounds like a lot of work... it probably is because it is. But let's do the work rather than doing a workaround and just adding to the ever growing mountain of technical debt we have in Koha. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #61 from David Cook <dcook@prosentient.com.au> --- (In reply to David Cook from comment #60)
And if that sounds like a lot of work... it probably is because it is.
Personally, I haven't done it, because I don't have the customer demand for it. If I had the demand for it, then I'd build it. -- For bug 27113, why not add a system preference "SearchSuggestionURL" and add a Koha plugin for it? Or just do it wholly in a Koha plugin? Or add a REST API endpoint /api/v1/search/suggestions and /api/v1/public/search/suggestions and have it just process an unqualified query or a single index query. Depends on how you want to implement the autocomplete. I really do think that we've been way too locked into the REST dogma and we're ignoring industry standards and wide-spread practicality. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #62 from David Cook <dcook@prosentient.com.au> --- Btw when I say unauthenticated public endpoint, we should still require a valid anon session. That's another way of preventing abuse. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #63 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I think we need to take a step back to where this dev came from: a demand that it needs to be done in order to have bug 27113 move forward. I personally would love to see that as I think auto-complete with Elasticsearch would make a great feature, in core and not only a plugin. Maybe it could be implemented without that using Elasticsearch's existing APIs? Having an Elasticsearch only solution would not be an issue nowadays. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #64 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Katrin Fischer from comment #63)
I think we need to take a step back to where this dev came from: a demand that it needs to be done in order to have bug 27113 move forward.
I personally would love to see that as I think auto-complete with Elasticsearch would make a great feature, in core and not only a plugin.
Maybe it could be implemented without that using Elasticsearch's existing APIs? Having an Elasticsearch only solution would not be an issue nowadays.
If we would support this, it should not be Elastic only.. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #65 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Marcel de Rooy from comment #64)
(In reply to Katrin Fischer from comment #63)
I think we need to take a step back to where this dev came from: a demand that it needs to be done in order to have bug 27113 move forward.
I personally would love to see that as I think auto-complete with Elasticsearch would make a great feature, in core and not only a plugin.
Maybe it could be implemented without that using Elasticsearch's existing APIs? Having an Elasticsearch only solution would not be an issue nowadays.
If we would support this, it should not be Elastic only..
We already have a growing number of features that are Elastic only. I don't think we can demand Zebra right now and we shouldn't. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #66 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- (In reply to Katrin Fischer from comment #65)
(In reply to Marcel de Rooy from comment #64)
(In reply to Katrin Fischer from comment #63)
I think we need to take a step back to where this dev came from: a demand that it needs to be done in order to have bug 27113 move forward.
I personally would love to see that as I think auto-complete with Elasticsearch would make a great feature, in core and not only a plugin.
Maybe it could be implemented without that using Elasticsearch's existing APIs? Having an Elasticsearch only solution would not be an issue nowadays.
If we would support this, it should not be Elastic only..
We already have a growing number of features that are Elastic only. I don't think we can demand Zebra right now and we shouldn't.
Meaning the auto-complete feature. Not a search API. My suggestion was to divide it from this bug report maybe. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #67 from Katrin Fischer <katrin.fischer@bsz-bw.de> --- I don't want to derail this... it just feels like we have been stuck for such a long time (probably not only a feeling). Happy with whatever people agree that moves us forward. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #68 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- (In reply to Katrin Fischer from comment #67)
I don't want to derail this... it just feels like we have been stuck for such a long time (probably not only a feeling). Happy with whatever people agree that moves us forward.
Yeah. We all want a different implementation (with good reasons, intentions, etc) but ultimately we end up having "nothing" 6 years later.. Note that nothing should be taken too literally :) -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #69 from Marcel de Rooy <m.de.rooy@rijksmuseum.nl> --- not taken -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |43355 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43355 [Bug 43355] Add a /search API endpoint for biblios -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Martin Renvoize (ashimema) <martin.renvoize@openfifth.co.uk> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|43355 | See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=43355 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=43355 [Bug 43355] Add a /search API endpoint for biblios -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #70 from Blou <philippe.blouin@inlibro.com> --- (In reply to Katrin Fischer from comment #66)
We already have a growing number of features that are Elastic only. I don't think we can demand Zebra right now and we shouldn't.
Meaning the auto-complete feature. Not a search API. My suggestion was to divide it from this bug report maybe.
We (inLibro) had a different solution for the autocomplete, but were told it needed to be built over this. Of course, we haven't waited, to the benefit of our users base. But I find very dumb to prevent Koha from having it for six years because of architectural zealotism (bz27113 depending on this, not "making 25870 one right" I clarify). -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #71 from David Cook <dcook@prosentient.com.au> --- (In reply to Katrin Fischer from comment #63)
I think we need to take a step back to where this dev came from: a demand that it needs to be done in order to have bug 27113 move forward.
Where is that demand? Looking at bug 27113 I see Tomas mention bug 25870 in 2021 in Comment 49 but only in terms of discussion. Not a demand. I don't see it mentioned as a dependency until Caroline mentioned it in 2023 in Comment 105. It looks like Caroline was the one who added it as a dependency 2023-02-08?
I personally would love to see that as I think auto-complete with Elasticsearch would make a great feature, in core and not only a plugin.
Yes, it would be a great feature, but considering delays and the potential problems with libraries with large collections, a plugin could be a good way to try it out in a variety of scenarios without doing a full push into core. Creating a plugin wouldn't stop it from being added into core once it's proven that it works and works well. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #72 from David Cook <dcook@prosentient.com.au> --- (In reply to Blou from comment #70)
We (inLibro) had a different solution for the autocomplete, but were told it needed to be built over this.
I can't see this in the bug reports. Was it mentioned in a dev meeting or an email or something?
Of course, we haven't waited, to the benefit of our users base. But I find very dumb to prevent Koha from having it for six years because of architectural zealotism (bz27113 depending on this, not "making 25870 one right" I clarify).
@Blou, I would suggest that you re-read the Koha Community Code of Conduct and review the language that you're using: https://koha-community.org/about/policy/code-of-conduct/ . While it was designed for events, I think it's something that we still try to adhere to more broadly. -- Personally, I don't think I've seen any zealotry, but I think we do sometimes have overly dogmatic approaches to certain architectural decisions for sure. I think it comes from a place of wanting to build a standards-based system that is maintainable by many people and for a long-time, but sometimes mistakes are made or things go in a suboptimal way. I've had some very high performance changes never make it into Koha for a number of reasons, and that's unfortunate but it also happens in group projects sometimes. I think instead of getting frustrated with each other, we can communicate and work together to find a solution. I think everyone is trying their best and has good intentions. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 --- Comment #73 from David Cook <dcook@prosentient.com.au> --- Useful features/enhancements being blocked for years is something that frustrates everyone. Perhaps even increasingly so. I'm in the process of trying to think of architectural changes that will make it easier to extend Koha. I think with the slow shift towards using the REST API for the backend and Vue.js for the front-end, it's going to get easier and easier to extend/customize Koha. "Bug 43355 - Add a /search API endpoint for biblios" has been created to add a search endpoint. Whether that's the right answer for bug 27113 - I don't know. I think /api/v1/search/autocomplete or something more to-purpose would make sense, but that's just me. Hence my comment about having a Koha Plugin and a System Preference pointing to an API endpoint. @Katrin: The logic is we make whatever necessary UI changes to Koha, have the system preference or other setting to point to the endpoint, and then backend components can be developed and swapped out easily. So maybe it starts as Koha Plugin, but then everyone really likes it, so we adopt it into core. (For instance, I think that Koha should adopt Bywater's Coverflow into core, as it's such a handy feature for every Koha.) Anyway, just a thought. I by no means am saying that it has to be a Koha Plugin, but I think that would accelerate development and testing. It's an approach I'm increasingly going to try taking with my own enhancements and new features. -- You are receiving this mail because: You are watching all bug changes.
https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25870 Lisette Scheer <lisette@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact| |testopia@bugs.koha-communit | |y.org -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org