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

[Bug 7163] New: BibLibre acquisitions omnibus
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '15

12 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7163 Bug #: 7163 Summary: BibLibre acquisitions omnibus Classification: Unclassified Change sponsored?: Sponsored Product: Koha Version: master Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: paul.poulain(a)biblibre.com ReportedBy: paul.poulain(a)biblibre.com QAContact: ian.walls(a)bywatersolutions.com Depends on: 5335, 5336, 5337, 5339, 5344, 5346, 5347, 5348, 5349, 5352, 5355, 5356, 5358, 5359, 5361, 5384, 7162 This entry contains pointers to enhancements related to acquisitions that must be submitted by BibLibre. Please don't close until all entries are closed -- 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 70

[Bug 7162] New: Factorize code for order cancellation
by bugzilla-daemon＠bugs.koha-community.org 12 Feb '15

12 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7162 Bug #: 7162 Summary: Factorize code for order cancellation Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: julian.maurice(a)biblibre.com ReportedBy: julian.maurice(a)biblibre.com QAContact: ian.walls(a)bywatersolutions.com Some code was duplicated, in the following patch all is now in a new file cancelorder.pl. It takes a 'referrer' parameter so it can easily be called from any page of Koha, and then redirect to it when it finish. Confirmation for cancellation is now done in this page (not in javascript). Add possibility to give a reason for cancellation (or other things, this is saved in aqorders.notes) DelOrder is modified to take two new parameters: - delete_biblio: if '1', try to delete biblio - reason: text to add to aqorders.notes (this note isn't show anywhere since there is no place to view cancelled orders, but another patch will add this feature). basket.pl and parcel.pl links to this page. -- 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 135

[Bug 12550] New: Add ability to delay loading of patron's checkouts in circulation and patron details
by bugzilla-daemon＠bugs.koha-community.org 11 Feb '15

11 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12550 Bug ID: 12550 Summary: Add ability to delay loading of patron's checkouts in circulation and patron 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Now that a patron's checkouts are loaded asynchronously, we can further improve Koha's performance by not loading the checkouts table when it is not needed. For example, if a librarian is checking out 5 items to a patron, we really don't need to load the table during the scanning of items 1 to 4, just for item 5. Another example would be browsing to the patron details table in order to change a patron's password. I propose we add two separate system preferences to add a timer for loading the patron's checkouts table, one for circulation and one for patron details. That way a library can choose to have enough delay so that most librarians can scan items repeatedly without loading the checkouts table, and can have the patron details table load more quickly if they wish. In addition, setting one or both timeouts to 0 will cause the system to act as it currently does. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 11641] New: ILS-DI: Some more work for HoldTitle and HoldItem
by bugzilla-daemon＠bugs.koha-community.org 10 Feb '15

10 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11641 Bug ID: 11641 Summary: ILS-DI: Some more work for HoldTitle and HoldItem 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This report is a follow-up on report 8918. This still needs some attention: 1) HoldTItle and HoldItem do not check for double reserve requests of a patron where Koha does. 2) The mandatory request_location parameter of HoldTitle does not seem to be used. Same for needed_before_date and pickup_expiry_date. 3) Also: needed_before_date, pickup_expiry_date in HoldItem. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 12041] New: Improve Koha::Cache
by bugzilla-daemon＠bugs.koha-community.org 10 Feb '15

10 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12041 Bug ID: 12041 Summary: Improve Koha::Cache Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: robin(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Koha::Cache can be improved to fall back more reliably, to handle complex data types, and so on. This is necessary to allow caching of things properly under plack. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 12842] New: Add classification to MARC21 XSLT detail page
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '15

09 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12842 Bug ID: 12842 Summary: Add classification to MARC21 XSLT detail page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Show classificatons from 082 and 084 in the MARC21 detail pages. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 12543] New: Add userid as matchpoint for "Import patrons" tool
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '15

09 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12543 Bug ID: 12543 Summary: Add userid as matchpoint for "Import patrons" tool Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The a patron's userid should be a matchpoint in the same manner as cardnumber. Though not enforced as a unique key by the database yet ( pending bug 1861 ), this field is effectively unique as uniqueness is enforced by Koha itself. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 12844] New: Introduce a centralized way to display prices
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '15

09 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12844 Bug ID: 12844 Summary: Introduce a centralized way to display prices Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org To display prices depending on the currency, Koha (and especially the acquisition module) needs a module to manage prices. -- You are receiving this mail because: You are watching all bug changes.

1 61

[Bug 12916] New: Use of uninitialized values $max and $min in C4/Tags.pm
by bugzilla-daemon＠bugs.koha-community.org 09 Feb '15

09 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12916 Bug ID: 12916 Summary: Use of uninitialized values $max and $min in C4/Tags.pm Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org If tag list is empty, sub stratify_tags issues a warning in opac-error.log because of uninitialized values $max and $min in C4/Tags.pm, line 600 -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 11924] New: warning about hold when item checked in at wrong library
by bugzilla-daemon＠bugs.koha-community.org 08 Feb '15

08 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11924 Bug ID: 11924 Summary: warning about hold when item checked in at wrong library 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: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This was received via email: ------------- I guess what I'm seeing as the problem is this: 1. PatronX places an item on hold for pickup at Library A. 2. Library B sends a copy of the item to Library A. 3. The item is checked in at Library A and Koha switches the status of the item to "Item is waiting for PatronX at Library A." 4. A staff member at Library A hands the item to PatronX and, for whatever reason, the item does not get checked out to PatronX. 5. PatronX uses the item and then returns it to Library C. 6. Staff at Library C checks in the item and Koha does nothing. When you look at the item record it says "Item is waiting for PatronX at Library A." Koha does not change the status of the item, it does not display a "Route to Library A" message, it does not change the holding location. Koha does nothing even though the item does not belong at Library C in any way shape or form. Yes, there is a procedure problem here. At step 4 the staff member at Library A screwed up and let PatronX leave the library building with an item that had not been checked out. What I'd like Koha to do is to give the staff at Library C some kind of alert when step 6 is reached so that staff at Library C know that the item is supposedly on hold at Library A. Since Koha doesn't do _anything_ at checkin, if this kind of mistake is made the error created by staff at Library A can be further complicated if staff at Library C are as inattentive as staff at Library A. So my question is, when an item that is supposed to be on hold and waiting for pickup at one branch gets checked in at a different branch, can Koha display some kind of a message? I really think that it ought to. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1