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

[Bug 28092] New: Holds to pull needs to include reserve notes
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '21

12 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28092 Bug ID: 28092 Summary: Holds to pull needs to include reserve notes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 Holds to pull (pendingreserves.pl) does not currently include a column for reserve notes. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 24197] New: Custom destination for failed overdue notices
by bugzilla-daemon＠bugs.koha-community.org 12 Oct '21

12 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24197 Bug ID: 24197 Summary: Custom destination for failed overdue notices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Notices Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Currently failed overdue notices are sent to the branch email , or when that is not set to the KohaAdminEmailAddress syspref. Several of our clients have requested a seperate email address for failed overdue notices to be sent to. This email address will be defined in the: RedirectAddressForFailedOverdueNotices syspref. -- You are receiving this mail because: You are watching all bug changes.

1 40

[Bug 28358] New: Some oddities with page titles in OPAC
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '21

11 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28358 Bug ID: 28358 Summary: Some oddities with page titles in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org While translating, I spotted these that might need a little work: I think this could read a little better as: Your IDREF search with PPN I happen to know that PPN is PICA Production Number belonging to an OCLC product. Your search IDREF for ppn %s &rsaquo; %s%s%sKoha online%s catalog There are some (unwanted?) repeats here: Your messaging settings &rsaquo; %s%s%s%sKoha online%s%sKoha online%s catalog Most popular titles &rsaquo; %s%s%sKoha online%s catalogMost popular titles -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 28650] New: Assumed branchcode variable appears to be empty
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '21

11 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28650 Bug ID: 28650 Summary: Assumed branchcode variable appears to be empty Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Found on bug 27948, but it occurs more often. We expect the variable branchcode in the template just like e.g. the lang variable. And we use it in a call to KohaNews.get. Example from opac-suggestions template: [% SET opacsuggestion = KohaNews.get( location => "OpacSuggestioninstructions", lang => lang, library => branchcode ) %] But unfortunately we do not have a general branchcode variable. So what we get is the All branches output, not the branch one. Should we fill branchcode in Auth.pm? Or call Branches.GetLoggedInBranchcode in the template? -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 22964] New: Change "product" language on bugzilla bug report page
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '21

11 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22964 Bug ID: 22964 Summary: Change "product" language on bugzilla bug report page Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Bugzilla Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: donna(a)kattekrab.net Target Milestone: --- Created attachment 89957 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=89957&action=ed… screenshot of the "select product" text on bugzilla When filing a bug, we see these words: First, you must pick a product on which to enter a bug: Koha: Koha - Free Software ILS Koha security: Security bugs for Koha. Please use this product ONLY if you are reporting a security bug that should be held in confidence prior to the release of a fix. Project Infrastructure: For logging bugs related to the Koha project infrastructure. Not Koha itself. You almost certainly don't want to log a bug here, but under the Koha project. I find "Pick a product" and "Use this product" to be a bit confusing in this context. Here's some alternative phrasing to consider. First, you need to decide where to enter a bug: Koha: Koha Free Software ILS (integrated library system) Koha security: Security bugs for Koha. Use this ONLY if you are reporting a security big that should be held in confidence prior to the release of a fix. Project Infrastructure: Bugs related to the Koha project infrastructure (eg bugzilla, gitlab, or the project website. Not for Koha itself. You almost certainly don't want to log a bug here, but under the Koha project. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 18328] New: There is no history for article request
by bugzilla-daemon＠bugs.koha-community.org 11 Oct '21

11 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18328 Bug ID: 18328 Summary: There is no history for article request Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Il would be useful if the "Cancelled requests" and "Completed requests" of articles request were kept in different tabs, just like it exists for acquisition suggestions. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 29073] New: Hold expiration added to new holds when DefaultHoldExpirationdate turned off
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '21

09 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29073 Bug ID: 29073 Summary: Hold expiration added to new holds when DefaultHoldExpirationdate turned off Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: nick(a)bywatersolutions.com Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 26498 to recreate: - turn on DefaultHoldExpirationdate, place a hold, confirm it has an expiration date - turn off DefaultHoldExpirationdate, place a hold, confirm it still has an expirtion date we're saving "no" rather than 0, which is breaking checks further along. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26498 [Bug 26498] Add option to set a default expire date for holds at reservation time -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 22829] New: Elasticsearch - some blank subfields cause parsing errors during indexing
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '21

08 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22829 Bug ID: 22829 Summary: Elasticsearch - some blank subfields cause parsing errors during indexing 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: nick(a)bywatersolutions.com Target Milestone: --- Some fields in the record cause errors during indexing if they exist but are blank To recreate: 1 - Use the koha sample data or edit a record using the advanced cataloging editor and blank 100$a (probably also shouldn't be allowed) 2 - Save record 3 - Reindex ES 4 - Note you cannot search for the record bug 22828 will show you the error from ES -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 22004] New: When decreaseLoanHighHolds is set to Enable, suspended holds still count in the number of holds
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '21

08 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22004 Bug ID: 22004 Summary: When decreaseLoanHighHolds is set to Enable, suspended holds still count in the number of holds Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The system preference decreaseLoanHighHolds if set to enable allows the library to modify the checkout length if a records has X number of holds. Unfortunately, Koha will look at the holds and determine to use this system preference and not discard the suspended holds. For example if a library had this system preference to decrease the loan period if a record has 2 holds on it, if there are 2 holds on the item, but one hold has been suspended, then Koha should not decrease the checkout period - however it does. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 27725] New: Use JavaScript to set history state during patron search
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '21

08 Oct '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27725 Bug ID: 27725 Summary: Use JavaScript to set history state during patron search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Patrons Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The patron search page can be annoying because it never remembers where you left off. If I click a letter to browse by last name, follow a link, and then back up, the page doesn't remember that I was in the middle of a search. There are a lot of aspects which can be improved, but I have a patch which will address the specific case of the first letter search ("Browse by last name"). -- You are receiving this mail because: You are watching all bug changes.

1 25