https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20212 --- Comment #141 from Tomás Cohen Arazi <tomascohen@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.