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

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '21

26 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Failed QA --- Comment #361 from David Cook <dcook(a)prosentient.com.au> --- My latest comment shows a very very bad regression which needs to be fixed. It's a simple fix but nasty problem. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15516] Allow to place a hold on first available item from a group of titles
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '21

26 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15516 --- Comment #360 from David Cook <dcook(a)prosentient.com.au> --- Comment on attachment 120644 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=120644 Bug 15516: Relevant controller changes and tests Review of attachment 120644: --> (https://bugs.koha-community.org/bugzilla3/page.cgi?id=splinter.html&bug=155…) ----------------------------------------------------------------- ::: C4/Reserves.pm @@ +1113,4 @@ > logaction( 'HOLDS', 'MODIFY', $hold->reserve_id, Dumper($hold->unblessed) ) > if C4::Context->preference('HoldsLog'); > > + # if this hold was part of a group, cancel other holds in the group This causes every hold with a null hold_group_id to be cancelled. This needs to be wrapped in a check for $hold_group_id first! @@ +1222,5 @@ > # Complete transfer if one exists > my $transfer = $hold->item->get_transfer; > $transfer->receive if $transfer; > + > + # if this hold was part of a group, cancel other holds in the group This causes every hold with a null hold_group_id to be cancelled. This needs to be wrapped in a check for $hold_group_id first! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28510] New: Skip processing holds queue items from closed libraries when HoldsQueueSkipClosed is enabled
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '21

25 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28510 Bug ID: 28510 Summary: Skip processing holds queue items from closed libraries when HoldsQueueSkipClosed is enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Right now we skip closed branch's items as we iterate over all items looking for ones to fill a hold. If HoldsQueueSkipClosed is enabled, no items held be a closed library can be targeted, so it would be more efficient if we never selected the items from those branches to begin with. This is how the holds queue works if we are not using the transport cost matrix, so we should make it work the same way if we *are* using the matrix. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 11175] Show the parent record's component parts in the detailed views
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '21

25 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11175 --- Comment #478 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Marcel de Rooy from comment #473) > I wrote two follow-ups now. WIll attach them tomorrow. > > But did look a bit closer to analytical records in Koha and they are quite > different from what is done here. They use 773 but thats about it. So there > seems to be no reason to braid(?) them together here. Making the analytics > disappear when there are components. > > Note: the components here work with 773 and record control numbers looked up > in biblio records. Analytics works different, storing item numbers(!) in > 773$9. This seems to be something that we add on top of MARC21, if I > understand correctly (so no default MARC21). > > Conclusion: We should keep them really separate from each other. Will have > to add that to my follow-up still. Which should be very trivial. > > Katrin: Could you confirm? I believe there are some major differences between the features - so fully agree. What we are looking for here is linking between bibliographic records. We link a record to another record, using either $w or a combination of title and author from 773 for search. So this is about hierarchies on the bibliographic record level. EasyAnalytics as I understand it, is linking an item to multiple records using non-standard MARC subfields of 773. It's a useful feature, but a different use case. For example it could probably be used very well for "bound-togethers", where different works where combined into one bound unit (often found in historical holdings). We could probably make both work together by checking for the prefs and maybe existence of certain subfields in 773, but as UseControlnumber and Easyanalytics are already mutually exclusive right now, I think it's outside of scope here. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9596] Allow longoverdue.pl to be configured by library
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '21

25 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9596 mdanko(a)burlingtonvt.gov changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |mdanko(a)burlingtonvt.gov --- Comment #2 from mdanko(a)burlingtonvt.gov --- I would love to have the longoverdue script be granular to the issuing branch. It makes sense to me if a patron borrows materials from our branch, they need to follow our loan rules...including if an item is longoverdue and will get billed. This would be a great place to start I think. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 29316] New: advanced search fails when top field is left blank
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '21

25 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29316 Bug ID: 29316 Summary: advanced search fails when top field is left blank Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: bdaeuber(a)cityoffargo.com QA Contact: testopia(a)bugs.koha-community.org When using the advanced search in the OPAC, it will fail when the top field is left blank (or ignore subsequent fields if there is a blank field above them). It does appear to work in the intranet, however. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 29118] New: Basic editor for new entry or editing records drops fields that contains any UTF-8 character
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '21

25 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29118 Bug ID: 29118 Summary: Basic editor for new entry or editing records drops fields that contains any UTF-8 character Change sponsored?: --- Product: Koha Version: 20.05 Hardware: PC OS: Linux Status: NEW Severity: major Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: courtenay.johnson(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When using the basic editor for cataloging, entry of new records, fields that contain UTF-8 are silent ignored when saved. When that record is reviewed the field that had contained one of more UTF-8 character is now blank. When an item for that record is entered, fields that contain UTF-8 work fine. A clue may be that when a new record is created, or changed with some UTF-8 in the title field 245a, the field appears to be blank, and if the save button is hit again without making any changes, there is a complaint “Can’t save this record because the following field aren’t filled, tag 245 subfield a Title in tab 0” that you can’t save with a blank title field. However the display of the record that shows the tile and the record number shows the title correctly including the UTF-8 characters exactly as typed in the title. This problem occurs in Koha 18.11 and 21.05. Both are running on Ubuntu 18.11 and now on 20.04.3 LTS. I have tested that mysql tables will accept input from a mysql prompt in UTF-8, and displays it correctly in a query. Have tested that a short HTML file can be read by Apach2 and displays correctly. I have tested that Ubuntu’s locale is set to support UTF-8, by running the locale command. I am using Koha in Canada, using English. I tried the advanced editor option. There was no change when I edited the same record. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 11175] Show the parent record's component parts in the detailed views
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '21

25 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11175 Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |29314 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29314 [Bug 29314] Move some OpenURL code to Koha::Biblio -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9565] Deleting a biblio should alert/fail if there are existent subscriptions
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '21

25 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9565 marion.durand(a)biblibre.com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marion.durand(a)biblibre.com Status|Failed QA |Needs Signoff -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 9565] Deleting a biblio should alert/fail if there are existent subscriptions
by bugzilla-daemon＠bugs.koha-community.org 25 Oct '21

25 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9565 --- Comment #5 from marion.durand(a)biblibre.com --- Created attachment 126821 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=126821&action=e… Bug 9565: (follow-up) Deleting a biblio should alert/fail if there are existent subscriptions Currently Koha will delete a biblio record if there are existent serial subscriptions. This patch will prevent deleting the biblio until attached subscriptions are removed. To test: 1) Add a subscription to a biblio, or check a biblio which has one attached already. 2) Remove all items if there are any. 3) Apply patch. 4) Confirm that the 'Delete record' item is disabled in the list. 5) Attempt to 'Delete record', you should recieve an error message stating to delete all subscriptions before deleting record. 6) Sign off. Sponsored by: Lunds Universitetsbibliotek -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0