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

[Bug 6392] New: Highlighting hold requests upon checkin
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6392 Bug #: 6392 Summary: Highlighting hold requests upon checkin Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Hold requests AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: bedmondsfcl(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com It would be a big help to circulation staff who are checking in stacks of items if the items on hold could be highlighted as they are scanned in the event that the staff person misses the hold screen as they scanning in the big stack. thank you, Beth Edmonds -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 3

[Bug 7595] New: Add branchcode to accountlines
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7595 Bug #: 7595 Summary: Add branchcode to accountlines Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_8 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: kyle.m.hall(a)gmail.com QAContact: koha.sekjal(a)gmail.com CC: gmcharlt(a)gmail.com For the purposes of statistics, it appears that it would help many libraries to have branchcode recorded in the accountlines table. For payments, the field would contain the code for the branch the payment was made at. For manual invoices, it would be the code of the library that created the invoice. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 55

[Bug 9834] New: Should reverting a waiting hold keep the item number?
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9834 Bug ID: 9834 Summary: Should reverting a waiting hold keep the item number? Classification: Unclassified 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: m.de.rooy(a)rijksmuseum.nl CC: gmcharlt(a)gmail.com When you confirm a hold, the item number is saved with the reserve. In case you revert the waiting status for some reason (probably exceptional), the hold becomes an item level hold. Unfortunately, you cannot know anymore if that was the case when the hold was placed. I would argue that it is more likely that it was not a item level hold. So why not remove the item number by default? Could we add a checkbox when doing the revert allowing the librarian to actively say "keep the item number" ? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 8562] New: RandomizeHoldsQueueWeight ignored if StaticHoldsQueueWeight is empty.
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8562 Priority: P5 - low Change sponsored?: --- Bug ID: 8562 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: RandomizeHoldsQueueWeight ignored if StaticHoldsQueueWeight is empty. Severity: minor Classification: Unclassified OS: All Reporter: kyle(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha If StaticHoldsQueueWeight is empty, but RandomizeHoldsQueueWeight is enabled, the script build_holds_queue.pl should select branches for fulfillment requests at random. Instead, it will select them in alphabetical order. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 5159] New: HomeOrHoldingBranch syspref description misleading
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5159 Summary: HomeOrHoldingBranch syspref description misleading Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: jwagner(a)ptfs.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 The old syspref description for HomeOrHoldingBranch implies it's only used with Independent Branches on: "Used by Circulation to determine which branch of an item to check with independent branches on, and by search to determine which branch to choose for availability." However, it seems to also affect transfers in systems where Independent Branches is not on (if set to holding branch, a checkin doesn't trigger a transfer message back to the owning branch). And it's also used by C4/Search.pm to control the branch description that shows in search results/record displays. The 3.2 syspref description is: Use the checkout and fines rules of (equiv description of home or holding branch) NOTE: This is older than CircControl, but used by some parts of Koha. It will be removed soon. First question, then, is whether there are plans to remove this syspref, as implied by the 3.2 description? And if so, what's going to happen to the other areas that it's now controlling? This came up in a discussion on the IRC about Bug 3262 -- the section of Search.pm that controls what library branch displays is in turn controlled by this syspref. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.

1 4

[Bug 7717] New: Multiple Identical Holds
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7717 Priority: P3 Change sponsored?: Sponsored Bug ID: 7717 CC: gmcharlt(a)gmail.com Assignee: mjr(a)ttllp.co.uk Summary: Multiple Identical Holds QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: mjr(a)ttllp.co.uk Hardware: All Status: ASSIGNED Version: unspecified Component: Hold requests Product: Koha Koha should optionally allow staff to reserve the same book more than once for the same borrower (but alert staff that it is already reserved for that borrower). -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 8010] New: Search history can be added to the wrong patron
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8010 Priority: P5 - low Change sponsored?: --- Bug ID: 8010 Assignee: oleonard(a)myacpl.org Summary: Search history can be added to the wrong patron QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: anthony.laquerre(a)ccsr.qc.ca Hardware: All Status: NEW Version: rel_3_6 Component: OPAC Product: Koha Search history is added to the next person that log in. *EnableOpacSearchHistory is activated. 1- Go on your OPAC. 2- Dont log in. 3- Do couple of search. 4- Login your account (opac) 5- Click on search history. If you really login yourself that's okay. But for public computer, this is a big problem since it's not necessary you that will login next.. A patron ask us why there was so many search in his account. He was sure it was a security problem where a student was able to hack his account/the system. Tested on On ByWater- Koha demo site : 3.07.00.044 + our site : 3.6.0 Maybe the search history should be cleared once someone login ? Let me know if you need more infos. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 7340] New: emailLibrarianWhenHoldIsPlaced enhancement
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7340 Bug #: 7340 Summary: emailLibrarianWhenHoldIsPlaced enhancement Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_0 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: spl(a)metrocast.net QAContact: ian.walls(a)bywatersolutions.com CC: gmcharlt(a)gmail.com This preference currently results in an email to the librarian whenever a hold is placed, even if the hold is placed by staff. I think it would be good to add a preference that excludes those holds, limiting emails to instances where holds are patron-initiated. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3

[Bug 7183] New: consistency of displays
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7183 Bug #: 7183 Summary: consistency of displays Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: paul.poulain(a)biblibre.com QAContact: ian.walls(a)bywatersolutions.com Blocks: 7119 There is no consistency for most displays in Koha. Sometimes, patron information is displayed John, Doe +123 45 67 89, New York sometimes Doe, John, New York Adult Sometimes <b>John Doe</b> Adult, New York ... Template Toolkit can help us having a consistent display: we should define basic objects and how they are displayed is managed in a specific include, ensuring consistency. A first list of objects: * biblio * biblio+item (location, without availability, like what is displayed in item bulkmodification, cart,...) * biblio+item (location and availability like what is displayed in circulation/hold pages) * patron -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 1

[Bug 8731] New: Holds Log to track the number of times a hold is overriden
by bugzilla-daemon＠bugs.koha-community.org 20 Dec '15

20 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8731 Priority: P5 - low Change sponsored?: --- Bug ID: 8731 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Holds Log to track the number of times a hold is overriden Severity: enhancement Classification: Unclassified OS: All Reporter: melia(a)bywatersolutions.com Hardware: All Status: NEW Version: unspecified Component: Hold requests Product: Koha There is not currently a way to track the number of times a Hold is overriden (i.e. that the book is checked out to someone other than the patron who currently has a hold on it). I think it would be nice to have a Holds Log that keeps track of this info so I could understand how often this happens and if there is any abuse of this "override". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4