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

[Bug 19919] New: Writing off a Lost Item Fee marks as "Paid for by patron"
by bugzilla-daemon＠bugs.koha-community.org 26 Dec '24

26 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19919 Bug ID: 19919 Summary: Writing off a Lost Item Fee marks as "Paid for by patron" Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: lisetteslatah(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 70293 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=70293&action=ed… An example A replacement copy was ordered for an item that was "long lost overdue" on a patron's account. The librarian wanted the old copy deleted from the system to keep the record clean. We checked in the item, marked it as lost, and then wrote off the fee associated with the item. Finally we reapplied the fee manually, no longer associated with the item. We noticed that at the point of the write off, the item gets a line that says paid for by (Patron name and barcode) DATE TIME. This also happens if the book is checked in and no longer marked as lost (say it was returned by the borrower so we wrote off the lost item fee.) The borrower has not paid for the book in either situation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 76

[Bug 25963] New: Koha converts ":" to "=" in search terms for Zebra which causes search to fail
by bugzilla-daemon＠bugs.koha-community.org 26 Dec '24

26 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25963 Bug ID: 25963 Summary: Koha converts ":" to "=" in search terms for Zebra which causes search to fail Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au Koha changes : to = because Zebra uses = to separate indexes from search terms, but this is problematic, because it transforms all colons. For instance, "title : subtitle" will become "title = subtitle" and that will cause a Zebra error. Here's the bug removed: buildQuery eb6b10f8 (Chris Nighswonger 2010-02-01 23:18:09 -0500 1768) # $query =~ s/:/=/g; Here's the bug re-introduced. getRecords 08c15831 (Joe Atzberger 2009-07-08 15:27:45 -0500 381) $query_to_use =~ s/\:/\=/g; # change : to = last minute (FIXME) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 7376] Transfer limits should be checked at check-in
by bugzilla-daemon＠bugs.koha-community.org 26 Dec '24

26 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7376 Victor Grousset/tuxayo <victor(a)tuxayo.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #140 from Victor Grousset/tuxayo <victor(a)tuxayo.net> --- There is still Comment 126 about expanding the test plan so no ready for testing yet. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15725] New: Merge permission
by bugzilla-daemon＠bugs.koha-community.org 25 Dec '24

25 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15725 Bug ID: 15725 Summary: Merge permission Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: hbraum(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be nice if Koha had a permission to limit access to the merge records option (Merge selected button) on the addbooks.pl search results page and the virtualshelves/shelves.pl page (lists). This is especially important in a consortial catalog environment where many people have cataloging permissions, but most probably shouldn't have the ability to merge records. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 38784] New: Authority does not update in basic editor when manually linking
by bugzilla-daemon＠bugs.koha-community.org 24 Dec '24

24 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38784 Bug ID: 38784 Summary: Authority does not update in basic editor when manually linking Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: esther.melander(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 175936 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=175936&action=e… bibliographic record to use for testing To replicate: Ensure the authority module is setup and configured. AutoLinkBiblios is set to DO CatalogModuleRelink is set to DO LinkerKeepStale is set to Don't LinkerRelink is set to Do AuthorityMergeLimit is set to 50 AuthorityMergeMode is loose AutoCreateAuthorities is don't generate 1. Have a bibliographic record with an authority for a personal name that includes a date. Have a corresponding authority record that does not include the date in the authority. (examples uploaded). 2. Edit the bibliographic record in the basic editor. 3. Use the tag editor to search for the authority and link it to the authority record. 4. See the authority record number in subfield 9. Also notice the authority record is not updated to remove the date. 5. Save the record. 6. View the bibliographic record in the normal view and see the authority link was not saved. Repeat the above steps, but use the Advanced Editor instead. Notice the authority heading is updated in the editor to match the authority record. Save and see the authority link is correctly saved. I would expect the basic editor to behave the same as the Advanced Editor. Tested this in 24.05, 23.11, and 23.05. Also tested with setting LinkerKeepStale set to DO. With this enabled the link created in the Basic Editor will be retained, but the heading will not be updated. The heading will still be updated in the Advanced Editor. There are likely a few different things happening. The primary thing to note is the difference in behavior between the basic and advanced editors when manually linking. Whether the heading is updated or not may be a matter of preference. Regardless, the link should have been saved in the basic editor. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 38021] New: Circulation Codes Suggestion
by bugzilla-daemon＠bugs.koha-community.org 24 Dec '24

24 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38021 Bug ID: 38021 Summary: Circulation Codes Suggestion Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: tylerkinney50(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I think Koha should add "Circulation Codes", kind of like Follett Destiny has. %C167I for "Reset", etc So for example, to use "reset", when a user scans their library card, and then a couple books, while still highlighting the book barcode field, if Koha detects they enter "%C167I" instead of a valid barcode, it goes back to /cgi-bin/koha/circ/circulation.pl (not circulation-home.pl). This would make "Touchless" checkouts super easy! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 38781] New: Add ability to weight search results based on popularity of biblio / item
by bugzilla-daemon＠bugs.koha-community.org 23 Dec '24

23 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38781 Bug ID: 38781 Summary: Add ability to weight search results based on popularity of biblio / item Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Elastic allows the user to sort results based on popularity, but libraries would like the ability to weight results such that more popular items are pushed higher in the search results when sorting by relevance. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 38749] New: Truncation doesn't work with Zebra phrase searches
by bugzilla-daemon＠bugs.koha-community.org 23 Dec '24

23 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38749 Bug ID: 38749 Summary: Truncation doesn't work with Zebra phrase searches Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org If you do a "Keyword as phrase" search in Koha when using Zebra, a search for 'testa testb*' will turn into this: (rk=(kw,phr: testa and kw,phr,rtrn:testb )) This may or may not make sense when doing a wrdl or word search, but it certainly doesn't make sense when doing a phr phrase search, because it breaks up the terms in the phrase you were searching. That said... Zebra doesn't support * for doing a masked/wildcard search, so it's not clear at a glance how a person could fix this. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 38780] New: Allow configuration of local default choice for framework on record creation and overlay when importing batch
by bugzilla-daemon＠bugs.koha-community.org 23 Dec '24

23 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38780 Bug ID: 38780 Summary: Allow configuration of local default choice for framework on record creation and overlay when importing batch Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When importing a batch of biblio records, the Manage Staged MARC Records page asks the user to specify which framework should be used if a new record is created and which should be used if a record is updated via overlay. "New record framework" is always set to "Default" on page load. "Replacement record framework" is always set to "Keep original framework" on page load. It would be helpful to allow libraries to indicate their local preference for which frameworks to assume in these situations. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 38695] New: CircConfirmItemParts not working correctly
by bugzilla-daemon＠bugs.koha-community.org 23 Dec '24

23 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38695 Bug ID: 38695 Summary: CircConfirmItemParts not working correctly Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1. Turn CircConfirmItemParts to 'require'. 2. Add a items.material note to an item 3. Checkout the item to a patron. Notice the "Note about the accompanying materials:" message. 4. The item is checked out with needing confirmation, as if CircConfirmItemParts was set to 'Don't require' -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2