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

[Bug 25812] New: Display overdue fines for the document on SIP checkin
by bugzilla-daemon＠bugs.koha-community.org 03 Oct '24

03 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25812 Bug ID: 25812 Summary: Display overdue fines for the document on SIP checkin 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: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Display overdue fines for the document on SIP checkin Test plan: - Using SIP, checkin an item that has one or several overdue fines. - Check that the following message is displayed (AF field): "You owe {correctly formatted price} for this document." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 16881] New: Apply KohaTable and ColVis plugin on MARCdetail' s items table
by bugzilla-daemon＠bugs.koha-community.org 02 Oct '24

02 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16881 Bug ID: 16881 Summary: Apply KohaTable and ColVis plugin on MARCdetail's items table Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Allows to choose columns to display on items table in the MARCdetail page (cgi-bin/koha/catalogue/MARCdetail.pl). Also, the columns displayed are saved for each users in database. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 30

[Bug 27652] New: Offer selections for preferences which ask for patron categories
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27652 Bug ID: 27652 Summary: Offer selections for preferences which ask for patron categories Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration 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 We have several system preferences where the user is supposed to enter a patron category, but it's a text input. These should offer selections of existing patron categories to prevent data errors. Ideally we'd have two ways to configure the preferences: As a single <select> ("choices" in the pref file) or multiple select ("multiple" in the pref file). PatronSelfRegistrationDefaultCategory - single GoogleOpenIDConnectDefaultCategory - single OPACHoldsIfAvailableAtPickup - multiple BatchCheckouts - multiple -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 19590] New: doc of Clean Patron Records tool wrong about deletion scope + anonymization syspref
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19590 Bug ID: 19590 Summary: doc of Clean Patron Records tool wrong about deletion scope + anonymization syspref Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Hi, I think I've found a documentation issue in the "Clean Patron Records" tool. Both the in-app + online doc [1] mention that: «patrons with outstanding fines or items checked out not saved» (the rest of the doc confirms that we are talking about removal) → wrong, see [2][3] «The anonymization will fail quietly if AnonymousPatron preference does not contain a valid value.» → wrong, according to the UI itself «The AnonymousPatron system preference is not defined. You can use this feature anyway but NULL will be used to update the checkout history.» Are these two findings correct? [1] https://koha-community.org/manual/17.05/html/03_tools.html#patrons-anonymiz… [2] excludes patrons with checked out item https://github.com/Koha-Community/Koha/blob/master/C4/Members.pm#L1040 [3] excludes patrons with unpaid fines https://github.com/Koha-Community/Koha/blob/master/tools/cleanborrowers.pl#… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 17330] New: Initiate batch item edit of items from cart (new feature? )
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17330 Bug ID: 17330 Summary: Initiate batch item edit of items from cart (new feature?) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: viktor.sarge(a)regionhalland.se QA Contact: testopia(a)bugs.koha-community.org On 16.05.03 I can initiate batch record edit from the cart, but not items edit. I realize that it's the records that are saved and not items, but /cgi-bin/koha/tools/batchMod.pl already have a checkbox for choosing which items to modify. How about showing all items for all the records chosen and you could just chose which ones to work with? I do feel that there is a possibility of people messing things up from not thinking about the difference between the saved records and the items for that record that might live in different locations. But when someone puked on a whole shelf it's a quick way to search all records on a particular shelf and marking the items as damaged. What say ye? (To be really helpful it would be good if you could check/uncheck all items based on for example location etc. of course) -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 16898] New: Show patron restriction details on OPAC user page
by bugzilla-daemon＠bugs.koha-community.org 01 Oct '24

01 Oct '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16898 Bug ID: 16898 Summary: Show patron restriction details on OPAC user page 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: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Right now if you have multiple restrictions on your account, the details of those restrictions are all string together in the message which displays in the OPAC. We should display details for each separate restriction. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 29554] New: No itemtype for neworderempty.pl
by bugzilla-daemon＠bugs.koha-community.org 30 Sep '24

30 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29554 Bug ID: 29554 Summary: No itemtype for neworderempty.pl 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org neworderempty contains: # Get the item types list, but only if item_level_itype is YES. Otherwise, it will be in the item, no need to display it in the biblio my @itemtypes; @itemtypes = Koha::ItemTypes->search unless C4::Context->preference('item-level_itypes'); I would argue that we should always fetch the itemtypes here. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 32

[Bug 30581] New: Items should show on the Holds Queue and Holds to Pull even if they have requested transfers
by bugzilla-daemon＠bugs.koha-community.org 29 Sep '24

29 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30581 Bug ID: 30581 Summary: Items should show on the Holds Queue and Holds to Pull even if they have requested transfers 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 In bug 23092 Koha added the idea of a transfer that has been requested but not yet sent. The Holds Queue and and Holds to Pull will not show titles/items that have transfers that are not either complete or cancelled, so staff are not alerted to holds on Available items if those items have requested transfers on them. But if the item is checked in, it will trigger the hold. We should show items in the Holds Queue and Holds to Pull if they have transfers that are requested but not sent. 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 19

[Bug 31109] New: Add ability to lock bibliographic record or alert staff when another user is in the same bibliographic record
by bugzilla-daemon＠bugs.koha-community.org 27 Sep '24

27 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31109 Bug ID: 31109 Summary: Add ability to lock bibliographic record or alert staff when another user is in the same bibliographic record Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When a cataloger is in bibliographic record-making changes, it would be nice to alert other staff (if they happen to be in the same bibliographic record) with a message box to indicate another staff member is also making changes. Additionally, allow staff to view the bibliographic record but not make changes if another staff member is also in the bibliographic record. This is a concern for larger consortiums that share records to have some sort of fail-safe method of making sure edits by any staff are saved. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 58

[Bug 26716] New: Allow specifying where to insert new fields in MARC Modification Templates
by bugzilla-daemon＠bugs.koha-community.org 27 Sep '24

27 Sep '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26716 Bug ID: 26716 Summary: Allow specifying where to insert new fields in MARC Modification Templates Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: phil(a)chetcolibrary.org QA Contact: testopia(a)bugs.koha-community.org Currently newly-added fields are stuffed at the end of the record, after 999. Bug 24480 is changing that to insert them in numerical order. However, as the methods on MARC::Record illustrate, there are two other ways that people want to insert fields: grouped by hundreds, so that instead of adding a new 502 after any existing 502s you add it after every existing 5xx field, or, before or after a specific other field. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3