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

[Bug 25877] New: Error libraryNotPickupLocation when placing a hold if logged in branchcode is not a pickup location
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '20

31 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25877 Bug ID: 25877 Summary: Error libraryNotPickupLocation when placing a hold if logged in branchcode is not a pickup location Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com On the staff side, if the librarian is logged in as a branch that is not a hold pickup location, that branch is still used as the default pickup location for the rules, resulting in the item not holdable reason libraryNotPickupLocation, while the pulldown shows the first branch that can actually be used as a pickup location. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 25411] New: Plugin routes cannot have annonymous access
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '20

31 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25411 Bug ID: 25411 Summary: Plugin routes cannot have annonymous access Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com This is a consequence of a big change introduced by bug 25045 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 35

[Bug 21733] New: Loanperiod shortened when there are hold, even if Library transfer limits prevents prebents the item from fulfilling a hold
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '20

31 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21733 Bug ID: 21733 Summary: Loanperiod shortened when there are hold, even if Library transfer limits prevents prebents the item from fulfilling a hold 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: klas.blomberg(a)skovde.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Another bug related to Library transfer limits Scenario: There is an item at library A There is another item at library B, and several holds for that title for pickup at library B. UseBranchTransferLimits is set to enfarce, so items should not be transferred from library A to library B. decreaseLoanHighHolds is set to enable, so loan periods are shortened when there are several holds. In this case it seems reasonable that the loanperiod at library A should not be shortened, irrespective of the hold, as that item is not supposed to be transfered and fill the hold -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 25569] New: decreaseLoanHighHolds will decrease loan too often
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '20

31 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25569 Bug ID: 25569 Summary: decreaseLoanHighHolds will decrease loan too often 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The routine checkHighHolds uses CanItemBeReserved to count the number of available items, however, since we must pass the current borrower and check their ability to hold the items, many of the checks in that routine are not necessarily applicable. Additionally the count of holds on the record may be inaccurate: 1 - The borrowers own holds shouldn't be counted - if I am getting several books for a book group or a number of dvds in a set I shouldn't shorten my own loan period 2 - My hold limits may prevent me from placing more holds, but are not relevant in determining if the item is in high demand 3 - My fines may prevent me from placing holds, but shouldn't shorten my loan period 4 - If 6 patrons from another library who can't hold my libraries items have holds on their libraries item, my loan period shouldn't be decreased as they can't get my item anyways 5 - etc. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 24134] New: improve 008 framework flexibility (autogenerate date)
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '20

30 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24134 Bug ID: 24134 Summary: improve 008 framework flexibility (autogenerate date) Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: philip.bertling(a)rbg.vic.gov.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When creating a framework for a form type other than book, it does not seem possible to autogenerate the date correctly. The 00-05 ‘date entered on file’ in the 008 field, can almost be auto-filled by using the code <<YYYY>><<MM>><<DD>>. However it doesn’t quite work because the 008 field expects a 6 digit date [YYMMDD] – this code inserts an 8 digit date [YYYYMMDD]. e.g. <<YY>><<MM>><<DD>> b at |||p |||||00| eng d = entered on the date <<29>><<11>><<25>> This creates the following data in a record: <<YY>>1125 b at |||p |||||00| eng d Is it possible to make this date code work to insert a date comprising 6 digits? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 21504] New: enumchron shows as 0 in pdf
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '20

30 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21504 Bug ID: 21504 Summary: enumchron shows as 0 in pdf Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 80141 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=80141&action=ed… bibrecord for testing enumchron issue When printing a spine label with itemcallnumber and enumchron, the pdf shows the one or two digit enumchron value as 0, but the CSV and XML formats show the correct enumchron value. Have replicated in 18.05. Changing item type, bib record, enumchron value, etc all result in same scenario. To replicate, create a template and layout: Template: US inches Page height 11 Page width 8.5 Label width 1.625 Label height 1 Top page margin .5 Left page margin .25 Top text margin .3 Left text margin 1.25 Number of columns 5 Number of rows 10 Gap col 0 Gap row 0 No profile Layout: Biblio 1 itemcallnumber 2 enumchron Split call numbers Text: center Font: Times-Bold Font size 12 Create a label batch with an enumchron, marc file for the record I was using is attached. View the pdf and see the enumchron shows 0. View the CSV and XML and see the correct enumchron shows. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 25878] New: Schema incorrectly describes course_items fields
by bugzilla-daemon＠bugs.koha-community.org 30 Aug '20

30 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25878 Bug ID: 25878 Summary: Schema incorrectly describes course_items fields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org On the schema page for the course_items table we include this comment on course_items.itype: "new itemtype for the item to have while on reserve (optional)" We have comparable notes for ccode, holdingbranch, and location. That comment is not strictly correct. While a course is active, these fields in course_items will hold the items original values. If the course is marked inactive and the item's original values are returned to the items table, then the fields in course_items will hold the values that this item had while on reserve. At this time I do not have alternate wording that explains this succinctly enough to put into the schema comment. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 22939] New: Hard due date should block renewals when it wouldn't extend the due date
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '20

28 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22939 Bug ID: 22939 Summary: Hard due date should block renewals when it wouldn't extend the due date 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: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- It seems like it would make sense for renewals to be blocked if there is a hard due date set equal to or before the time the renewal would normally allow it would block renewing. aka: School branch (branch a) is closing for the summer. They set their hard due date to be 5/17/19. Their checkout period is 14 days, they allow 1 renewal, and the renewal is 14 days. Patron at branch b (not closing for the summer) gets a book from branch a on hold and checks it out 5/3/19. Due date is 5/17/19 and it says they have 1 renewal on the item. There is no warning about a hard due date and it looks like they should be able to renew it. On 5/16/19 they come in and want to renew the item, as their account says there is a renewal available. When the item is renewed it only gains 1 day. The patron has no indication why it is renewing differently than before. If the renewal was blocked (box grayed out or changed to zero) staff could preserve the previous renewal information without as much confusion for patrons. Lisette -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 22269] New: Pay amount - modal confirmation of amount to return to patron should be suppressed if attempting to pay (not collect) more than owed
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '20

28 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22269 Bug ID: 22269 Summary: Pay amount - modal confirmation of amount to return to patron should be suppressed if attempting to pay (not collect) more than owed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 Target Milestone: --- To recreate: 1 - Add a fine or find a patron owing money 2 - Go to pay fines, pay amount 3 - Set amount to be paid higher than amount owed 4 - Set amount collected higher than amount paid 5 - Note you get a confirmation modal, confirm 6 - payment fails Expected action would be that modal is prevented or notifies user that they are trying to pay more than owed. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 18251] New: SCO alerts - need a trigger for successful checkouts
by bugzilla-daemon＠bugs.koha-community.org 26 Aug '20

26 Aug '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18251 Bug ID: 18251 Summary: SCO alerts - need a trigger for successful checkouts Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Failed checkouts on the sco can be triggered by presence of alert, however, we have no feedback for a successful checkout. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 63