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

[Bug 6833] New: Notifications Rewrite
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '13

12 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6833 Bug #: 6833 Summary: Notifications Rewrite Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Notices AssignedTo: henridamien(a)koha-fr.org ReportedBy: tdavis(a)uttyler.edu QAContact: koha-bugs(a)lists.koha-community.org http://wiki.koha-community.org/wiki/Notifications_RFC -- 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 7

[Bug 8260] New: Routing List Ranking Needs Re-order After Patron Delete
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '13

12 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8260 Priority: P5 - low Change sponsored?: --- Bug ID: 8260 CC: colin.campbell(a)ptfs-europe.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Routing List Ranking Needs Re-order After Patron Delete Severity: minor Classification: Unclassified OS: All Reporter: dcook(a)prosentient.com.au Hardware: All Status: NEW Version: master Component: Serials Product: Koha Currently, deleting a patron will create a missing value in the ranking of members in a routing list. For instance, the ranking will go 1, 2, 3, 5 in the database when the patron ranked at #4 is deleted. This causes the intranet to display these rankings as 1, 2, 3, 1, since 5 is not a valid option due to there only being 4 entries in the database. I've written up a little re-order function based on the reorder_members function, which just re-orders all the members for that routing list every time routing.pl or routing-preview.pl are called. It might be more ideal to only run it if errors are detected, but that error detection would require more code that might just add more bulk. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 7032] New: can select multiple layouts to edit
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '13

12 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7032 Bug #: 7032 Summary: can select multiple layouts to edit Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All URL: cgi-bin/koha/labels/label-manage.pl?label_element=layo ut OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Label printing AssignedTo: cnighswonger(a)foundations.edu ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org I've noticed that I am allowed to check off more than one layout in the list of layouts. It's not a big deal, since the system tells me to choose only one layout to edit, but it seems like those check boxes should be exclusive (I can't come up with the right term for it) -- so if I check one box and then check another box, the initial check should go away when I check box #2 or they should be radio buttons instead. -- 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 13

[Bug 7881] New: display additional fields in the staff client
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '13

12 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7881 Priority: P5 - low Change sponsored?: --- Bug ID: 7881 CC: gmcharlt(a)gmail.com Assignee: paul.poulain(a)biblibre.com Summary: display additional fields in the staff client QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: melia(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Staff Client Product: Koha Display additional fields in the staff client: For example, the $c of the 260 field might contain two dates, separated by a comma -- $c1991, 1977. When one views this record in any display other than MARC, one gets just part of the date, usually whatever comes after the comma, rather than all the date information. This can be misleading. Can the display be altered to include ALL of the information contained in $c? Would also like to display the rest of the 245 field ($b, $n, $p, etc.). -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 7536] New: delete permissions
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '13

12 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7536 Bug #: 7536 Summary: delete permissions Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha.sekjal(a)gmail.com It would be nice if there were a delete permission for cataloging. Right now if you can edit you can delete, but it would be nice to allow only select people to delete and more people to edit. -- 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 8

[Bug 8031] New: get rid of older notices from the patron notices tab
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '13

12 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8031 Priority: P5 - low Change sponsored?: --- Bug ID: 8031 Assignee: henridamien(a)koha-fr.org Summary: get rid of older notices from the patron notices tab Severity: enhancement Classification: Unclassified OS: All Reporter: melia(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Notices Product: Koha Created attachment 9380 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=9380&action=edit Notices tab on patron record Would like a way to delete or filter the notices that show up on the notices tab of the patron record. Looking at ALL of the notices can make for a long and unwieldy list - could we make it so that the library could choose to see only the notices from the last two months, for example? -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 7075] New: Fine in days values are returned for patrons with past overdues when fine in days is set to 0
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '13

12 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7075 Bug #: 7075 Summary: Fine in days values are returned for patrons with past overdues when fine in days is set to 0 Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: oleonard(a)myacpl.org QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com When Members.pm checks to see whether a particular patron can check out, it checks for issuingrules.finedays "WHERE finedays IS NOT NULL." If the user has created a rule via Circulation and fines rules, finedays will always be 0 even if an empty value has been submitted. This causes Members::IsMemberBlocked to return a value when it should not. [09:57] <sekjal> IsMemberBlocked checks for finedays IS NOT NULL [09:58] <oleonard> ...and it's 0. [09:58] <sekjal> so, if you have finedays = 0 in any of your rules, it'll trigger [09:59] <sekjal> so, in that case, it'll just take the date difference between the returndate, and the current date [09:59] <sekjal> which means it would grow to 44 tomorrow [09:59] <sekjal> and so on [09:59] <sekjal> that's.... bad [09:59] <libsysguy> ^^ [09:59] <oleonard> And you can't set finedays to null when editing an issuing rule [10:00] <libsysguy> so we could change that check or null or 0 [10:00] <libsysguy> and it would fix your issue right [10:00] <sekjal> yes, that's the fix [10:00] <sekjal> one more line to the SQL [10:00] <sekjal> "AND finedays != 0" http://stats.workbuffer.org/irclog/koha/2011-10-21#i_795577 -- 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 11

[Bug 6604] New: without OPACXSLTResultsDisplay, some entries are "no items available" in opac-search
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '13

12 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6604 Bug #: 6604 Summary: without OPACXSLTResultsDisplay, some entries are "no items available" in opac-search Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: semarie-koha(a)latrappe.fr QAContact: koha-bugs(a)lists.koha-community.org Under some circumstances (seems to be zebra indexing), some entries in opac-search are marked with "No items available", whereas in opac-detail, the items are showed. This occurs only without OPACXSLTResultsDisplay preference (not using xsl for result display). The items not displayed seems to be correlated with zebra indexing state: only the latest items are "no items available". The incremental indexing not resolving this, but a full indexing yes (indexing with reset). In order to test: - unset the system preferences OPACXSLTResultsDisplay (not use xsl for result display) - in OPAC: search for your lasted created entries in search form (created after a full indexing) - check the availability displayed Additional question: zebra incremental indexing shouldn't process also items (not just notice) ? So I don't now if the problem is more a "display" error (information present in zebra, but not showed), or a zebra problem (the information isn't present so can't be showed) -- 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 9652] New: Call number column on list view displays commas when no callnumbers exist
by bugzilla-daemon＠bugs.koha-community.org 12 Aug '13

12 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9652 Bug ID: 9652 Summary: Call number column on list view displays commas when no callnumbers exist Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de Created attachment 15446 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15446&action=edit screenshot To reproduce: 1) Create a new list 2) Create a record with a few items, no callnumbers are entered 3) Add record to list 4) Show list in staff: /cgi-bin/koha/virtualshelves/shelves.pl?viewshelf=1&shelfoff=1 For 4 items without call numbers, the columns content is: , , , , -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 9899] New: Can't create new patrons with the database administrator account
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '13

11 Aug '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9899 Bug ID: 9899 Summary: Can't create new patrons with the database administrator account Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nunyo(a)masmedios.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 16781 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=16781&action=edit Error to create a new patron When I try to add a new patron, appear this error: "This patron does not exist." and the patron is not created. I have to select a Library(Set library), then I can create a new patron. In previous version this didn´t happening. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1