September 2017 - Koha-bugs - lists.koha-community.org

[Bug 16787] New: 'Too many holds' message appears inappropriately and is missing data
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '21

29 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16787 Bug ID: 16787 Summary: 'Too many holds' message appears inappropriately and is missing data 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com bug 11250 changed the holds message to be and if,elsif loop, falling through to catch the first appropriate message bug 13116 changed the reporting from CanItemBeReserved causing tooManyHolds to trigger when no holds are allowed A side effect is that 'maxreserves' is only passed to the template when there are too many reserves, but the too many reserves message is called when no holds are available To recreate: Set maxreserves to 50 Set some item type to allow 0 holds Attempt to place a hold on a record with that itemtype Message will be "Too many holds: [Firstname Surname] can only place a maximum of total holds." Message should be "[Firstname Surname] cannot place any holds on these items." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 100

[Bug 17717] New: Can't locate Authen/CAS/Client/Response/Failure.pm
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '21

28 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17717 Bug ID: 17717 Summary: Can't locate Authen/CAS/Client/Response/Failure.pm Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: Linux Status: NEW Severity: minor Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: mjnkml(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz On Ubuntu, output of /usr/share/koha/bin/cronjobs/process_message_queue.pl in an email from cron: ourlib: Can't locate Authen/CAS/Client/Response/Failure.pm: ./Authen/CAS/Client/Response/Failure.pm: Permission denied at /usr/share/perl/5.22/base.pm line 97. ourlib: ...propagated at /usr/share/perl/5.22/base.pm line 106. ourlib: BEGIN failed--compilation aborted at /usr/share/perl5/Authen/CAS/Client/Response.pm line 68. ourlib: Compilation failed in require at /usr/share/perl5/Authen/CAS/Client.pm line 8. . . . process_message_queue.pl is currently invoked from /etc/cron.d/koha-common I don't find any Failure.pm on the system. This only started happening after a recent update which resulted in Bug 17234. Not sure if issues with that may have also affected this. Have done a full reinstall (without Purge) of the packages. -- You are receiving this mail because: You are watching all bug changes.

1 91

[Bug 18731] New: Orders table slow to load for vendors with many orders
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '21

28 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18731 Bug ID: 18731 Summary: Orders table slow to load for vendors with many orders Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some libraries may have hundreds of open orders for a vendor, depending on acqisitions workflow. At that number of open orders, the tables on parcel.pl take 10 to 20 seconds to load. To speed up the loading of this page and the data, we should convert the order tables from pre-loading all order data to ajax tables that load order data on an as needed basis. That way we are only pulling the data for the orders that are currently visible. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 111

[Bug 18755] New: Allow empty password fields in Patron Info requests
by bugzilla-daemon＠bugs.koha-community.org 28 Apr '21

28 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18755 Bug ID: 18755 Summary: Allow empty password fields in Patron Info requests Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Bug 16610 changed the behaviour of patron info requests and responses - previously if the password field was empty in the request, we returned password ok. Many sip clients assume that passing an empty pwd field means "I'm not validating a password - I just want to know patron is valid" and are failing because of the change in behaviour. As both scenarios are valid I suggest adding a parameter to the sip config to allow empty password fields to be treated as previously. To my knowledge this is only an issue in the patron info response. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 16335] New: Refactor OpacHiddenItems
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '21

23 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16335 Bug ID: 16335 Summary: Refactor OpacHiddenItems 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: mtompset(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org See 14385 and 10589 as well. The problem is this functionality would be better written using the newer Koha::RecordProcessor filtering functionality. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 17809] New: ER country in fr-FR database files
by bugzilla-daemon＠bugs.koha-community.org 21 Apr '21

21 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17809 Bug ID: 17809 Summary: ER country in fr-FR database files Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org In installer/data/mysql/fr-FR/1-Obligatoire/authorised_values.sql, ER is defined twice, for "Érythrée" (correct one) and "Allemagne". -- You are receiving this mail because: You are watching all bug changes.

1 86

[Bug 18433] New: Allow to select results to export in item search
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '21

20 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18433 Bug ID: 18433 Summary: Allow to select results to export in item search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Searching Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 18394 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18394 [Bug 18394] Add an option to item search to export a barcodes file -- You are receiving this mail because: You are watching all bug changes.

1 62

[Bug 18170] New: Show damaged status on check-in
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '21

17 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18170 Bug ID: 18170 Summary: Show damaged status on check-in Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 It would be nice if when checking in an item we could see if it has a damaged status without opening a new tab to see. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 31

[Bug 18195] New: Charge for expired holds per patron category
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '21

15 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18195 Bug ID: 18195 Summary: Charge for expired holds per patron category Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: sally.healey(a)cheshiresharedservices.gov.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com ExpireReservesMaxPickUpDelayCharge allows one charge to be applied to all holds that expire. However, each patron category can have a unique hold fee. It would be preferable if each patron category could also have a unique 'hold expired' fee, so different patron categories could be charged different amounts (or not at all) for expired holds. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 17388] New: Suggestion detail page marks suggestion as rejected and accepted
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '21

06 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17388 Bug ID: 17388 Summary: Suggestion detail page marks suggestion as rejected and accepted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org To reproduce: - Create a suggestion - In suggestions management, mark it ("accidentally") as accepted. - Then change status, e.g. to rejected - Display the suggestion's detail page Result: Weird information on detail page, suggestion appears as rejected and as accepted. See screeshot. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3