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

[Bug 9470] New: Secondary and Other Phone Listings are reversed in patron record after creating
by bugzilla-daemon＠bugs.koha-community.org 06 Feb '13

06 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9470 Bug ID: 9470 Summary: Secondary and Other Phone Listings are reversed in patron record after creating Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: fred.pierre(a)smfpl.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Create a new patron with required fields filled. Assign a secondary phone number, for example 123-456-7890 Assign an other phone number, for example 111-111-1111 Save the patron record View the newly-created patron record. The secondary number will be 111-111-1111 The other number will be 123-456-7890 The two fields have been reversed. Patrons notification may malfunction if text messages are being sent, or calls may be inadvertently sent to mobile, possibly incurring fees for the patron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 9516] New: Item Availability/Data missing from OPAC tag search
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '13

05 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9516 Bug ID: 9516 Summary: Item Availability/Data missing from OPAC tag search Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au For example: .../cgi-bin/koha/opac-search.pl?tag=Important&q=Important "Availability: No items available:" appears for each result, even if there actually are items available. This is because the raw marc is being retrieved straight from the database without having any item data embedded in it... If you do a regular search, you will get the correct item availability. I assume this is because Koha adds the item information to the MARCXML before passing it to Zebra which returns the item data inside the raw MARC... -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 4437] acq.js uses XMLHttpRequest() directly; should use jQuery
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '13

05 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4437 Owen Leonard <oleonard(a)myacpl.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #6 from Owen Leonard <oleonard(a)myacpl.org> --- Can you please add a test plan for this? acq.js is modified in several places, so I assume several different functions are being affected. A test plan will ensure that we test all the changes properly. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 9399] New: Accessibility - Search box options aren't buttons
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '13

05 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9399 Bug ID: 9399 Summary: Accessibility - Search box options aren't buttons Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: bart.tj(a)gmail.com CC: gmcharlt(a)gmail.com the options under the search box on most pages (eg: on the mainpage: checkout, check in, search patrons... etc.) are not classed as buttons which means screen readers read them separately to the search box and it isn't clear that they are related, or that changing the options effects the box. In addition to this on some pages there are identically named links that are very difficult to distinguish between when only using a screen reader. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 2720] Overdues which debar automatically should undebar automatically when returned
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '13

05 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2720 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #15051|0 |1 is obsolete| | --- Comment #13 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 15052 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15052&action=edit Bug 2720 - Overdues which debar automatically should undebar automatically when returned This patch adds a more extensible and flexible debarments system to Koha. The fields borrowers.debarred and borrowers.debarredcomment are retained for compatibility and speed. This system supports having debarments for multiple reasons. There are currently three types of debarments: OVERDUES - Generated by overdue_notices.pl if the notice should debar a patron SUSPENSION - A punative debarment generated on checkin via an issuing rule MANUAL - A debarment created manually by a librarian OVERDUE debarments are cleared automatically when all overdue items have been returned, if the new system preference AutoRemoveOverduesRestrictions is enabled. It is disabled by default to retain current default functionality. Whenever a borrowers debarments are modified, the system updates the borrowers debarment fields with the highest expiration from all the borrowers debarments, and concatenates the comments from the debarments together. Test plan: 1) Apply patch 2) Run updatedatabase.pl 3) Verify the borrower_debarments table has been created and populated with the pre-existing debarments 4) Run t/db_dependent/Borrower_Debarments.t 5) Manually debar a patron, with an expiration date 6) Verify the patron cannot be issued to 7) Add another manual debarment with a different expiration date 8) Verify the 'restricted' message lists the date farthest into the future 9) Add another manual debarment with no expiration date 10) Verify the borrower is now debarred indefinitely 11) Delete the indefinite debarment 12) Verify the debarment message lists an expiration date dagain 13) Enable the new system preference AutoRemoveOverduesRestrictions 14) Set an overdue notice to debar after 1 day of being overdue 15) Check out an item to a patron and backdate the due date to yesterday 16) Run overdue_notices.pl 17) Verify the OVERDUES debarment was created 18) Return the item 19) Verify the OVERDUES debarment was removed 20) Disable AutoRemoveOverduesRestrictions 21) Repeat steps 15 though 18, verify the OVERDUES debarment was *not* removed 22) Add issuing rules so that an overdue item causes a temporary debarment 23) Check out an item to a patron and backdate the due date by a year 24) Return the item 25) Verify the SUSPENSION debarment was added to the patron -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 2720] Overdues which debar automatically should undebar automatically when returned
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '13

