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

[Bug 28292] New: Searching with colon ":" in the end of query gives internal server error
by bugzilla-daemon＠bugs.koha-community.org 11 Jun '21

11 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28292 Bug ID: 28292 Summary: Searching with colon ":" in the end of query gives internal server error Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi CC: nugged(a)gmail.com, stalkernoid(a)gmail.com Searching (SearchEngine=elasticsearch) the catalogue with anything that ends with just a colon ":" gives internal server error. E.g. searching "hello:" gives this error. The code that was modified in bug 24567 would need to be adapted so that it would strip also the colon when it ends the query and not just when there is whitespace around it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 28552] New: Internal server error when patron's birthday doesn't include required number of characters
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '21

10 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28552 Bug ID: 28552 Summary: Internal server error when patron's birthday doesn't include required number of characters Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: madamyk(a)ckls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When adding or editing a patron record, if the birth date is manually typed in and doesn't include the proper number and type of characters (MM/DD/YYYY), attempting to save the patron record will result in an internal server error. For example, 07/09/1999 will work, but 7/9/1999 will return the error. It would be very helpful if Koha would kick us back to the patron creation screen, preferably with an error or explanation message, rather than returning an internal server error. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 28547] New: With anonymous transactions now available, the Koha::Account class is misnamed
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '21

10 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28547 Bug ID: 28547 Summary: With anonymous transactions now available, the Koha::Account class is misnamed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org We should move Koha::Account to Koha::Patron::Account to better reflect how it is tied to the patron. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 14825] Accounts Rewrite Omnibus
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '21

10 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14825 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |28547 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28547 [Bug 28547] With anonymous transactions now available, the Koha::Account class is misnamed -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 5229] OPACItemsResultsDisplay preference does not work with XSLT results
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '21

10 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5229 Lucas Gass <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lucas(a)bywatersolutions.com --- Comment #2 from Lucas Gass <lucas(a)bywatersolutions.com> --- This appears to still be valid. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 27071] New: Hold pickup library match not enforced correctly on intranet when using hold groups
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '21

10 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27071 Bug ID: 27071 Summary: Hold pickup library match not enforced correctly on intranet when using hold groups Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical 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: 22284 To recreate: - Create two local hold groups containing distinct lists of libraries. - In default rules for all libraries, set Hold Policy = "From local hold group" and Hold pickup library match to "Patron's hold group" - Make sure AllowHoldPolicyOverride is set to Don't Allow - Make sure you're logged in at a library in Group 1 - Find a bib with only 1 item from Group 1. Confirm you can place a hold on this title for a patron in Group 1 (correct), but not for a patron in Group 2 (correct). - Find a bib with only 1 item from Group 2. Confirm you cannot place a hold for a patron from Group 1 (correct), BUT you also cannot place a hold for a patron from Group 2 (incorrect) -- Koha gives the erroneous message "pickupNotInHoldGroup" - Change your library to a something in Group 2 - Find a bib with only 1 item from Group 1. Confirm you cannot place a hold on this title for a patron in Group 1 (incorrect), and not for a patron in Group 2 (correct). - Find a bib with only 1 item from Group 2. Confirm you cannot place a hold for a patron from Group 1 (correct), but you can place a hold for a patron from Group 2 (correct) Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22284 [Bug 22284] Add ability to define groups of locations for hold pickup -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 61

[Bug 26787] New: getletter does not fallback to default language - transaction receipts can be blank
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '21

10 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26787 Bug ID: 26787 Summary: getletter does not fallback to default language - transaction receipts can be blank Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org getletter does not fallback to default language, it searches for a language if passed then gives up To recreate 1 - Enable 'TranslateNotices' syspref 2 - Define ACCOUNT_CREDIT notice for print transport in default language 3 - Make sure 'English (en)' notice is not defined 4 - Make a payment on a patrons account 5 - Go to the patrons transactions and click 'Print' on the payment 6 - Is blank? 7 - Copy notice from default to english 8 - Try again, it works -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 14715] Results per page setting for catalog search in staff client and OPAC
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '21

10 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14715 --- Comment #118 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Wanted to add: it's not related to this bug or feature. And a tip: When the bug you think is related has already been closed/released, it's always better to open a new one with any findings and link them using depends or see also. Any patches/fixes will need a new bug number. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14715] Results per page setting for catalog search in staff client and OPAC
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '21

10 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14715 --- Comment #117 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hi Holly, when using OpacHiddenItems the results are filtered "after" paging, is what I was told, so it leaves holes in the result lists like you see. That cannot be changed easily it seems, which is why it was chosen to remove the numbering of results when OpacHiddenItems is used to hide this a bit. See also: bug 23923 and bug 18989 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14715] Results per page setting for catalog search in staff client and OPAC
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '21

10 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14715 Holly <hc(a)interleaf.ie> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hc(a)interleaf.ie --- Comment #116 from Holly <hc(a)interleaf.ie> --- I'm noticing something in situations where the OPAC is suppressing records that I would appreciate some feedback on. I walk through what I'm seeing below using a general example from a site I'm testing on. In the below example, the system preferences have been set so that the results per page dropdown appears and a search will show 10 results per page for both the OPAC and the staff side. 1. I use the advanced search on the OPAC to search for all items with a specific item type called "General items". 3. The results per page display shows that there should be 10 results on the first and all other pages. 4. There are actually 9 results on the first results page. 5. There are 10 results on all other pages. 6. Doing the same search on the staff side, the results per page display shows that there should be 10 results on the first and all other pages. 7. There are 10 results on the first page and all other pages. 8. The first result on the first page of the staff side does not appear on the OPAC. Looking at it, this seems to be because all items on the bibliographic record are marked as lost. 9. It is fine that the OPAC is not showing the suppressed record, but I would assume in cases like this, instead of showing nine results on the first page, it should show 10, moving the first result from the second page up one, and so on for all the other pages. To summarise, my understanding is that there should be 10 results on the first page of results, assuming that all subsequent pages have 10 or more results on them, even if one of the results for the first page is suppressed. Is anyone else seeing this? Would this require a new bug to be opened? -- You are receiving this mail because: You are watching all bug changes.

1 0