April 2023 - Koha-bugs - lists.koha-community.org

[Bug 23550] New: Not possible to add multiple patron restrictions in memberentry.pl
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '23

09 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23550 Bug ID: 23550 Summary: Not possible to add multiple patron restrictions in memberentry.pl 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When editing a patron record in memberentry.pl, you have a link to "Add manual restriction", but after you click and add, there is no link to add another. You have to save and edit again, or you can add multiple restrictions straight from circulation.pl or moremember.pl. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 23501] New: Drag-and-drop hold reordering in the staff client
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '23

09 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23501 Bug ID: 23501 Summary: Drag-and-drop hold reordering in the staff client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Blocks: 16421 It would be nice to be able to use drag-and-drop to reorder holds in the staff client. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16421 [Bug 16421] Move hold edit actions into dropdown menu -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 23498] New: Broken links to bibs when placing holds on multiple records and a hold exists on at least one record
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '23

09 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23498 Bug ID: 23498 Summary: Broken links to bibs when placing holds on multiple records and a hold exists on at least one record Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: jrobb(a)sekls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 92441 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=92441&action=ed… Screenshot of broken link When placing holds on multiple records at once from a list of search results in the staff client, if one of the selected records already has a hold, the "Confirm Holds" page where you choose a patron will list each record and the existing holds. The links to the bib records on that page are incomplete. To replicate the issue: 1. Run a search that gives multiple results 2. Place an individual hold on the first record 3. Repeat the search 4. Use the check boxes to select 2 or more records, including the record with a hold 5. Click 'Place Hold' at the top of the results 6. The next page should have a box to search for the patron, and list out the records you selected and any holds on those records. Hover over the title of the record and notice that the URL for each is lacking a bib number at the end. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 23480] New: Check out screen (circulation.pl)
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '23

09 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23480 Bug ID: 23480 Summary: Check out screen (circulation.pl) 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Wondering why we have a column for renewal and a column for check in? Couldn't we: * Have a single check box? You can't renew and check in. * Put renewal information in the due date or checked out on column? * Have either multiple action buttons or a single selectable action button? I guess, theoretically, one could renew and check in at the same time with the current setup. I'm wondering if anyone actually does this? I would personally find it confusing, and I would be nervous about doing both at the same time. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 23454] New: Fine for the previous overdue may get overwritten by the next one
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '23

09 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23454 Bug ID: 23454 Summary: Fine for the previous overdue may get overwritten by the next one Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hemantharao.kr(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The fine for the previous overdue is getting overwritten by the next one in Koha version 18.11 in case of renewal with overdue, this is happening even after updating bug fix patch no. 17135. Please help me out with this error. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 22018] New: Add an option to 'AllowEarlyRenewal' to enable users to renew before the autorenew date
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '23

08 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22018 Bug ID: 22018 Summary: Add an option to 'AllowEarlyRenewal' to enable users to renew before the autorenew date 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- There are occasions where a patron may want to manually renew an item before the date on which an autorenewal would take place; for example, if they are going on holiday they may wish to renew all their items before they leave to prevent them accruing fines whilst away. Autorenewals can be blocked by a hold having been placed on an item, and if this hold was placed after the original patron had left for their holiday but before the autorenewal date then the patron has no option but to start accruing a fine. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 29438] New: Importing a record with an ISBN13 with no ISBN10 counterpart does not save the ISBN
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '23

08 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29438 Bug ID: 29438 Summary: Importing a record with an ISBN13 with no ISBN10 counterpart does not save the ISBN Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When importing a record we call 'NormalizeISBN' This routine returns nothing when an ISBN13 cannot be converted to an ISBN10 - we should have a fallback to return the original value -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 31361] New: Button batch operations disappears when alias is used for itemnumber of biblionumber
by bugzilla-daemon＠bugs.koha-community.org 07 Dec '23

07 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31361 Bug ID: 31361 Summary: Button batch operations disappears when alias is used for itemnumber of biblionumber Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: Windows Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: j.m.koopmans(a)saxion.nl QA Contact: testopia(a)bugs.koha-community.org Created attachment 139128 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=139128&action=e… screenshot report result with batch modification button When running a SQL-report and using an alias for itemnumber or biblionumber in SELECT, the button for 'Batch operations with 20 visible records' disappears. Using an alias for other columns is no problem. Example SQL with button: SELECT items.itemnumber,items.barcode,items.notforloan as Status,biblio.title,items.ccode as Itemtype FROM items LEFT JOIN biblioitems on (items.biblioitemnumber=biblioitems.biblioitemnumber) LEFT JOIN biblio on (biblioitems.biblionumber=biblio.biblionumber) WHERE items.homebranch=<<homebranch|branches>> AND items.itype=<<itype|itemtypes>> AND items.notforloan=<<notforloan>> ORDER BY items.itemnumber asc Changing it to 'SELECT items.itemnumber as Itemnr, etc.' removes the button and the ability for batch processing. The same thing occurs when using an alias for biblionumber in a report. Example SQL with button: SELECT CONCAT ('<a href=\"/cgi-bin/koha/catalogue/detail.pl?biblionumber=',biblio.biblionumber,'\" target=new>',biblio.title,' </a>') as Titel, items.biblionumber,biblio.datecreated as Datum FROM items LEFT JOIN biblioitems on (items.biblioitemnumber=biblioitems.biblioitemnumber) LEFT JOIN biblio on (biblioitems.biblionumber=biblio.biblionumber) where date (datecreated) BETWEEN <<From date|date>> AND <<To date|date>> ORDER BY biblio.datecreated desc Changing 'items.biblionumber to items.biblionumber as Biblionr' removes the button. Also tested it in version 20.11 with the same results. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 29291] New: Self Registration e-mail verification is not stored in notices
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '23

06 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29291 Bug ID: 29291 Summary: Self Registration e-mail verification is not stored in notices 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be great if the self registration e-mail verification was stored in the notifications. Any password that might be in the message could be masked in storage. Or the message itself could be masked. We would at least have a record of the attempt. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 25654] New: Making the Contact Section / Guarantor Section separate from the Contact details of the patron would be less confusing
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '23

06 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25654 Bug ID: 25654 Summary: Making the Contact Section / Guarantor Section separate from the Contact details of the patron would be less confusing Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 105490 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=105490&action=e… differences With the recent change of the Guarantors in Koha, the Contact section of the Patron Detail page (when editing) is confusing. Prior to 19.11, the Contact section was created for the Contact details of the Patron, phone, email, fax. Now in 19.11, the Guarantor (Non-Koha) has been added to the contact section, causing questions if this is the Guarantor's contact information or the primary patron's contact information. It would be nice if there could be a separation of the two areas in the Koha patrons form (memberentry.pl) Attaching an image of the before 19.11 and 19.11 contact section. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30