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

[Bug 9482] New: set library redirects wrong on fines
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '15

08 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9482 Bug ID: 9482 Summary: set library redirects wrong on fines Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I was on the Pay Fines page: cgi-bin/koha/members/pay.pl and went to change my library by clicking 'set library' in the top right. When I reset my library it redirected me back to cgi-bin/koha/members/pay.pl but it no longer had the patron's info on the screen. It should just redirect to circulation main or to the pay fines on the patron's record (where I was). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 9500] New: GetNormalizedISBN only ever checks the first populated ISBN field
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '15

08 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9500 Bug ID: 9500 Summary: GetNormalizedISBN only ever checks the first populated ISBN field Classification: Unclassified 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: kyle(a)bywatersolutions.com If you take a look at C4::Koha::GetNormalizedISBN you will see code like this: if ($marcflavour eq 'UNIMARC') { @fields = $record->field('010'); foreach my $field (@fields) { my $isbn = $field->subfield('a'); if ($isbn) { return _isbn_cleanup($isbn); } else { return undef; } } } If I read this correctly, if we have say two ISBNs in a record, with the first being invalid and the second being valid, GetNormalizedISBN will still return undef because it never bothers to check the second isbn! -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 5998] New: Error "failed to submit form parsererror" and empty staged
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '15

08 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5998 Bug #: 5998 Summary: Error "failed to submit form parsererror" and empty staged Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: MARC Bibliographic record staging/import AssignedTo: gmcharlt(a)gmail.com ReportedBy: dubyk(a)library.lviv.ua QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Created attachment 3513 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=3513 marcxml, that gives error Trying stage 1 MARC record with many items. (about record: Unimarc, items in 995, Cyrillic text) File loaded ok. Choose Unimarc and push "Stage for import". After this jumps out the window with an error "failed to submit form parsererror". (Job progress: 0% and stopped) Look on "Staged MARC management": File_name Status # Bibs # Items suchasna.xml staged 0 0 (must be 1 bibs and many items) Also looked at the logs /var/log/koha - nothing that could describe the problem. Next I trying import from command line: /usr/share/koha/bin/migration_tools/bulkmarcimport.pl -b -file=/home/dubyk/Dropbox/Koha/suchasna.xml -c=UNIMARC -m=MARCXML ...all ok (imported 1 record and 198 items) -- 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 5

[Bug 7550] New: Self checkout should limit display of patron image to logged-in patron
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '15

08 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7550 Bug #: 7550 Summary: Self checkout should limit display of patron image to logged-in patron Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All URL: /cgi-bin/koha/sco/sco-patron-image.pl?cardnumber=XXXX OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: Self checkout AssignedTo: koha.sekjal(a)gmail.com ReportedBy: oleonard(a)myacpl.org QAContact: koha.sekjal(a)gmail.com The patron image display in the self-checkout takes a GET parameter from the image source, so if someone copied the image location and substituted the barcode string they could browse through all patron images: <img alt="" src="/cgi-bin/koha/sco/sco-patron-image.pl?cardnumber=XXXX"> It would offer patrons better privacy to limit that request based on the currently-logged-in user. -- 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 2

[Bug 8059] New: local use recorded on lost items
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '15

07 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8059 Priority: P5 - low Change sponsored?: --- Bug ID: 8059 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: local use recorded on lost items Severity: minor Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Circulation Product: Koha Created attachment 9457 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=9457&action=edit checking in lost item I have the sys pref set to record local use when I check in an item that is not checked out. Now I don't know if this is a bug, but probably should be discussed. As you see in my attachment when I check in an item that was lost it records a local use and marks the item as 'found.' My question/comment is should this track a local use? There wasn't any usage here, just the returning of an item that was thought lost. It's not a big deal so I've marked this as minor, but thought I should mention that this is happening and maybe effecting stats. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 10188] New: Top Most-circulated items doesn't count current loans
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '15

07 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10188 Bug ID: 10188 Summary: Top Most-circulated items doesn't count current loans Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com Right now, the 'calculate' function only counts circulation from the old_issues table, and not issues. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 8248] New: Invalid characters entered in bib record cause 500 error
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '15

07 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8248 Priority: P5 - low Change sponsored?: --- Bug ID: 8248 Assignee: gmcharlt(a)gmail.com Summary: Invalid characters entered in bib record cause 500 error Severity: enhancement Classification: Unclassified OS: All Reporter: steven_jeffery(a)fmi.com Hardware: All Status: NEW Version: rel_3_8 Component: Cataloging Product: Koha Created attachment 10282 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10282&action=edit text to reproduce error Entering text with invalid characters causes Koha to return a 500 Internal Server Error in when submit is pressed. The bib record is NOT created. I am attaching a document here with text (see the English abstract) that causes this to happen. This occurs in both 3.6 and 3.8 in IE8. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 7001] New: User Configurable Slips
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '15

