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

[Bug 27882] New: Move external search results links out of page heading
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '21

09 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27882 Bug ID: 27882 Summary: Move external search results links out of page heading Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Depends on: 27740 When results are found in OverDrive, Recorded Books, or OpenLibrary collections the information is appended to the search results <h1>. I think the should be added just after the <h1> because they're not really part of the heading information. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27740 [Bug 27740] Accessibility: OPAC - Headings should have correct tags and hierarchy -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 26838] New: Improve styling of checkin message
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '21

09 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26838 Bug ID: 26838 Summary: Improve styling of checkin message 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 112596 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=112596&action=e… Checkin message box When an item type has a checkin message of the type "message" (rather than "alert"), the styling of the box is weird. The box is blue, but the background of the text is yellow. To replicate: 1) Go to Administration > Item types 2) Edit an item type and include a checkin message, the checkin message type should be "message" 3) Check in an item of that type I attached a screen capture of the blue/yellow message. In the manual, we can see what it used to look like : https://koha-community.org/manual/20.11/en/html/_images/itemtype-msg.png -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 15969] New: Allow use of Template Toolkit syntax for Phone Notices
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '21

09 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15969 Bug ID: 15969 Summary: Allow use of Template Toolkit syntax for Phone Notices 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org By allowing the use of Template Toolkit for generating the outgoing Talking Tech CSV files, we can give libaries more control over the data they send to Itiva. This enhancement would also make it possible to use the script for other services since the output is no longer fixed to a single format. -- You are receiving this mail because: You are watching all bug changes.

1 75

[Bug 21091] New: Move add item template JavaScript to a separate file
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '21

08 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21091 Bug ID: 21091 Summary: Move add item template JavaScript to a separate file Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org I would like to modify the add item template (additem.tt) to move JavaScript from the <head> to separate files: cataloging_additem.js and cataloging_additem.inc (for defining translatable strings used in the js). -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 28482] New: Floating point math prevents items from being returned
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '21

08 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28482 Bug ID: 28482 Summary: Floating point math prevents items from being returned Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We have seen this before, cropping up again. To recreate: 1 - Add a processing fee of 15 to an itemtype 2 - Add an item of that type, set the replacement fee to 12.63 3 - Set MarkLostItemsAsReturned to 'On payment' only 4 - Set WhenLostChargeReplacementFee to 'Charge' 5 - Checkout the item to a patron 6 - Mark the item lost 7 - Reload patron and confirm they are charged 27.63 8 - Go to accounting, pay amount, pay 27.63 9 - Item is still lost and not returned -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 28503] New: When ReservesControlBranch set to "patron's home library" and Hold policy set to "From home library" all holds are allowed
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '21

08 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28503 Bug ID: 28503 Summary: When ReservesControlBranch set to "patron's home library" and Hold policy set to "From home library" all holds are allowed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Hold requests 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 In C4::Reserves::CheckReserves we have: next if (($branchitemrule->{'holdallowed'} eq 'from_home_library') && ($branch ne $patron->branchcode)); Where $branch is the return of my $branch = GetReservesControlBranch( $item->unblessed, $patron->unblessed ); When ReservesControlBranch is set to "patron's home library" this boils down to: $patron->branchcode ne $patron->branchcode which will never be true In all other locations we ue ReservesControlBranch to fetch the rule, but always compare the item's homebranch to the patron's branchcode: 543 if ( $branchitemrule->{holdallowed} eq 'from_home_library' 544 && $borrower->{branchcode} ne $item->homebranch ) 545 { 546 return { status => 'cannotReserveFromOtherBranches' }; 547 } 1409 || $branchitemrule->{holdallowed} eq 'from_home_library' && $param->{patron}->branchcode ne $i->homebranch -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 45

[Bug 25189] New: Make AutoCreateAuthorities less of a footgun with LinkerModule: Default
by bugzilla-daemon＠bugs.koha-community.org 07 Jul '21

07 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25189 Bug ID: 25189 Summary: Make AutoCreateAuthorities less of a footgun with LinkerModule: Default Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If you read every word of the description of AutoCreateAuthorities in the system prefs page, and then read every word about it in the manual, even if you also read every word in the description and in the manual about LinkerModule, you'll have no idea that by turning on AutoCreateAuthorities without changing LinkerModule from its default value of Default, you've just given yourself infinite authority duplicates. The behavior of LinkerModule: Default is to link a field in a bib to an authority when there is one and only one matching authority record. Without AutoCreateAuthorities, that means if you have zero matches or two or more matches, the field is unlinked. Fine, no problem. With AutoCreateAuthorities on, the behavior is that if there are zero matches, an authority record is created, if there is one match, the field is linked to that existing authority record, if there are two matches a third duplicate authority is created, and if there are three matches, a fourth duplicate match is created, and if there are 2661 matches, a 2662nd duplicate match is created (that being how many authority records my system had for the genre Thrillers (Fiction) when I noticed this behavior). Two ways to not create infinite duplicates occur to me: Change what a LinkerModule returns, so it returns the match, whether it was a fuzzy match, and also whether more than one match was found, so that in the AutoCreateAuthorities case when more than one was found it can be left unlinked rather than creating another duplicate, or, Have C4/Linker/Default.pm check whether AutoCreateAuthorities is on, and if it is and $behavior isn't either first or last, just force it to first rather than creating infinite duplicates. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 29

[Bug 22880] New: Convert opacheader system preference to news block
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '21

06 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22880 Bug ID: 22880 Summary: Convert opacheader system preference to news block Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 22318 Target Milestone: --- Building on 22318, the opacheader system preference should be converted to a Koha news block. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22318 [Bug 22318] Extend Koha news feature to include other content areas -- You are receiving this mail because: You are watching all bug changes.

1 99

[Bug 28621] New: Make circulation conditions visible for patrons in patron account
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '21

06 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28621 Bug ID: 28621 Summary: Make circulation conditions visible for patrons in patron account Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement 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 It would be a nice feature if it was possible to display the circulation conditions, like loan periods, number of possible renewals etc. for a patron in the patron account. The display should take the home library and patron category into account, so it doesn't have to be maintained manually and is as specific as possible, leaving anything out that doesn't apply to the patron looking at it. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 21325] New: Should we still allow user and password via GET parameters?
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '21

06 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21325 Bug ID: 21325 Summary: Should we still allow user and password via GET parameters? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org In testing bug 13779, I just noticed that an URL like this works: https://[your_domain]/cgi-bin/koha/opac-reserve.pl?biblionumber=[some_bibli… Obviously, we should not expose credentials like that. But it raises the question: should we allow it then? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32