March 2010 - Koha-bugs - lists.koha-community.org

[Bug 4313] New: Language selected in staff client affects value of boolean sysprefs
by bugzilla-daemon＠kohaorg.ec2.liblime.com 15 Mar '10

15 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4313 Summary: Language selected in staff client affects value of boolean sysprefs Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: I18N/L10N AssignedTo: chris(a)bigballofwax.co.nz ReportedBy: magnus(a)enger.priv.no Estimated Hours: 0.0 Change sponsored?: --- When I have selected English as the language in the staff client i get this HTML in the syspref-editor: <select name="pref_NoZebra" id="pref_NoZebra" class="preference preference-choice"> <option value="1">Don't use</option> <option value="">Use</option> </select> the Zebra search engine... When I switch to Norwegian i get this: <select name="pref_NoZebra" id="pref_NoZebra" class="preference preference-choice"> <option value="yes">Don't use</option> <option value="no" selected="selected">Use</option> </select> the Zebra search engine... And the value that is actually stored in the DB is a "yes" or a "no", not a numeric value. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 2

[Bug 3222] New: ENH: add ability to set defaut message preferences per patron category
by bugzilla-daemon＠liblime.com 11 Mar '10

11 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3222 Summary: ENH: add ability to set defaut message preferences per patron category Product: Koha Version: HEAD Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P5 Component: Patrons AssignedTo: galen.charlton(a)liblime.com ReportedBy: galen.charlton(a)liblime.com Estimated Hours: 0.0 Deadline: 2009-06-01 Change sponsored?: Sponsored Enhancement project to make the following changes to Koha's patron messaging system: [1] Add the ability to define default patron messaging preferences for each patron category. E.g., so that you can say for new patrons of category 'patron' they'll get emailed overdue notices and checkout slips by default. [2] Use the category-level default preferences to set the initial patron preferences for a new patron record, created either via the patron editing page or patron import. [3] Move the patron messaging preferences form from the messaging tab to the patron editing form in the staff interface. [4] Fix a bug to prevent a hold-filled notification from being sent multiple times; send it only the first time it is put on the hold shelf. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 8

[Bug 4315] New: Add ability to put a note on a specific hold request
by bugzilla-daemon＠kohaorg.ec2.liblime.com 11 Mar '10

11 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4315 Summary: Add ability to put a note on a specific hold request Product: Koha Version: rel_3_4 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Hold requests AssignedTo: gmcharlt(a)gmail.com ReportedBy: wizzyrea(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- It is not strictly necessary, but the ability to place notes on a hold record would be a nice addition to the holds interface. The goal of this enhancement would be so I could make a note that "I am NEKLS staff, and that yes, this priority list is correct due to blah blah blah," and other staff members could see what the deal was. It also adds accountability. Other examples of notes one might want to put on a hold, to explain odd human behavior with the queues to other staff members: "we want this copy b/c it has notes in the margin" "we need our copy back for re-labeling" "original hold date 01/27/2010" These notes would only be visible to the staff. Also along these lines, it would be nice if you could tell if a hold was placed through the OPAC or Staff interface (good for statistics, you could then report on it, if the data was collected), and who created or last modified the hold (if through the staff interface). This allows for accountability of staff regarding the queues. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 4063] New: SIP Returns sometimes cause items to have dual statuses
by bugzilla-daemon＠kohaorg.ec2.liblime.com 11 Mar '10

