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

[Bug 15758] New: Move the C4::Branch related code to Koha::Libraries - part 4
by bugzilla-daemon＠bugs.koha-community.org 23 Jun '21

23 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15758 Bug ID: 15758 Summary: Move the C4::Branch related code to Koha::Libraries - part 4 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 15629 Blocks: 15293 This fourth and last part will remove: - GetBranchName - GetBranchesLoop - GetBranches - GetBranch will move mybranch and onlymine to C4::Context and finally remove all occurrences of C4::Branch. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15293 [Bug 15293] Move the C4::Branch related code to Koha::Libraries https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15629 [Bug 15629] Move the C4::Branch related code to Koha::Libraries - part 3 -- You are receiving this mail because: You are watching all bug changes.

1 169

[Bug 16181] New: Limit number of tags loaded initially for tag cloud
by bugzilla-daemon＠bugs.koha-community.org 09 Jun '21

09 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16181 Bug ID: 16181 Summary: Limit number of tags loaded initially for tag cloud Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When a patron has an large number of tags (say 3,421) the tag cloud takes an inordinately long time to load. Maybe we could enforce a limit on initial load and then allow user to load more or paginate through all? -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 16785] New: Autocomplete broken on overdues report
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '21

08 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16785 Bug ID: 16785 Summary: Autocomplete broken on overdues report Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/circ/overdue.pl OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Circulation Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, koha-bugs(a)lists.koha-community.org, kyle.m.hall(a)gmail.com If you have a patron attribute defined which is searchable and linked to an authorized value, that attribute will show up in the overdue report filter form as an autocomplete field. The autocomplete is broken for cases where more than one result is returned by the search. -- You are receiving this mail because: You are watching all bug changes. You are on the CC list for the bug.

1 20

[Bug 15683] New: Inconsistent population of lastreneweddate between AddRenewal and AddIssue
by bugzilla-daemon＠bugs.koha-community.org 12 May '21

12 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15683 Bug ID: 15683 Summary: Inconsistent population of lastreneweddate between AddRenewal and AddIssue Change sponsored?: --- Product: Koha Version: 3.20 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When lastreneweddate is populated via C4::Circulation::AddRenewal, it is added as a date, whereas C4::Circulation::AddIssue stores it as DateTime, i.e. hours, minutes and seconds are populated. Because of hourly loans, I think that it only makes sense to store lastreneweddate as a full datetime. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 16486] New: Display the TIME a fine was collected/written off
by bugzilla-daemon＠bugs.koha-community.org 11 May '21

11 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16486 Bug ID: 16486 Summary: Display the TIME a fine was collected/written off Change sponsored?: --- Product: Koha Version: 3.20 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: theod(a)lib.auth.gr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In many cases it would be very useful to be able to know the time a fine was collected/written off (in addition to the date). So ideally, the TIME could be shown next to the date in the Fines->Account tab. (This would make sense in almost all cases except maybe in Accruing fines). Alternatively, a text could be added to the description column. For example, "Payment, thanks" could become "Payment on 15/09/2015 14:30, thanks", "Writeoff" could become "Written off on 15/09/2015 14:30", etc -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 93

[Bug 17202] New: Deleting a rotating collection with items should either be prohibited or items should be removed
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '21

30 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17202 Bug ID: 17202 Summary: Deleting a rotating collection with items should either be prohibited or items should be removed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: Create a rotating collection Add an item Delete the rotating collection View the db (SELECT * FROM collections_tracking;) The item is still in the collection -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 16787] New: 'Too many holds' message appears inappropriately and is missing data
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '21

29 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16787 Bug ID: 16787 Summary: 'Too many holds' message appears inappropriately and is missing data Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com bug 11250 changed the holds message to be and if,elsif loop, falling through to catch the first appropriate message bug 13116 changed the reporting from CanItemBeReserved causing tooManyHolds to trigger when no holds are allowed A side effect is that 'maxreserves' is only passed to the template when there are too many reserves, but the too many reserves message is called when no holds are available To recreate: Set maxreserves to 50 Set some item type to allow 0 holds Attempt to place a hold on a record with that itemtype Message will be "Too many holds: [Firstname Surname] can only place a maximum of total holds." Message should be "[Firstname Surname] cannot place any holds on these items." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 100

[Bug 16335] New: Refactor OpacHiddenItems
by bugzilla-daemon＠bugs.koha-community.org 23 Apr '21

23 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16335 Bug ID: 16335 Summary: Refactor OpacHiddenItems 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: mtompset(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org See 14385 and 10589 as well. The problem is this functionality would be better written using the newer Koha::RecordProcessor filtering functionality. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 16628] New: Patrons requesting modifications link behaves differently on the home page than the members-home.pl page
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '21

02 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16628 Bug ID: 16628 Summary: Patrons requesting modifications link behaves differently on the home page than the members-home.pl page Change sponsored?: --- Product: Koha Version: 3.22 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 It would appear that the links do not behave the same between the members-update.pl page and mainpage.pl. When IndependentBranchesPatronModifications is set to Prevent, the link on mainpage.pl shows the count for your library, and only shows when your library has requests. However, the link ALWAYS shows on members-update.pl, and shows the total of all requests. I don't believe any other feature in Koha works this way, and I don't believe this should be the behavior of this feature. In my opinion, the link on mainpage.pl behaves correctly, and the link on members-update.pl should be changed to do the same. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 15729] New: SIP server allows checkin of reserved item
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '21

30 Mar '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15729 Bug ID: 15729 Summary: SIP server allows checkin of reserved item Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: bc(a)interleaf.ie QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com At present the SIP server will allow an item to be returned even if there is an outstanding hold on it. Some libraries do not see this as an issue and run reports for reserves before re-shelving. However, some prefer to have the item denied at the selfservice unit and force the borrower to return the item to the desk. With this in mind there should be a SIP systempreference which allows libraries to specify if a reserved item should be permitted to be checked in via the selfservice unit -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16