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

[Bug 13701] Sharing lists: Text hardcoded to 2 weeks, but could be any time frame
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13701 --- Comment #10 from Alex Buckley <alexbuckley(a)catalyst.net.nz> --- Yeah that sounds good. In that case I'll create a new bug report a bit later on today, which depends on this one, for the new syspref. And leave this one as it is ready for testing. Thanks Katrin! -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13701] Sharing lists: Text hardcoded to 2 weeks, but could be any time frame
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13701 --- Comment #9 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hm, there are advantages to both - and both would be ok. I think this as it stands now could be a candidate for backporting to older versions (but depends on the RMaints) while a new pref would be a new feature. So maybe splitting it might be nicer? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13701] Sharing lists: Text hardcoded to 2 weeks, but could be any time frame
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13701 --- Comment #8 from Alex Buckley <alexbuckley(a)catalyst.net.nz> --- Awesome, thank you for sharing your thoughts on that Katrin. Glad you like the idea :) Do you think it is alright for me to implement both the standard text and new syspref in this bug report, or put adding the new syspref on a separate bug report? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 26823] New: Locked account should display in ANY patron page, not just checked out or details
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26823 Bug ID: 26823 Summary: Locked account should display in ANY patron page, not just checked out or details Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 23979 adds the check out (circulation.pl) page for displaying the warning that the patron account is locked, but really this should be displayed on any tab in the patron account, and the edit page and change password page. Why leave this bit of information to be discovered only on some of the patron pages? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 13701] Sharing lists: Text hardcoded to 2 weeks, but could be any time frame
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13701 --- Comment #7 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I love the idea :) We might still need a standard text as a fallback for when the cron value is used, but we could have the best of all worlds. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 18958] New: If patron has multiple record level holds on one record transferring first hold causes next hold to become item level
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18958 Bug ID: 18958 Summary: If patron has multiple record level holds on one record transferring first hold causes next hold to become item level 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Imagine you have a record with 3 items, each item is held by LibraryA, LibraryB and LibraryC respectively. Now, a patron places to record level holds for pickup at LibraryD. When any of the items are checked in, that item is trapped to fill the first hold, but a side affect is that the next open hold because item level for the item that was just checked in! This is clearly incorrect and prevents the patron from placing more record level holds on the record. To reproduce: 1. Create and use a patron that can place multiple record level holds per record 2. Create a record with X items, each at a different library 3. Place X 'Next available' holds on the record for the patron using the 'Holds to place' box 4. Check in LibraryA's copy as LibraryA and confirm the hold 5. Revisit request.pl for the record, notice the next hold in line is now item-specific 6. Attempt to place another hold for your patron, notice that it requires an item-specific hold -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 119

[Bug 23212] New: Patron request modifications enhancement
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23212 Bug ID: 23212 Summary: Patron request modifications enhancement Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- Currently patron request modifications are an all or none request. Sometimes requests are entered with mistakes. Sometimes patrons are requesting some changes that are questionable, like a complete name change, or removing a birth date. I would like to suggest that each line of request have an approve, deny, or follow-up radio box. If follow-up is chosen, staff have the ability to add a question, and the question is posed to the patron when they log in to the OPAC. Maybe an e-mail notification of the question, if they have e-mail. Once they answer that question, that particular line request is submitted again with the staff question and patron answer. I would also like to suggest that the new value be editable, so if staff need to format something, or fix an obvious mistake, they can. Right now, if we see something like this, we have to click on the patron link to open the account, accept the changes, refresh the patron page, and fix the mistake. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 26822] New: Linking with subject heading dates with question mark failing
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26822 Bug ID: 26822 Summary: Linking with subject heading dates with question mark failing Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: joe(a)flo.org QA Contact: testopia(a)bugs.koha-community.org The issue arises when there is a "?" in the dates in a subject field. I'm told by one of our catalogers that this is the correct way according to LOC to catalog an uncertain date in a subject heading. The problem is that when the "?" is part of the date, it breaks the subject linking. Two examples: 1. Incorrect subject heading, linking works: Thomas, à Becket, Saint, 1118-1170 2. Correct subject heading, linking does not work: Thomas, à Becket, Saint, 1118?-1170 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 26452] New: overdue_notices causes "uninitialized value in string"
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26452 Bug ID: 26452 Summary: overdue_notices causes "uninitialized value in string" Change sponsored?: --- Product: Koha Version: 20.05 Hardware: PC OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: wyneken(a)physik.uni-freiburg.de QA Contact: testopia(a)bugs.koha-community.org I just updated my Koha from 17.05 to 20.05 when I upgraded the server from Debian Stretch to Debian Buster. Now when I execute: koha-foreach --chdir --enabled --email /usr/share/koha/bin/cronjobs/overdue_notices.pl -t I get the following error/warning: Use of uninitialized value in string eq at /usr/share/koha/lib/C4/Overdues.pm line 663. Can anybody tell me what this means? Is it a big problem? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 22834] New: Add a method for plugins to return the absolute path for bundled files
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22834 Bug ID: 22834 Summary: Add a method for plugins to return the absolute path for bundled files 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: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Koha::Plugins::Base inherits from Module::Bundled::Files, which is handy to pack assets together and have a simple way to calculate the asset's path. It would help developing new features to have a way to retrieve the absolute path. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40