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

[Bug 29594] New: Koha should print transfer slip when generated a transfer from cancelling a hold on Holds Awaiting Pickup
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '22

27 Feb '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29594 Bug ID: 29594 Summary: Koha should print transfer slip when generated a transfer from cancelling a hold on Holds Awaiting Pickup Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 23092 When one cancels a hold with the Cancel button on Holds Awaiting Pickup (waitingreserves.pl), a transfer may be generated but Koha doesn't prompt you to print a transfer slip. Following the changes in bug 23092, this transfer is generated with both a daterequested and a datesent -- in other words the transfer is immediately considered Sent. Since the transfer is already Sent, checking the item in to generate a new hold slip will generate a "wrong transfer" error message, cancel the first transfer, and generate a new transfer (which does get a slip). I see two options to resolve this: 1: We could generate the transfer as Requested rather than Sent. One would then check the item in to trigger the transfer and get a slip at that point. 2: We could print the transfer slip right away when cancelling the hold. Answer 1 seems simpler and more in line with the directions transfers are going in. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23092 [Bug 23092] Add 'daterequested' to the transfers table -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 29119] New: Search of course reserves doesn't work propertly with accents
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '22

27 Feb '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29119 Bug ID: 29119 Summary: Search of course reserves doesn't work propertly with accents Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Course reserves Assignee: koha-bugs(a)lists.koha-community.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org when a user looks for a course reserve it must write as it is, it doesn't recognize accent variations Example is a course reserve 'evaluación' and the users looks fon evaluacion, the result will be empty. Search course reserves should be accent neutral kindest regards -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 29247] New: Enable staff to see whether a patron has a password or not
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '22

26 Feb '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29247 Bug ID: 29247 Summary: Enable staff to see whether a patron has a password or not Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexander.borkowski(a)kau.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In the staff client at members/moremember.pl, a patron's password is always shown as a number of stars, even for patrons which do not have a password set. While there are provisions to handle unset passwords in koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember.tt these are not effective. It is checked whether the patron.password field is false/empty or not. However, Koha::Patron::store always at least writes an exclamation mark in that field to mark the password invalid. So the field is never really empty, the condition being checked is always false, and hence the staff client never shows that a patron does not have a password set. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 23976] New: limit ill by patron category
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '22

26 Feb '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23976 Bug ID: 23976 Summary: limit ill by patron category Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: hagud(a)orex.es Koha administer could limit article request by patron category at circulation rules, but ill that it could cost more money is open to all type of patron it should be desirable if ill requests could be also limited by patroncategory like article request.. the limitation could be placed at syspref or also at circulation rules... perhaps better at syspref as itemtype could noe match with ill destination -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 29240] New: Flatpickr - error in the console when a date is selected
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '22

26 Feb '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29240 Bug ID: 29240 Summary: Flatpickr - error in the console when a date is selected Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 29239 It seems that there is no date validation. When a date is selected there is a worrying error in the console: Error: Invalid date provided: Tue Oct 19 2021 00:00:00 GMT+0200 (Central European Summer Time) C http://kohadev-intra.mydnsname.org:8081/intranet-tmpl/lib/flatpickr/flatpic… is_valid_date http://kohadev-intra.mydnsname.org:8081/intranet-tmpl/prog/js/calendar_21.0… validate_date http://kohadev-intra.mydnsname.org:8081/intranet-tmpl/prog/js/calendar_21.0… onClose http://kohadev-intra.mydnsname.org:8081/cgi-bin/koha/reserve/request.pl?bib… Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29239 [Bug 29239] [OMNIBUS] Replace jQueryUI's timepicker with flatpickr -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 48

[Bug 19800] New: confusion with the notification for an item "in transfer" during a check-in
by bugzilla-daemon＠bugs.koha-community.org 25 Feb '22

25 Feb '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19800 Bug ID: 19800 Summary: confusion with the notification for an item "in transfer" during a check-in Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi, When we receive a items in transfer, we have two option. We can cancel the transfer with te fonction "Tranfers to receive" or we can do a check-in. But, the notification the notification that appears is confusing. Indeed, in this notification it is written taht the item is "Not Checked out.". The message is misleading because that could be perceived as if the check-in had not worked the first time. The message should be like "Item in transit - now available" or "Item returned from transit - Now available". Like this, the notification would no longer be confusing for library staff. Patrick. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 20609] New: Get back the "Add order to basket" on the basket page
by bugzilla-daemon＠bugs.koha-community.org 25 Feb '22

25 Feb '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20609 Bug ID: 20609 Summary: Get back the "Add order to basket" on the basket page Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: patrick.robitaille(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Hi, Before the 16.11 version of Koha, when we opened a basket we had acces to the form "Add order to basket". Now we have to clik on "add to basket". This form was convenient and avoided an extra click. It could be nice to have this form directly from the basket without havind to do an extra clic. Patrick. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 29703] New: Simplify GetBranchItemRule
by bugzilla-daemon＠bugs.koha-community.org 25 Feb '22

25 Feb '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29703 Bug ID: 29703 Summary: Simplify GetBranchItemRule Change sponsored?: --- Product: Koha Version: master 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Possibly we should work towards removing this sub, but for now we should use get_effective_rules rather than calling get_effective rule three times -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 27627] New: Fix invalid HTMl in OPAC results XSLT: change spans to divs
by bugzilla-daemon＠bugs.koha-community.org 25 Feb '22

25 Feb '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27627 Bug ID: 27627 Summary: Fix invalid HTMl in OPAC results XSLT: change spans to divs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: kyle(a)bywatersolutions.com, lucas(a)bywatersolutions.com, testopia(a)bugs.koha-community.org Depends on: 27613 There are many <span>s in MARC21slim2OPACResults.xsl which contain block-level elements, which is invalid. There's no reason for these not to be converted to <div>s. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27613 [Bug 27613] Pipe separated online resource links are hard to customize -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 29845] New: Styling OverDrive buttons is difficult
by bugzilla-daemon＠bugs.koha-community.org 25 Feb '22

25 Feb '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29845 Bug ID: 29845 Summary: Styling OverDrive buttons is difficult 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 Some librarians would like style the buttons on the Dverdrive results page differently from one another. I realized this is somewhat difficult to do at the moment because each of those buttons are built by JavaScript and don't include a unique class name or ID. Those buttons are the check-in, check-out, place hold, cancel hold, and download as buttons. If they had an ID it would make it easy to style them. -- You are receiving this mail because: You are watching all bug changes.

1 19