11 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4063 Summary: SIP Returns sometimes cause items to have dual statuses Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: SIP2 AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: wizzyrea(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- Pictures really say it here: An item with dual statuses: http://screencast.com/t/YTk3ZGU2N2Qt Another item with dual statuses: http://screencast.com/t/NDU3YjQ3M Both of these items do have outstanding holds on them, that probably should have been triggered by going through the chute. I will try to get more examples and more thorough documentation of what exactly is happening to these items. We are using the NEKLS sponsored SIP2 code from LL with no further patches. This is not LEK. KF (irc) says she has also seen this issue, perhaps she can comment more. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 8

[Bug 3397] New: Deleting item record leaves a hole in patron's reading history
by bugzilla-daemon＠liblime.com 11 Mar '10

11 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3397 Summary: Deleting item record leaves a hole in patron's reading history Product: Koha Version: HEAD Platform: PC OS/Version: Windows 2000 Status: NEW Severity: normal Priority: P5 Component: Circulation AssignedTo: galen.charlton(a)liblime.com ReportedBy: mcoalwell(a)nekls.org Estimated Hours: 0.0 Change sponsored?: --- Deleted items continue to display in Fines, but disappear from the Reading History. See screen shot. Pull from deleted items table? Or pull title info from bib record? What if bib is also deleted? Not sure of the best solution. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 2

[Bug 4224] New: Holds queue report includes items already allocated
by bugzilla-daemon＠kohaorg.ec2.liblime.com 11 Mar '10

11 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=4224 Summary: Holds queue report includes items already allocated Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Hold requests AssignedTo: gmcharlt(a)gmail.com ReportedBy: oleonard(a)myacpl.org Estimated Hours: 0.0 Change sponsored?: --- When /misc/cronjobs/holds/build_holds_queue.pl builds the holds queue report, it looks for items which are available to fulfill an outstanding hold, in GetItemsAvailableToFillHoldRequestsForBib. It selects items which are available, not lost etc., and then excludes items ("AND itemnumber NOT IN") in this set: SELECT itemnumber FROM reserves WHERE biblionumber = ? AND itemnumber IS NOT NULL AND (found IS NOT NULL OR priority = 0) However, look at the data for an item which has been allocated for a hold but which isn't marked as waiting ("found = W") yet because it is in transit to its destination branch: reserves.itemnumber will not be NULL, but found *will* still be NULL. Therefore such items will NOT be excluded from the holds queue report. If this diagnosis is correct, that explains why my staff finds entries on the holds queue report which they have already checked in and sent through cargo delivery to other branches. >From IRC today: <gmcharlt> subquery would then either have to include a join on branchtransfers <gmcharlt> or perhaps define a new value for found : 'T' <gmcharlt> meaning that hte item is allocated for a hold but is in transit --- <gmcharlt> thinking about it a bit more, I think defining a found status of 'T' is the way to go <gmcharlt> but there are ~15 place that I'll need to check -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3

[Bug 3342] New: Changes to holds priority list should be logged for accountability.
by bugzilla-daemon＠liblime.com 11 Mar '10

11 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3342 Summary: Changes to holds priority list should be logged for accountability. Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Hold requests AssignedTo: galen.charlton(a)liblime.com ReportedBy: wizzyrea(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- When a library staff member changes a hold priority or moves a hold up or down the list, the change information should be logged to encourage accountability. Log information should include: - Which user did it - Date/Time stamp - Which Patron was moved and to which priority. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 2

[Bug 3319] New: Need a nicer error message when attempting to add a patron with no libraries defined
by bugzilla-daemon＠liblime.com 11 Mar '10

11 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3319 Summary: Need a nicer error message when attempting to add a patron with no libraries defined Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Patrons AssignedTo: galen.charlton(a)liblime.com ReportedBy: wizzyrea(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- The add patron screen should give a message (instead of a cryptic mysql borrowernumber=0 error) when a new koha user tries to add a patron but has no libraries defined. Additionally, should give an error message when a user tries to add a patron but has no patron types defined. Currently both conditions give inadequate or nonexistant errors. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 2

[Bug 2749] GMD (245h) display issues
by bugzilla-daemon＠kohaorg.ec2.liblime.com 11 Mar '10

11 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=2749 Sharon Moreland <smoreland(a)nekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |smoreland(a)nekls.org -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 0

[Bug 3920] New: XSLTdetailDisplay syspref controls both OPAC and Intranet XSLT detail display
by bugzilla-daemon＠kohaorg.ec2.liblime.com 11 Mar '10

11 Mar '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3920 Summary: XSLTdetailDisplay syspref controls both OPAC and Intranet XSLT detail display Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: major Priority: P5 Component: Staff Client AssignedTo: paul.poulain(a)biblibre.com ReportedBy: wizzyrea(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- The XSLTdetailDisplay syspref has an inaccurate description: Current verbiage: Enable XSL stylesheet control over details page display on OPAC WARNING: MARC21 Only Current behavior: Enabling this syspref turns on XSLT detail display for both OPAC and Intranet. Filing an additional bug related to other erroneous behavior related to this syspref, will update this bug with that number when I have it. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 9