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

[Bug 20894] New: Feature request: pass barcode width and height as parameters to /svc/barcode
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '23

28 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20894 Bug ID: 20894 Summary: Feature request: pass barcode width and height as parameters to /svc/barcode Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org /svc/barcode does not currently accept width and height parameters, even though GD::Barcode does. We should allow these to be passed in. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 24129] New: Add ability to configure some indexes to not autotruncate
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '23

27 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24129 Bug ID: 24129 Summary: Add ability to configure some indexes to not autotruncate Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com To Test: - Set QueryAutoTruncate to Automatically - Set search engine to Zebra - search for sn:1 - Confirm you only get biblionumber 1 in your results - Set search engine to Elastic - search for sn:1 - confirm you get bibs 1, 10, 11, 100, etc Zebra apparently knows to ignore autotruncate for some instances. We should at least maintain that behavior. It would probably be good to go a step further and make it configurable per index in our search engine config. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 23059] New: reserves_stats.pl needs overhaul
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '23

26 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23059 Bug ID: 23059 Summary: reserves_stats.pl needs overhaul Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- This bug is sort of a catch-all for changes that need to be made to the holds statistic wizard, reserves_stats.pl Two big issues: - By default, the wizard sets a value for items.homebranch and items.holdingbranch. That means it unexpectedly cuts out all bib-level holds and gives no clear indication that it's done so. You *can* change home and holding branch to not limit, but it's not intuitive. - The wizard splits holds into 5 statuses (Placed, Processed, Pending, Satisfied, and Cancelled) that aren't used anywhere else in Koha. These statuses aren't explained without diving into the code and don't match how we otherwise divide and talk about holds. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 25299] New: Date not showing on Details page when patron is going to expire
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '23

25 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25299 Bug ID: 25299 Summary: Date not showing on Details page when patron is going to expire Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The date doesn't show on the Details page when the patron is going to expire. It does appear on the "Check out" page, however. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 17228] New: Make two versions of SIPconfig.xml identical
by bugzilla-daemon＠bugs.koha-community.org 23 Oct '23

23 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17228 Bug ID: 17228 Summary: Make two versions of SIPconfig.xml identical Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Packaging Assignee: magnus(a)libriotech.no Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net We have two versions of SIPconfig.xml: etc/SIPconfig.xml debian/templates/SIPconfig.xml The former has been updated with some changes to the possible configuration of SIP2 servers, e.g. by bug 15006. The latter has not been updated with the same information. Since debian/templates/SIPconfig.xml contains no special placeholders or variables, this bug proposes to simply copy etc/SIPconfig.xml to debian/templates/SIPconfig.xml, so that admins using the packages will see an up-to-date SIP2 config example when they have enabled SIP2 for a site. -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 18094] New: Patron search filters are broken by searchable attributes
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '23

20 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18094 Bug ID: 18094 Summary: Patron search filters are broken by searchable attributes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When using searchable patron attributes they seem to be added to all searches as a contain To recreate: Add a new patron attrbute and mark it searchable Populate a new patron with 'potato' in that field Add/edit another patron to have email potato(a)invalidemail.com' Perform a patron search with filters 'Email' and 'Starts with' and query 'potato' You will see both patrons in your results Remove the potato email Perform search again You will be directed to the patron containing the potato attribute -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 25023] New: Claims Returned uses US date format (mm/dd/yyyy) in the Claims tab when UK date format (dd/mm/yyyy) is selected
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '23

20 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25023 Bug ID: 25023 Summary: Claims Returned uses US date format (mm/dd/yyyy) in the Claims tab when UK date format (dd/mm/yyyy) is selected Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sally.healey(a)cheshiresharedservices.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To replicate: 1. Turn on the Claims Returned feature by setting ClaimReturnedLostValue to 1 2. Change Koha's date format to UK format by setting DateFormat to dd/mm/yyyy 3. Check an item out to a patron 4. Note that the dates in the Check out screen are in UK format - dd/mm/yyyy 5. Claim the item as returned 6. Note that in the Claims tab, the date for 'Created on' is in US format mm/dd/yyyy 7. In the Claims tab, use the Actions button to mark the item as resolved. 8. Note that the 'Updated on' and 'Resolution' columns both show the date in US format - mm/dd/yyyy 9. Reload the Check out page for the patron and note that the 'Return claims' column correctly shows the date in UK format - dd/mm/yyyy -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 21577] New: Enable Koha to act as Shibboleth identity provider
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '23

19 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21577 Bug ID: 21577 Summary: Enable Koha to act as Shibboleth identity provider Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org For us it is important now, as we are going to append our Koha to national project which aims to enable users to use "all" libraries from one place. Maybe this could be implemented using Net::SAML2::IdP -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 23846] New: bad iso 2709 record silently results in broken marcxml
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '23

19 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23846 Bug ID: 23846 Summary: bad iso 2709 record silently results in broken marcxml Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: dominique(a)leducq.net QA Contact: testopia(a)bugs.koha-community.org Created attachment 94419 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=94419&action=ed… iso 2709 with problematic record The (UNIMARC) ISO 2709 record in the attached file (26080509.txt) seems to have a problem : the 009 field should contain an ARK identifier but seems to be something else, with a subfield separator in it. When imported into koha, it is said to be imported all right, but when trying to access the notice, we get the following error message : Invalid data, cannot decode object (id=9865, format=marcxml, schema=UNIMARC) Investigating, I found that the marcxml in biblio_metadata.metadata is broken : the content of the <controlfield tag="009"> element is a verbatim copy of the 009 field, including the (non-printable, 0x1F) subfield separator (cf line 9 of the attached marcxml) When I deleted this element in the database, all seems to work fine. I think either the record should be rejected alltogether, with an explicit error message, or the erroneous field should be droped. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 24574] New: Broken MARC records cause "invalid data, cannot decode object" on ISBDdetail and MARCdetail pages.
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '23

18 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24574 Bug ID: 24574 Summary: Broken MARC records cause "invalid data, cannot decode object" on ISBDdetail and MARCdetail pages. Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: rudolfbyker(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Broken MARC records cause "invalid data, cannot decode object" on ISBDdetail and MARCdetail pages. Although this is fixed on the /cgi-bin/koha/catalogue/detail.pl page (see Bug #23425 ), it's still not handled gracefully on these pages: /cgi-bin/koha/catalogue/ISBDdetail.pl /cgi-bin/koha/catalogue/MARCdetail.pl Use case: Some of our staff have to update books. They use "cataloging search", enter the barcode, then click the title of the book. This takes them directly to the MARCdetail page. To fix the MARC data, they need to work around the problem by editing the URL and replacing "MARCdetail.pl" with "detail.pl". Since most of our staff is not very technically apt, this is a problem. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 29