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

[Bug 7385] Enrich OPAC with wikipedia content
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '19

10 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7385 David Nind <david(a)davidnind.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=24206 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9156] itemcallnumber not pulling more than 2 subfields
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '19

10 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9156 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Failed QA |Needs Signoff --- Comment #7 from Owen Leonard <oleonard(a)myacpl.org> --- Séverine I wasn't able to reproduce either of these problems. Could you test again and see if luck shines on me? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12446] Enable an adult to have a guarantor
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '19

10 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12446 Maxime Dufresne <maxime.dufresne(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maxime.dufresne(a)inlibro.com Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12430] Using QueryAutoTruncate breaks relevance ranking
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '19

10 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12430 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com Status|In Discussion |Needs Signoff --- Comment #16 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- I've attempted a rebase of the patch.. it's not an area I'm all that familiar with so testing is required. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12430] Using QueryAutoTruncate breaks relevance ranking
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '19

10 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12430 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #28880|0 |1 is obsolete| | --- Comment #15 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- Created attachment 96167 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=96167&action=ed… Bug 12430 - Truncation disables relevance ranking when not using QueryParser The system preference "QueryWeightFields" is mutually exclusive with the system preference "QueryAutoTruncate" and the * truncation modifier, when not using QueryParser. If you use truncation, relevance won't work anymore. (N.B. Relevance doesn't work probably when using QueryParser, but for a very different reason beyond the current scope of this bug.) This patch adds relevance ranking when using truncation (or basically when QueryWeightFields is disabled). _TEST PLAN_ 1) Turn on "QueryWeightFields" and "QueryAutoTruncate" 2) Turn off "TryQueryParser" 3) Do a keyword search in the OPAC 4) Note that the results are ordered by biblionumber ascending 5) Apply patch 6) Do the same keyword search in the OPAC 7) Note that the results are never ordered differently (presumably in relevance order :P) If you're a stickler, throw in some warns so that you can see what CCL query is being sent to Zebra. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8132] Batch delete tool deletes items with holds on them
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '19

10 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8132 --- Comment #40 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- (In reply to Kelly McElligott from comment #39) > Jonathan, > Two issues that I have with this: > > In this step: > > 2/ Select them and confirm the deletion > => Nothing happened and you get a message saying that one of the 2 items > from B2 is blocking the whole deletion process > > This does block the whole process! So all the item that could be deleted - > don't get deleted, the button to return to Batch Item Deletion, results in > having to re-enter all the items that could have been deleted but weren't > because of 1 item. Could the return to deletion button bring back the > screen prior to this. This is just a lot of extra work. I will see what I can do. But yes, I do expect the whole process to be blocked. If something is wrong, the whole transaction is rolled back. > In this step: > 3/ Remove the biblio-level hold > 4/ Repeat 1 > => The deletion has been effective! > > Koha is deleting both items on Bib4 - one of which had an item level hold > (not triggered). The hold does not get orphaned, because it too is deleted. > Is this what you would like to see happen, a library can delete an item with > an item level hold if it isn't triggered? It is how it works so far. That's why I added a note in the commit message about this behavior. The hold has to be found (waiting or in transfer) to see the deletion blocked. I guess it's how it works as well in the cataloguing module. It's not a behavior's change I want to introduce with this patchset, if we decide to modify it we should do it on its own bug report. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 8132] Batch delete tool deletes items with holds on them
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '19

10 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8132 --- Comment #39 from Kelly McElligott <kelly(a)bywatersolutions.com> --- Jonathan, Two issues that I have with this: In this step: 2/ Select them and confirm the deletion => Nothing happened and you get a message saying that one of the 2 items from B2 is blocking the whole deletion process This does block the whole process! So all the item that could be deleted - don't get deleted, the button to return to Batch Item Deletion, results in having to re-enter all the items that could have been deleted but weren't because of 1 item. Could the return to deletion button bring back the screen prior to this. This is just a lot of extra work. In this step: 3/ Remove the biblio-level hold 4/ Repeat 1 => The deletion has been effective! Koha is deleting both items on Bib4 - one of which had an item level hold (not triggered). The hold does not get orphaned, because it too is deleted. Is this what you would like to see happen, a library can delete an item with an item level hold if it isn't triggered? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15483] in a weekly serial subscription, the second planned issue corresponds to third publisheddate
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '19

10 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15483 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|NEW |RESOLVED CC| |nick(a)bywatersolutions.com --- Comment #1 from Nick Clemens <nick(a)bywatersolutions.com> --- Cannot recreate, please add details of numbering pattern used if this issue recurs -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 10450] Editing serials predicts wrong
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '19

10 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10450 Nick Clemens <nick(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |WORKSFORME Status|NEW |RESOLVED CC| |nick(a)bywatersolutions.com --- Comment #3 from Nick Clemens <nick(a)bywatersolutions.com> --- Cannot recreate, internal ticket was marked resolved and problem not replicable -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 22923] New: Items search does not take care of independent branches
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '19

10 Dec '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22923 Bug ID: 22923 Summary: Items search does not take care of independent branches Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Items search /cgi-bin/koha/catalogue/itemsearch.pl should be impacted by preference IndependentBranches. Maybe it should automatically limit to current branch. Main problem is that actually its a way to edit items of other branches. Maybe there should also be a check in cataloguing/additem.pl itself. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 11