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

[Bug 16734] New: getLanguages() in opac-search.pl should be called only if needed
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '25

08 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16734 Bug ID: 16734 Summary: getLanguages() in opac-search.pl should be called only if needed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: abl(a)biblos.pk.edu.pl QA Contact: testopia(a)bugs.koha-community.org There is no need to always call getLanguages() in opac/opac-search.pl (especially not if it's an actual search), it's output is used only in opac-advsearch.tt template. This patch moves it into 'if ( ... $template_type eq 'advsearch' )' block. Speed gain is rather moderate (40 - 80 msec, if the mysql server is no too busy, and the results are already in query cache), but it eliminates a lot of small DBI calls, making a further profiling of OPAC searches a bit easier. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 28742] New: OAI.xslt has hardcoded metadataPrefix = oai_dc
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '25

07 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28742 Bug ID: 28742 Summary: OAI.xslt has hardcoded metadataPrefix = oai_dc Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When viewing the pages on the web there are many places where oai_dc is hardcoded - there should be an option in config/sets for the default prefix to use in the template -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 35760] New: Separate manage_all_funds permission from which funds are available for ordering
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '25

07 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35760 Bug ID: 35760 Summary: Separate manage_all_funds permission from which funds are available for ordering Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisette.scheer(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some large consortia want the ability for some users to be able to manage all funds but only order from their branch's funds/funds they are owners for. Currently if you can manage all funds, you see everything in the dropdown when ordering, which with large systems can be overwhelming. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 29268] New: Query used in Koha::Biblio->get_marc_host is incorrect
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '25

07 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29268 Bug ID: 29268 Summary: Query used in Koha::Biblio->get_marc_host is incorrect Change sponsored?: --- Product: Koha Version: master 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org After digging through this some more in relation to bug 27507 and bug 11175 I have come to the conclusion that I think the searches performed by get_marc_host are too simplistic/incorrect. First of all, both the 773 field and $w subfield are repeatable.. so we need to iterate for subfields as well as the field. Secondly, I don't think the search for (RCI)CN is correct.. this is what would appear in the 773 of the child, not how the 001 would be constructed in the host. What I believe we really need to do is as follows: 1. Iterate through 773 fields. 2. Iterate through subfield w's and looks for one of the following: 1a. (RCI)Controlnumber where the RCI matches the OrgCode syspref 1b. Fully numeric Controlnumber 3. Once we've found the form we're expecting from above iterations (1a in preference to 1b if both exist) jump out of the loops. 3. Produce the search string 'control-number=Controlnumber' for 1b. or `control-number=Controlnumber AND rci=RCI` if 1a is found. It may also be helpful to add the `OR control-number=Controlnumber` search to 1a to account for cases where OrgCode was added to new children but was is missing from the host? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 37547] New: One should be able to disable sending of element set name in z3950 connections
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '25

07 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37547 Bug ID: 37547 Summary: One should be able to disable sending of element set name in z3950 connections Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We've recently had to set up a new z3950 connection to a provider who doesn't support element set names. Koha sends 'F' for full in the element set name field at connection time and so we're faced with an error 24 for all searches against this provider. We should make it configurable what element set name is used.. F, B or none at all. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 19859] New: Add option to return to the search result in authorities
by bugzilla-daemon＠bugs.koha-community.org 07 Jan '25

07 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19859 Bug ID: 19859 Summary: Add option to return to the search result in authorities Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi, It is imposible to return to hte result search when you edit an authorities in a record. When we want to edit an authorities in a record, we can clic on the tag editor. That option will open a search page. In this search page you can search authorities. If you clic on edit authorities that action will be open into the authorities module. If you clic on save, you stay in authorities module and you don't return on the search page of the tag editor. Because of that, if you had made some changes in the authoritie, you can't clic on choose for linking to the record. To recreate: Go to a record Edit an authoritie with tag editor Search an authoritie with this plugin Choose an authoritie and clic on edit authorities Clic on Save Notice that you still in the authorities modul and you can’t link this authoritie in your record. For make this link you have to "go back" two times ank clic on choose or make this search another time. Patrick. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 38154] New: Batch checkout fails if AllFinesNeedOverride is set to Require and patron has any fines
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '25

06 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38154 Bug ID: 38154 Summary: Batch checkout fails if AllFinesNeedOverride is set to Require and patron has any fines Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To replicate: -Set AllFinesNeedOverride to Require -Add fines to patron account below the amount set in noissuescharge -Enter barcodes into batch item checkout for patron, and click Check out -Click 'Checkout or renew' button on the Batch checkout confirmation screen (keep all items selected) -Note that no items have actually checked out -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 18595] New: Move C4::Members::Messaging to Koha namespace
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '25

06 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18595 Bug ID: 18595 Summary: Move C4::Members::Messaging to Koha namespace Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: lari.taskula(a)jns.fi QA Contact: testopia(a)bugs.koha-community.org Bug 17499 adds Koha-objects for messaging preferences. -- You are receiving this mail because: You are watching all bug changes.

1 159

[Bug 38254] New: Patron auto-complete search explodes when dateexpiry is NULL
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '25

06 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38254 Bug ID: 38254 Summary: Patron auto-complete search explodes when dateexpiry is NULL Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com This was moved from bug 31143: > We either need to fix the auto-complete patron search or have the > script re-calculate the dateexpiry from the patron category. I am > leaning towards making the patron search deal with NULL. borrowers.dateexpiry can be NULL so the code needs to be fixed. I have not tried it but this would be the idea: iff --git a/koha-tmpl/intranet-tmpl/prog/js/staff-global.js b/koha-tmpl/intranet-tmpl/prog/js/staff-global.js index 73a4a0251e1..28060fb35da 100644 --- a/koha-tmpl/intranet-tmpl/prog/js/staff-global.js +++ b/koha-tmpl/intranet-tmpl/prog/js/staff-global.js @@ -694,10 +694,13 @@ function patron_autocomplete(node, options) { } let new_date = new Date(); let today = Date.parse($date_to_rfc3339($date(new_date.toString()))); - let expiration = Date.parse( - $date_to_rfc3339($date(item.expiry_date.toString())) - ); - let expired = today > expiration; + let expired = false; + if (item.expiry_date){ + let expiration = Date.parse( + $date_to_rfc3339($date(item.expiry_date.toString())) + ); + expired = today > expiration; + } return $("<li></li>") .addClass(loggedInClass) .data("ui-autocomplete-item", item) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 36454] New: Staff - Provide indication if a patron is expired when creating an ILL request
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '25

06 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36454 Bug ID: 36454 Summary: Staff - Provide indication if a patron is expired when creating an ILL request Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com CC: katrin.fischer(a)bsz-bw.de, martin.renvoize(a)ptfs-europe.com, nick(a)bywatersolutions.com, pedro.amorim(a)ptfs-europe.com, rebecca.bradshaw(a)nnuh.nhs.uk, tomascohen(a)gmail.com Creating an ILL request, when staff adds a patron, there is no indication that the patron is expired, if said patron is indeed expired. Part of the problem tackling this, I believe, is that the 'create form' is ILL backend specific, so this should be tackled at each ILL backend level. Having said that, with bug 35570 in the pipeline, we could perhaps consider adding this little enhancement as a follow-up to that. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47