https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20212
--- Comment #141 from Tomás Cohen Arazi <tomasco...@gmail.com> --- (In reply to Jonathan Druart from comment #140) > I am sorry but I cannot persuade myself that pushing the "fix_query" trick > is a good idea. > > We are doing it for only one purpose: search on isbn. In that case why don't > we have a hidden feature to allow that (instead of having ton of code that > is dealing with all biblioitem attributes)? > Tomas told me that this fix_query won't be reused somewhere else, but > actually IMO we will need to implement it correctly everywhere we search on > biblio. > Like a simple route GET /biblios will need it :) > > If we push it "as it", what would be the next step? If we push it, and it makes sense (i.e. we really need it in other places) we need a second loop similar to that of ->to_api to gather information about the bestest objects with each of them specifying the transformations required for the query. And pass that to the build_query helper. It felt too much for a single case, but can be done if course. > Is there plan to have a > GET /biblios route? Development shifted to routes we need to implement things. There's no plan for that route, still. > I've just noticed I remove the search by ean, that was using the same trick. > We could re-add it easily but we should then display it in the summary > column, for consistency. The EAN filter is dependent on UNIMARC being set. Keep it in mind. -- You are receiving this mail because: You are watching all bug changes. _______________________________________________ Koha-bugs mailing list Koha-bugs@lists.koha-community.org https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-bugs website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
