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

[Bug 25364] New: Add "Other" to the gender options in a patron record
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '23

10 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25364 Bug ID: 25364 Summary: Add "Other" to the gender options in a patron record 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: david.roberts(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Almost all new installs require us (PTFS Europe) to modify the wording on the Gender options in a patron record in order to meet the requirements of users. I propose that changing the three options ("Female", "Male" and "None specified") to ("Female", "Male", "Other" and "None specified / Prefer not to say") would help avoid these problems. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36

[Bug 24425] New: Remove utf8 as an export option
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '23

10 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24425 Bug ID: 24425 Summary: Remove utf8 as an export option 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: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl it's a character encoding, not a file type. Doesn't really makes sense. Option exists for both bibliographic records and authority records. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 25579] New: Holds Tracker Page
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '23

10 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25579 Bug ID: 25579 Summary: Holds Tracker Page 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 Similar to delivery systems for pizza companies, it would be great to have a holds tracker that refreshes each minute, checking holds and displaying a live queue, and optionally automatically printing a pull slip so staff can just grab slips and grab the item to check in and trigger. This would also be a great mechanism for cancelled holds as well. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 25676] New: Staff client catalog search shows incorrect item status under location
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '23

10 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25676 Bug ID: 25676 Summary: Staff client catalog search shows incorrect item status under location Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: joe(a)flo.org QA Contact: testopia(a)bugs.koha-community.org Created attachment 105553 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=105553&action=e… Incorrect search result example If you have an item that has a Lost status of "Lost" it will appear as "long overdue" in staff client search results. See attached screenshots for an example. This should display the current Lost status instead. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 25657] New: Import Patron fails without userid - not stated as required field in notes
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '23

10 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25657 Bug ID: 25657 Summary: Import Patron fails without userid - not stated as required field in notes Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: eb(a)efdss.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Somewhere in a recent upgrade, the userid became a required field for importing patrons. If it is not present Koha will attempt to use the userid from the person logged in for all userids. This causes the import to fail as they're 'duplicate'. This is an easy fix - update the notes to state the userid is a required field. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 25788] New: Club holds should have an optional expiration date
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '23

10 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25788 Bug ID: 25788 Summary: Club holds should have an optional expiration date Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: george(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com There is no way to set an expiration date for club holds. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 25784] New: Flag to make individual items non-holdable
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '23

10 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25784 Bug ID: 25784 Summary: Flag to make individual items non-holdable Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: fiona.borthwick(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Items can be made non-holdable by item type - can set the 'holds policy' in the 'Default hold policy by item type' area. This works fine if we have a set of items that should be non-holdable. The NOT_LOAN authorised value can also play a role in identifying items that can be placed on hold. e.g. -1 = Ordered (holdable), 1 = Not for loan (non-holdable) Problems arise however if only individual items should be non-holdable or if there are specific collections (identified by ccode) that should be non-holdable BUT these items can go out on loan. We have a customer who have a set of items that belong in a specific collection (ccode). These are a mixutre of item types (e.g. Book, Audio Book etc) that link to different circ rules. All these items can go out on loan. In this case we cannot really advise allocating a new item type as loan periods differ by current item types. We could of course then duplicate the item type - e.g. have BK (Book) and BK-NH (Book Non-holdable) but this adds unnecessary complexity and would have implications on the circulation rules! It is not really an option to add a NOT_LOAN status to these records as this would mean that staff would have to override a checkout transaction each time and there would be problems at the self issue machines. The status would also not look correct. It would be really good if we could add some flag into the item record or find some other method to mark items as non-holdable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 25736] New: ClaimsReturnedWarningThreshold should be disabled by being unset
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '23

10 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25736 Bug ID: 25736 Summary: ClaimsReturnedWarningThreshold should be disabled by being unset 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Tangential to bug 25733 If ClaimsReturnedWarningThreshold is empty, it should be ignored and no message should be shown in patron account. Imagine: - a library decides to use Claims Returned, sets it up, uses it for a while - the library decides not to use it anymore and removes the values from ClaimReturnedLostValue and ClaimReturnedWarningThreshold - Koha treats the blank in ClaimReturnedWarningThreshold as a zero, shows the warning for anyone who still has 1 or more claims in the database - With ClaimReturnedLostValue unset, there is no longer a way to see or address those claims -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 25719] New: Add system preference for logged in patrons to display only the patron's first name
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '23

10 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25719 Bug ID: 25719 Summary: Add system preference for logged in patrons to display only the patron's first name Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org We'd like to see a system preference created that would allow libraries to select whether they would like to display the full patron name or only the first name for patrons who are logged into the OPAC. This would provide a cleaner display since some patron names can be rather long. In addition, most commercial websites will only display a first name for logged in users. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 25737] New: Allow for Claims Returned status in Lost Authorized Value to be branch specific
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '23

10 Dec '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25737 Bug ID: 25737 Summary: Allow for Claims Returned status in Lost Authorized Value to be branch specific Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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 Currently, in the Lost Authorized value set up - a lost status can be specific to a branch. So only that branch/es can use that specific lost status. This is super helpful in consortiums. With this new Claims Returned feature, you assign a lost value for your Claims returned, and in the set-up (Authorized Value) it does show that it can be branch-specific, however, this is currently not working as expected. This could be due to this bug https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24279 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2