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

[Bug 32515] New: SIP2 no block flag on checkin calls routine that does not exist
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32515 Bug ID: 32515 Summary: SIP2 no block flag on checkin calls routine that does not exist Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org git grep "checkin_no_block" C4/SIP/Sip/MsgType.pm: $status = $ils->checkin_no_block( $item_id, $trans_date, $return_date, $item_props, $cancel ); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 18117] New: Convert browser alerts to modals
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18117 Bug ID: 18117 Summary: Convert browser alerts to modals Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org With modals becoming more active in Koha, I think we need to move away from alert messages and stick with modals. Alert messages look different from browser to browser, and you have less/no control over the look and feel of the alert. Modals would allow for more enhancement, such as color and sound, if someone chose that. The big concern is consistency. We lack consistency between alerts and modals, and with alerts between browsers. I would proposed a stop on use of alert messages, and convert existing uses of alerts to modal. That's my opinion. Would like to hear others. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 30575] New: Returning an ILL item shouldn't just change the request status
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30575 Bug ID: 30575 Summary: Returning an ILL item shouldn't just change the request status 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: tomascohen(a)gmail.com In the context of more complex ILL backends, in which returning an item could imply, for example, notifying an external source it is just not enough to call $req->status('RET')->store We should be calling something like ->backend_return instead, as we do with other actions, and let the plugin handle it however they need to. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 12141] On Display Module
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12141 Sally Lodico <Slodico(a)knoxlib.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |Slodico(a)knoxlib.org --- Comment #22 from Sally Lodico <Slodico(a)knoxlib.org> --- +1 Yes please. Right now all of our circ staff have permission to bulk edit the location field, which isn't ideal, but it's the only option we had. A display module would be grand. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 32627] New: Reprinting holds slips should not reset the expiration date
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32627 Bug ID: 32627 Summary: Reprinting holds slips should not reset the expiration date Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: Laura.escamilla(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Occasionally, the slips in items waiting on the holds shelf tend to get pulled out. When this happens, library staff check in items to reprint the slips. Previous to the latest upgrade the holds expiration date would remain the same, but now the expiration date is being calculated based on the NEW date the item is checked in. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 34766] New: Searching for URIs in MARC fields could be improved
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34766 Bug ID: 34766 Summary: Searching for URIs in MARC fields could be improved Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org In Zebra we currently have this index: <index_subfields tag="952" subfields="u"> <target_index>uri:u</target_index> </index_subfields> It seems to be connected only to items.uri however. The generic index name would suggest a broader range. Or perhaps, allow a broader range? We still have one other specific uri indexed: <index_subfields tag="024" subfields="a" condition="marc:subfield[@code='2' and text()='uri']"> <target_index>Identifier-other:u</target_index> </index_subfields> Two popular MARC fields for URIs, 520$u and 856$u are not indexed in a specific index. How about adding them to uri ? Since we do now have uri bound to items, do we need a specific subindex (like item_uri) for that one? Or the other way around, given that uri is already taken, why not add generic_uri or any other (better) new index name? And still elaborating here, a urx search does not really work in Koha. Several special characters in URLs seem to return nothing, since C4/Search does not like them probably. (While the search works in yaz-client.) Should we make it possible to search those just like other text fields too? If I am looking for a record containing a URL like sub.domain.country, why not look for a word in the string like sub or domain? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 34765] New: Display list of Packages for an Agreement as paginated table
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34765 Bug ID: 34765 Summary: Display list of Packages for an Agreement as paginated table 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: ian(a)bywatersolutions.com CC: jonathan.druart+koha(a)gmail.com, jonathan.field(a)ptfs-europe.com, martin.renvoize(a)ptfs-europe.com, matt.blenkinsop(a)ptfs-europe.com, pedro.amorim(a)ptfs-europe.com For Agreements that have a large number of associated Packages, the UI bogs down when fetching the page. Moving to a paginated data table, similar to how Titles are displayed on Packages, would alleviate this slowness, and also provide searchability of Packages from the Agreement details page. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 27849] New: Koha::Token may access undefined C4::Context->userenv
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27849 Bug ID: 27849 Summary: Koha::Token may access undefined C4::Context->userenv Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: mjr(a)software.coop QA Contact: testopia(a)bugs.koha-community.org The _add_default_csrf_params internal function accesses C4::Context->userenv without checking that it has been defined. I think not all of the potential callers of it declare that they require a defined userenv, so we should test and provide defaults for required values if it is not defined, to avoid some "Can't use an undefined value as a HASH reference" HTTP 500 Internal Server Errors. Step to Reproduce: write some code that results in that function being used before a set_userenv call Actual Result: error logged, code exits Expected Result: code runs to completion Additional Information: I am not sure whether this is currently triggered by any released core koha code, or only a few plugins and mods. It looks to me like a bug waiting to happen, based on the documentation, which can be avoided simply. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 15504] Track Patron's Last Activity
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15504 Eric Bégin <eric.begin(a)inLibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC|maksim.sen(a)inlibro.com | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15504] Track Patron's Last Activity
by bugzilla-daemon＠bugs.koha-community.org 12 Sep '23

12 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15504 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |oleonard(a)myacpl.org -- You are receiving this mail because: You are watching all bug changes.

1 0