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

[Bug 35841] New: Update text of 'Cancel' hold button on OPAC
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '24

09 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35841 Bug ID: 35841 Summary: Update text of 'Cancel' hold button on OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org On the OPAC, if a hold is waiting one can request to cancel it. However, the wording of the button is misleading. It reads 'Cancel', indicating to patrons that there hold has been canceled. It should be 'Request to cancel'. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 35817] New: Wrong hint on patron's category when batch update patron
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '24

09 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35817 Bug ID: 35817 Summary: Wrong hint on patron's category when batch update patron Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Tools Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 20443 When a patron's attribute is limited to a given patron's category, the batch patron modification tool will display a hint "This attribute will be only applied to the patron's category %s". But this is followed by the description of the patron's attribute, not the patron's category. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20443 [Bug 20443] Move C4::Members::Attributes to Koha namespace -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 35461] New: Renew All 66 SIP server response messages produce HASH content in replies
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '24

09 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35461 Bug ID: 35461 Summary: Renew All 66 SIP server response messages produce HASH content in replies Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: lmstrand(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org "Renew All" -function aka. 65-66-messages work like this: 66-return messages has renewed items in BM-fields and non-renewables go into BN-fields. If all items were renewable, then the reply message looks like: Reply: 13.07.2022 10:06:17:530 OUTESTI1 6610005000020220713 100616AOOUPK|BM564N15977171|BM564N09203960|BM564N23261720|BM564N25161958|BM564N23455012|C4::SIP::SIPServer=HASHC4::SIP::SIPServer=HASHAY6AZCEFE If items include renewables and non-renewables, the response includes the renewed items first, then a HASH mixed into the first BN-field, then rest of the renewed ones like they should show in BN-fields and after that, anohter HASH: 13.07.2022 14:41:32:610 OUTESTI1 6610003000420220713 144130AOOUPK|BM564N23455012|BM564N23261720|BM564N25161958|C4::SIP::SIPServer=HASHBN564N09203960|BN564N04191259|BN564N15977171|BN564N13788332|C4::SIP::SIPServer=HASHAY8AZC7C5 If all loans were unrenewable (this test included just one item), you first get a HASH in a BN-field, and another at the end. 13.07.2022 14:49:00:037 OUTESTI1 6610000000120220713 144858AOOUPK|C4::SIP::SIPServer=HASHBN564N19874533|C4::SIP::SIPServer=HASHAY9AZDD3B Our self checkout/checkin machine can handle/parse these reply messages correctly, but this might not be the case with all self checkout/checkin devices. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 32593] New: Item search option location breaks with only one location defined
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '24

09 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32593 Bug ID: 32593 Summary: Item search option location breaks with only one location defined Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When there is only one location (LOC) configured, the search option for locations on item search is not generated correctly. It shows the 'all locations' option and then 3 empty (no description) entries: <select id="location" name="location" multiple="multiple" size="4"> <option value="" selected="selected"> <span>All locations</span> </option> <option value="REF"></option> <option value="Reference"></option> <option value="Reference"></option> </select> As soon as a second location is configured, the list will be generated correctly. To test: * delete all LOC entried, but one, I left REF in the sandbox * Go to item search * Verify that only 'all locations displays' with 3 clickable empty entries below * Add another LOC entry * Verify the list now works again -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 33842] New: Search for authid not returning right results with QueryAutoTruncate ON
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '24

09 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33842 Bug ID: 33842 Summary: Search for authid not returning right results with QueryAutoTruncate ON 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: adolfo.rodriguez(a)xercode.es Conditions to replicate this bug: 1) Preference QueryAutoTruncate activated 2) Have authorities with low authids 3) ElasticSearch, though it should also happen with Zebra. You can try it on this demo, it's on the master branch. Intranet: https://intranet.koha-community.es OPAC: https://catalog.koha-community.es/ User demo/demo The following searchs return different results: 1) Search in the catalog an:1 The QueryAutoTruncate adds * so it returns all the biblios that use authorities with authids that begin with 1, which are 81. That doesn't make sense as those authorities have nothing in common. https://intranet.koha-community.es/cgi-bin/koha/catalogue/search.pl?q=an%3A1 2) The authority with the id 1 is Mika Ninagawa, if you search her in the Authorities module, it says the authority is being used in two records, which is correct. https://intranet.koha-community.es/cgi-bin/koha/authorities/authorities-hom… 3) In the authority detail, Koha makes the same query as in point 1 so it appears it's being used in 81 records. https://intranet.koha-community.es/cgi-bin/koha/authorities/detail.pl?authi… I think this disparity in results can be confusing for librarians and readers, as they won't understand why Koha is recovering records that are unrelated to the author/subject... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 26978] New: Add item type criteria to batch extend due date tool
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '24

09 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26978 Bug ID: 26978 Summary: Add item type criteria to batch extend due date tool Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org In the Change due date plugin by inLibro, there is a possibility of choosing specific item types to extend due dates. I think the original purpose of the batch extend due date tool was for COVID and the purpose was to extend everything regardless, as the libraries were closed. However, it would be nice if we could discontinue de plugin in favour of the native tool. But that would require that the native tool have all the options that the plugin has. https://inlibro.com/en/changeduedate-instructions/ One example of use case would be where a school would want to extend loans for textbooks, because the semester was extended, but not the other types of items. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 32166] New: When adding to a basket from a staged file we may use the wrong inputs
by bugzilla-daemon＠bugs.koha-community.org 08 Feb '24

08 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32166 Bug ID: 32166 Summary: When adding to a basket from a staged file we may use the wrong inputs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org On addorderiso2709.pl we loop over the records in the staged batch: for my $biblio (@$biblios){ $biblio_count++; skipping any not selected, which inlcudes any already imported: next if not grep { $_ eq $$biblio{import_record_id} } @import_record_id_selected; Later we use that count to find the inputs: my @homebranches = $input->multi_param('homebranch_' . $biblio_count); The problem being that if a record is already imported, our count increases, but the input on the page still counts from 1 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 35912] New: Item prices not populating order form when adding to a basket from a staged file
by bugzilla-daemon＠bugs.koha-community.org 08 Feb '24

08 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35912 Bug ID: 35912 Summary: Item prices not populating order form when adding to a basket from a staged file Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 33170 refactored addorderiso2709 to make MarcItemFieldsToOrder easier to adjust, however, it missed that when listing we renamed 'price' as 'itemprice' so prices for items are not being populated -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 29930] New: Auth with LDAP: Update tag leads to unwanted updates
by bugzilla-daemon＠bugs.koha-community.org 08 Feb '24

08 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29930 Bug ID: 29930 Summary: Auth with LDAP: Update tag leads to unwanted updates 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: janik.hilser(a)systemli.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I have observed that as soon as the update tag is set to true in koha-config.xml, the cardnumber is also updated on every login, even if it is not in the mappings. After a login the cardnumber is equal to the userId, but according to log entries it is empty in between. I could see this in the log entry that is generated in line 214 of the Auth_with_ldap.pm. Maybe line 262 of the same file has something to do with it? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 42

[Bug 35260] New: Review batch checkout page
by bugzilla-daemon＠bugs.koha-community.org 08 Feb '24

08 Feb '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35260 Bug ID: 35260 Summary: Review batch checkout page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The back checkout page in the staff interface appears a little unstructured at the moment and could look a little nicer. The name of the patron on top doesn't seem right here compared to other pages and the long labels break onto multiple lines in English. Hard due date seems mislabelled and should probably be "Specify due date" to avoid confusion with the hard due dates in the circulation rules. -- You are receiving this mail because: You are watching all bug changes.

1 11