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

[Bug 7611] Show the NOT_LOAN authorised values for item status in XSLT OPAC search results
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '20

05 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7611 --- Comment #44 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- Nick, could you confirm it will not break the display for UNIMARC and NORMARC? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 24587] New: reserve/placerequest.pl is not used anymore and should be removed
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '20

05 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24587 Bug ID: 24587 Summary: reserve/placerequest.pl is not used anymore and should be removed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 19618 Bug 19618 removed the last place where reserve/placerequest.pl was used and forgot to remove it. It should be removed. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19618 [Bug 19618] Add 'Club Holds' feature -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 12430] Using QueryAutoTruncate breaks relevance ranking
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '20

05 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12430 --- Comment #25 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- (In reply to David Cook from comment #24) > (In reply to Katrin Fischer from comment #23) > > I'd argue it's still a very bad bug and Elastic not ready yet for wide use > > yet (thinking of libraries without IT experts and support especially). As it > > breaks things when NOT using QueryParser, there is no link to that. It hurts > > a lot of our libraries and is very hard to figure out - I think we shoudl > > really fix it. The sole reason it was not fixed yet is probably people are > > scared of Search.pm. > > I'm not scared but there's no time/money for me to work on fixing it :/. > > In my opinion, Search.pm is really really bad, and fixing it would be a very > time-consuming exercise. (I suppose part of the time-consuming part would be > finding a lack of people wiling to test/QA because of fear of Search.pm > though that's true...) What about the patch? Was not it suppose to fix the issue? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15261] Verify if checkouts or reserves requests periods overlap with existing reserves
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '20

05 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15261 Julian Maurice <julian.maurice(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Patch doesn't apply |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15261] Verify if checkouts or reserves requests periods overlap with existing reserves
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '20

05 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15261 Julian Maurice <julian.maurice(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #98383|0 |1 is obsolete| | --- Comment #81 from Julian Maurice <julian.maurice(a)biblibre.com> --- Created attachment 98424 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=98424&action=ed… Bug 15261: Check if checkout/reserve request overlaps existing reserves When checking out or placing hold, we should check if an existing reserve whose period overlap exists. - A user places a hold from opac whose requested period overlaps with an existing reserve period => prevent reserve - A librarian places a hold from staff whose requested period overlaps with an existing reserve period => Warn librarian (Ask for confirmation) - A librarian makes a checkout from staff whose requested period overlaps with an existing reserve period => Warn librarian (Ask for confirmation) Test plan: Enable syspref: AllowHoldDateInFuture OPACAllowHoldDateInFuture PreventChechoutOnSameReservePeriod and PreventReservesOnSamePeriod 1 (staff side): - Place a hold on title (which has only one items) level with start date and expiration date. - Place another hold (also title level) with period overlaping this reserve. - Check you are warned about an existing reserve 2 (staff side): - Place a hold on title (which has more than one items) level with start date and expiration date. - Place another hold (also title level) with period overlaping this reserve. - Check you are NOT warned about an existing reserve. Because it remains at least one item not reserved. 3 (staff side): - Place a hold on item level with start date and expiration date. - Place another hold on item level with period overlaping this reserve. - Check you are warned about an existing reserve. 4 (opac side): - Do the same than for staff side. Instead of a warn, reserve is prevented. 5: - Place a hold on title (which has only one items) level with start date and expiration date. - Try to checkout the unique item from this title with period overlaping the reserve period. - Check you are warned about an existing reserve 6: - Place a hold on title (which has more than one items) level with start date and expiration date. - Checkout an item from this title with period overlaping the reserve period. - Check you are NOT warned about an existing reserve. 7: - Place a hold on item level with start date and expiration date. - Checkout this item period overlaping the reserve period. - Check you are warned about an existing reserve 8: - Create a checkout (i.e from ${TODAY} to ${TODAY + 10 days}), - Place a hold on the same item from ${TODAY + 11 days} to ${TODAY + 30 days}), - Check that you cannot renew the checkout. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12742] Omnibus: QueryParser
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '20

05 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12742 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |24586 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24586 [Bug 24586] Double quote escape doesn't work properly in C4::AuthoritiesMarc::SearchAuthorities with QueryParser enabled -- 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 05 Feb '20

05 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12430 --- Comment #24 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #23) > I'd argue it's still a very bad bug and Elastic not ready yet for wide use > yet (thinking of libraries without IT experts and support especially). As it > breaks things when NOT using QueryParser, there is no link to that. It hurts > a lot of our libraries and is very hard to figure out - I think we shoudl > really fix it. The sole reason it was not fixed yet is probably people are > scared of Search.pm. I'm not scared but there's no time/money for me to work on fixing it :/. In my opinion, Search.pm is really really bad, and fixing it would be a very time-consuming exercise. (I suppose part of the time-consuming part would be finding a lack of people wiling to test/QA because of fear of Search.pm though that's true...) -- 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 04 Feb '20

04 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12430 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|normal |major -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10532] koha-run-backups option --output doesn't work
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '20

04 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10532 --- Comment #7 from Magnus Enger <magnus(a)libriotech.no> --- What it is the right approach here? 1. Create the directory indicated by --output if it does not exist 2. Check if the directory indicated by --output exists, and exit if it does not -- 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 04 Feb '20

04 Feb '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12430 --- Comment #23 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Martin Renvoize from comment #22) > De-escalating this one.. it's been around for 6 years and hasn't really > recieved the attention a critical should.. I personally feel at the time it > was critical and it's still a nice to fix.. but as we're moving toward > elastic search and possible deprecating QueryParser entirely I'm not sure > how to progress this bug. I'd argue it's still a very bad bug and Elastic not ready yet for wide use yet (thinking of libraries without IT experts and support especially). As it breaks things when NOT using QueryParser, there is no link to that. It hurts a lot of our libraries and is very hard to figure out - I think we shoudl really fix it. The sole reason it was not fixed yet is probably people are scared of Search.pm. -- You are receiving this mail because: You are watching all bug changes.

1 0