- Koha-bugs - lists.koha-community.org

[Bug 19306] New: Adding hooks to the plugin system
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '24

31 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19306 Bug ID: 19306 Summary: Adding hooks to the plugin system Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: stefan.berndtsson(a)ub.gu.se QA Contact: testopia(a)bugs.koha-community.org We've been working on adding hook functionality to the existing plugin system. This is very much proof-of-concept code at the moment, but here is how it works. 1. Somewhere in the code you add a hook-call with a name for that hook, and pass in some data relevant to that hook. 2. Each plugin with a method matching the hook name is called in sequence, with the data as input and returning data of similar form, which is then passed on to the next matching plugin. 3. The end result is returned back from the hook-call, is put back in place, and code execution is resumed. The PoC code adds a Koha::Plugins::Handler->run_matching() method that looks up the relevant loaded plugins (using GetPlugins) and calls Koha::Plugins::Handler->run() on each of them. If plugins are not enabled, or if there is no plugin matching the hook, the input data is returned back, resulting in unaffected operation. One hook is added in Koha::SearchEngine::Elasticsearch::QueryBuilder.pm, in build_query_compat with the name "build_query_before", which is simply run before the query parsing takes place. A very simple example plugin is available at: https://github.com/ub-digit/koha-plugin-build-query-example/releases This plugin edits a query beginning with "Provider:" to do "publisher:" instead. A simple example that when using Elasticsearch makes publisher links in the bibliographic detail view clickable. The current XSLT uses the Zebra based links, that result in an unusable search. This is not meant to be the solution to the Zebra/Elasticsearch conflict in the XSLT, but it's a simple demonstration of the hook feature. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 13705] Move indexation subs in C4::ZebraIndex
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '24

31 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13705 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Failed QA CC| |dcook(a)prosentient.com.au --- Comment #20 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Fridolin Somers from comment #19) > Looks obsolete since we have Koha/SearchEngine/Zebra Yeah, Koha/SearchEngine/Zebra/Indexer.pm would be the best place to house this code. "./misc/migration_tools/rebuild_zebra.pl" is nearly 1000 lines long, which is not a good idea for a CLI script. I'd say this change has merit, but... it's super old. Personally, I'd be tempted to mark this one as RESOLVED WISHLIST, as it would be nice to have, but with the gradual shift to Elasticsearch... I don't know if it's really worth the time. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 34662] New: Allow configuration of search type in main search bar
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '24

31 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34662 Bug ID: 34662 Summary: Allow configuration of search type in main search bar Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The top search bar defaults to different types of search depending on the page one is on. It would be helpful to make this configurable to allow for local preference. For example, when one is looking at a Normal view of a bib record (/cgi-bin/koha/catalogue/detail.pl?biblionumber=X), the top search bar defaults to Search the Catalog. But if one clicks to Holds on the same record (/cgi-bin/koha/reserve/request.pl?biblionumber=X), then the top search bar switches to Check Out. Our staff find this disruptive, but I don't expect a strong consensus across the community for how this should behave. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 11599] itemBarcodeFallbackSearch should work even for items that don't have barcodes
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '24

31 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11599 --- Comment #3 from hebah(a)bywatersolutions.com --- I will just chime in on this a decade later to note that in the intervening time, batch patron actions went from cardnumber only to being able to use borrowernumber, and batch actions can be run with an itemnumber, so it would be great if this preference meant that items without barcodes could be searched up and circulated this way since they ultimately do still have itemnumbers. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 11599] itemBarcodeFallbackSearch should work even for items that don't have barcodes
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '24

31 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11599 hebah(a)bywatersolutions.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hebah(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11808] When searching for a cardnumber in the intranet, also try to search for it on the LDAP server if one is configured and add/update user
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '24

31 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11808 hebah(a)bywatersolutions.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hebah(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 38300] New: Cancelling holds in bulk should not need localStorage
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '24

31 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38300 Bug ID: 38300 Summary: Cancelling holds in bulk should not need localStorage Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We are storing the selected holds in localStorage, we should not need that. Once we selected and cancelled them, a fresh table (without nothing checked) should be shown. There is some code to reset it 251 if(!localStorage.selectedWaitingHolds || document.referrer.replace(/\?.*/, '') !== document.location.origin+document.location.pathname) { 252 localStorage.selectedWaitingHolds = '[]'; 253 } But it does not work in all situations. I think we simply need to use a JS variable, or I am missing something. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 13965] Add date last seen on item search
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '24

31 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13965 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on|37238 | Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37238 [Bug 37238] Add table settings to itemsearch results -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13965] Add date last seen on item search
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '24

31 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13965 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |36640 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36640 [Bug 36640] Upgrade DataTables from 1.13.6 to 2.x -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33480] New: Improve display of the vendor aliases in the ERM module
by bugzilla-daemon＠bugs.koha-community.org 31 Oct '24

31 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33480 Bug ID: 33480 Summary: Improve display of the vendor aliases in the ERM module Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ERM Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com Depends on: 33103 Coming from bug 33103 comment 34 """ I am not persuaded by the display tbh, I believe it will get messy very soon as often those aliases will be quite long and we might even want to record a slight name change. Could it be an option to show the aliases in the list as "second level" entries, kind of a hiearchical display, like we have it for funds? """ Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33103 [Bug 33103] Add vendor aliases -- You are receiving this mail because: You are watching all bug changes.

1 29