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

[Bug 28269] New: Order search should be possible with ISSN too
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '23

14 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28269 Bug ID: 28269 Summary: Order search should be possible with ISSN too Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: inkeri.hakulinen+bugz(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org At the order search ( koha/acqui/histsearch.pl ) there should be a possibility to search orders by ISSN. Serials don't have an ISBN, but ISSN. Often the serial names are long and similar to each other, so the short and exact searching by ISSN should be an option, too. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 30980] New: Make patron selection more consistent
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '23

14 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30980 Bug ID: 30980 Summary: Make patron selection more consistent Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We have a number of places where one can select a patron as part of a process... but these selects vary wildly.. some are 'autocomplete', others allow for full search. I proposed using select2 consistently for the forms one's when reviewing bug 30578. It's worth investigating. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 30578] New: We should drop circ/ysearch.pl in preference to using the REST API's
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '23

14 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30578 Bug ID: 30578 Summary: We should drop circ/ysearch.pl in preference to using the REST API's 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 As the title says, we should really stop using ysearch.pl for autocomplete.. it doesn't fully respect the various restrictions and the REST API is well developed now. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 51

[Bug 26346] New: Add option to make a public list editable by library staff only
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '23

14 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26346 Bug ID: 26346 Summary: Add option to make a public list editable by library staff only Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: bolshawh(a)parliament.uk QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Currently there are three options for who can add or remove items from a public list: - "Nobody" - "Owner Only" - "Anybody seeing this list" It would be useful to have a "staff only" option as well so that all users could see the list but only library staff could add or remove items from the list. At the moment we have to either rely on a single member of staff to update and maintain a public list or give everyone edit rights and risk users accidentally or deliberately editing a list. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 213

[Bug 23079] New: Checkouts page broken because of problems with date calculation (TZAmerica/Sao_Paulo)
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '23

13 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23079 Bug ID: 23079 Summary: Checkouts page broken because of problems with date calculation (TZAmerica/Sao_Paulo) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation 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 Target Milestone: --- We keep having issues especially with the TZ America/Sao_Paulo in certain areas of Koha. The most recent error was the checkouts page showing "Internal server error" resolving to: Invalid local time for date in time zone: America/Sao_Paulo The date expiry of this patron was: 2019-12-03 Changing the date expiry date to be a day later (2019-12-04) fixed the issue. The patron currently has no checkouts. I am not sure yet if other settings factor into this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 30162] New: XSLT has broken link for traced series because of OPAC/staff interface confusion
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '23

11 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30162 Bug ID: 30162 Summary: XSLT has broken link for traced series because of OPAC/staff interface confusion 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org In the Utils file for the OPAC XSLT is a hardcoded link for the staff interface, which means the link is broken in OPAC and generates an ugly error when clicked: https://git.koha-community.org/Koha-community/Koha/src/branch/master/koha-t… <xsl:when test="$UseControlNumber = '1' and marc:subfield[@code='w']"> <a href="/cgi-bin/koha/catalogue/search.pl?q=rcn:{marc:subfield[@code='w']}"> <xsl:call-template name="chopPunctuation"> <xsl:with-param name="chopString"> <xsl:call-template name="subfieldSelect"> <xsl:with-param name="codes">a_t</xsl:with-param> </xsl:call-template> </xsl:with-param> </xsl:call-template> </a> It should use the searchurl variable used in other spots of the same template. Also it doesn't work for me with the {} - I believe they might only work with Elasticsearch or ICU? Removing them makes the link behave correctly. The record for testing should have these fields and USeControlNumber needs to be set to use: 490 _1 _aKirche, Wirtschaft, Gesellschaft _v1 830 _0 _aKirche, Wirtschaft, Gesellschaft _v1 _w(DE-627)577593544 -- You are receiving this mail because: You are watching all bug changes.

1 35

[Bug 21255] New: memberetnry.pl is missing categories in the Category pull-down list
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '23

08 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21255 Bug ID: 21255 Summary: memberetnry.pl is missing categories in the Category pull-down list Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cnighswonger(a)foundations.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In some instances, when editing a patron, the Category pulldown under the "Library management" section is missing categories. I'm at a loss as to how to accurately describe the problem, but here goes: 1. The given patron's category shows up correctly on every other screen. 2. Navigating to the Patron Detail screen and selecting the edit option for Library use section results in the Modify Patron screen. 3. The heading on the Modify Patron screen displays the correct category. 4. However, the Category pulldown does not. 5. Furthermore, the pulldown does not even contain the correct category for the given patron. Doing a bit of looking around turned up a few things which may or may not be related. For the given patron: 1. The problem seems to be with the child category. 2. The Koha::Patron::Categories object may contain missing or incorrect category information. Here is a snip of the object returned for the 'C' category type by this line http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=members/memberent… 'attrs' => { 'bind' => [], 'join' => 'categories_branches', 'order_by' => [ 'categorycode' ], 'where' => { 'category_type' => 'C', 'categories_branches.branchcode' => [ 'JL', undef ] }, 'alias' => 'me' }, 3. The underlying data appears to be sound. 4. This was not a problem prior to upgrading a month ago. Unfortunately, I'm not sure what version this system was at prior to the upgrade. Maybe this will get the discussion started and someone with more knowledge of this area of the code can give some direction to it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 29755] New: SIP2 code does not correctly handle NoIssuesChargeGuarantees or NoIssuesChargeGuarantorsWithGuarantees
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '23

07 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29755 Bug ID: 29755 Summary: SIP2 code does not correctly handle NoIssuesChargeGuarantees or NoIssuesChargeGuarantorsWithGuarantees Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major 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 The sip code always checks noissuescharge as the limit for fines, never the other possible limits -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 23580] New: Add C4::Context->yaml_preference
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '23

06 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23580 Bug ID: 23580 Summary: Add C4::Context->yaml_preference 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org I propose to add a way to retrieve the decoded YAML from (YAML) system preferences. This way we don't need to write code in vain for decoding them in-place. Also, I propose we move pipe-separated sysprefs into YAML lists. This raised on reviewing 22996. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 28609] New: Popularity sort is broken
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '23

05 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28609 Bug ID: 28609 Summary: Popularity sort is broken Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de Bug 13976 reported that the sort by popularity was only alphabetic and not numeric. I cannot confirm that... because now it's broken. When sorting by popularity the result list is sorted by biblionumber instead, which is the usual fallback when values are identical. When searching issues:74 or popluarity:74 records where the items have this number of issues are found correctly. So it appears the index is there and filled, but somehow not working when used for sorting? Verified in 18.11 and 20.11. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4