07 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7001 Bug #: 7001 Summary: User Configurable Slips Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: srdjan(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Work To Be Done: * Hold notification slips and Checkout receipts brought under the Notices editor * Associate Notices/Slips with branches, and include a fallback to 'default' notice type, so there can be both a standard notice layout, and branch- specific ones - Provide pull down to choose branch and then have notices under each branch like with circ/fine rules - Use IndependentBranches to prevent edits to notices of other branches * Parsing of patron extended attributes into notices * Allow for notices/slips to be created in and printed with HTML - Right now emails are sent only in plain text - This can either be an automatic process, the script identifies when the notice is in HTML, or it can be a choice on notice creation (HTML or Plain Text) * Ability to include/link/otherwise associate a CSS file with HTML notices/slips - New system preference NoticeCSS - New system preference SlipCSS To Test: * Test on a system with at least two branches * Create a CSS file for the NoticeCSS * Create a CSS file for the SlipCSS * Create a patron at Branch A (Patron A) - Choose to receive at least two enhanced messages (one should be a hold filled) - Enter at least one extended patron attribute * Create patron at Branch B (Patron B) - Choose to receive at least two enhanced messages (one should be a hold filled) - Enter at least one extended patron attribute * Create at least two notices for each branch (one should be hold filled) - Include branch specific fields as well as information on items and the borrower - Make sure there are some fields that are different in each notice - Make sure one from each branch has HTML code in it * Create at least two slips for each branch - One hold slip - Include branch specific fields as well as information on items and the borrower (include at least one extended patron attribute) - One branch should be in HTML and the other plain text - One checkout receipt - Include branch specific fields as well as information on items and the borrower (include at least one extended patron attribute) - One branch should be in HTML and the other plain text * Check out one item to Patron A at Branch A - Print a slip for that check out - Confirm that data is parsed correctly - Print a quick slip for that check out - Confirm that data is parsed correctly - Print a page for that check out - Confirm that data is parsed correctly * Check out another item to Patron A at Branch A - Print a slip for that check out - Confirm that data is parsed correctly - Print a quick slip for that check out - Confirm that data is parsed correctly - Print a page for that check out - Confirm that data is parsed correctly * Check out one item to Patron B at Branch B - Print a slip for that check out - Confirm that data is parsed correctly - Print a quick slip for that check out - Confirm that data is parsed correctly - Print a page for that check out - Confirm that data is parsed correctly * Check out another item to Patron B at Branch B - Print a slip for that check out - Confirm that data is parsed correctly - Print a quick slip for that check out - Confirm that data is parsed correctly - Print a page for that check out - Confirm that data is parsed correctly * Place a hold for Patron A for pick up at Branch A * Place a hold for Patron B for pick up at Branch B * Check in an item on hold from Branch A - Print the hold slip - Confirm that the data is parsed correctly * Check in an item on hold from Branch B - Print the hold slip - Confirm that the data is parsed correctly * Check both patrons’ email to be sure that the hold filled email parsed properly * Trigger the sending of at least one other notice and confirm that that email is parsed properly as well -- 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 135

[Bug 8259] New: No longer possible to have multiple serial notices
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '15

07 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8259 Priority: P2 Change sponsored?: --- Bug ID: 8259 Keywords: regression Assignee: koha-bugs(a)lists.koha-community.org Blocks: 7001 Summary: No longer possible to have multiple serial notices Severity: major Classification: Unclassified OS: All Reporter: katrin.fischer(a)bsz-bw.de Hardware: All Status: NEW Version: master Component: Notices Product: Koha Late orders in serial claims provides a pull down below the form where you can select which notice template should be used for the serial claim. The pull down used to list all notices that have the right module for serial claiming. This no longer works. To make it worse, I can't create a second notice for the module with a different code and the same library. Every time I save the notice, it gets added to 'all libaries' instead. Editing and changing the library does also not work. Now the pull down should list all notice templates for the user's library + all libraries. This is a regression :( -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 8295] New: patron duplicate message not checking required fields
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '15

07 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8295 Priority: P5 - low Change sponsored?: --- Bug ID: 8295 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: patron duplicate message not checking required fields Severity: major Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Patrons Product: Koha I have firstname and surname as required fields when creating patron records. I also have 22 patron records where one or both of those fields are empty. If I create a new record and leave the firstname and surname fields empty I get a message that this could be a duplicate and either I can edit the duplicate or save the new record. If I click save it saves it without first or surname. If I click edit the duplicate it brings up a record which appears to be the first one in the database with neither a first nor surname. Shouldn't the first check on saving a new record be a look at the two required fields and an error message if they are empty? Instead, it's just matching on a record where these are empty and allowing the record to be created. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1