05 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2720 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #15050|0 |1 is obsolete| | --- Comment #12 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 15051 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15051&action=edit Bug 2720 - Overdues which debar automatically should undebar automatically when returned This patch adds a more extensible and flexible debarments system to Koha. The fields borrowers.debarred and borrowers.debarredcomment are retained for compatibility and speed. This system supports having debarments for multiple reasons. There are currently three types of debarments: OVERDUES - Generated by overdue_notices.pl if the notice should debar a patron SUSPENSION - A punative debarment generated on checkin via an issuing rule MANUAL - A debarment created manually by a librarian OVERDUE debarments are cleared automatically when all overdue items have been returned. Whenever a borrowers debarments are modified, the system updates the borrowers debarment fields with the highest expiration from all the borrowers debarments, and concatenates the comments from the debarments together. Test plan: 1) Apply patch 2) Run updatedatabase.pl 3) Verify the borrower_debarments table has been created and populated with the pre-existing debarments 4) Run t/db_dependent/Borrower_Debarments.t 5) Manually debar a patron, with an expiration date 6) Verify the patron cannot be issued to 7) Add another manual debarment with a different expiration date 8) Verify the 'restricted' message lists the date farthest into the future 9) Add another manual debarment with no expiration date 10) Verify the borrower is now debarred indefinitely 11) Delete the indefinite debarment 12) Verify the debarment message lists an expiration date dagain 13) Set an overdue notice to debar after 1 day of being overdue 14) Check out an item to a patron and backdate the due date to yesterday 15) Run overdue_notices.pl 16) Verify the OVERDUES debarment was created 17) Return the item 18) Verify the OVERDUES debarment was removed 19) Add issuing rules so that an overdue item causes a temporary debarment 20) Check out an item to a patron and backdate the due date by a year 21) Return the item 22) Verify the SUSPENSION debarment was added to the patron -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 2720] Overdues which debar automatically should undebar automatically when returned
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '13

05 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2720 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #15045|0 |1 is obsolete| | --- Comment #11 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 15050 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15050&action=edit Bug 2720 - Overdues which debar automatically should undebar automatically when returned This patch adds a more extensible and flexible debarments system to Koha. The fields borrowers.debarred and borrowers.debarredcomment are retained for compatibility and speed. This system supports having debarments for multiple reasons. There are currently three types of debarments: OVERDUES - Generated by overdue_notices.pl if the notice should debar a patron SUSPENSION - A punative debarment generated on checkin via an issuing rule MANUAL - A debarment created manually by a librarian OVERDUE debarments are cleared automatically when all overdue items have been returned. Whenever a borrowers debarments are modified, the system updates the borrowers debarment fields with the highest expiration from all the borrowers debarments, and concatenates the comments from the debarments together. Test plan: 1) Apply patch 2) Run updatedatabase.pl 3) Verify the borrower_debarments table has been created and populated with the pre-existing debarments 4) Run t/db_dependent/Borrower_Debarments.t 5) Manually debar a patron, with an expiration date 6) Verify the patron cannot be issued to 7) Add another manual debarment with a different expiration date 8) Verify the 'restricted' message lists the date farthest into the future 9) Add another manual debarment with no expiration date 10) Verify the borrower is now debarred indefinitely 11) Delete the indefinite debarment 12) Verify the debarment message lists an expiration date dagain 13) Set an overdue notice to debar after 1 day of being overdue 14) Check out an item to a patron and backdate the due date to yesterday 15) Run overdue_notices.pl 16) Verify the OVERDUES debarment was created 17) Return the item 18) Verify the OVERDUES debarment was removed 19) Add issuing rules so that an overdue item causes a temporary debarment 20) Check out an item to a patron and backdate the due date by a year 21) Return the item 22) Verify the SUSPENSION debarment was added to the patron -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 5287] New: Would be nice to have search result options repeated at bottom of page, and page nav repeated at top of list
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '13

05 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5287 Summary: Would be nice to have search result options repeated at bottom of page, and page nav repeated at top of list Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: lmschatt(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 After doing a search in the OPAC, the following options appear at the top of each page of results: Select All Clear All Highlight / Unhighlight Add to: Place Hold At the bottom of the page of search results, you can navigate to other pages of search results. It would be nice to be able to do all of those at either the top or the bottom of the page. I often scroll down the list, checking off items to add to the cart. I then have scroll all the way back up to add them, and then scroll all the way back down to navigate to the next page. It would be nice to eliminate some of the scrolling. -- 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 1

[Bug 4282] acq stats misleading
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '13

05 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4282 --- Comment #1 from Nicole C. Engard <nengard(a)gmail.com> --- This is still an issue - the word Budgets in used in place of Funds in a few places and should be fixed. Nicole -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 3361] Option to choose the number of titles to display in a list page.
by bugzilla-daemon＠bugs.koha-community.org 05 Feb '13

05 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3361 Nicole C. Engard <nengard(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED CC| |nengard(a)gmail.com Resolution|--- |WORKSFORME --- Comment #1 from Nicole C. Engard <nengard(a)gmail.com> --- I think this now controlled by the search results XSLT and as such shows the same number of results as the search - so it's now settable ... I could be wrong ... reopen if I am. -- You are receiving this mail because: You are watching all bug changes.

1 0