July 2012 - Koha-bugs - lists.koha-community.org

[Bug 8317] New: Cursor appears again not in Search box of catalogue
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '15

09 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8317 Priority: P5 - low Change sponsored?: --- Bug ID: 8317 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Cursor appears again not in Search box of catalogue Severity: enhancement Classification: Unclassified OS: All Reporter: programming(a)tyndale.cam.ac.uk Hardware: All Status: NEW Version: rel_3_8 Component: Circulation Product: Koha While two bugs (3189, 5125) in the past dealt with this issue and were resolved, now again the cursor is not in the right place. Thus when a patron in firefox enters the catalogue, it is not directly in the only search-box on the screen. (Tested in firefox and IE.) Entered for the Tyndale House library. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[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 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

[Bug 8364] New: Inconsistency in hold count
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '15

07 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8364 Priority: P5 - low Change sponsored?: --- Bug ID: 8364 CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Inconsistency in hold count Severity: normal Classification: Unclassified OS: All Reporter: paul.poulain(a)biblibre.com Hardware: All Status: NEW Version: master Component: Circulation Product: Koha If a Koha is set with ReservesControlBranch syspref set to ItemHomeLibrary item-level-itype=yes, a patron placing a "first available" hold won't be counted in the total number of reserves placed. The SQL is SELECT count(*) as count FROM reserves LEFT JOIN items USING (itemnumber) LEFT JOIN biblioitems ON (reserves.biblionumber=biblioitems.biblionumber) LEFT JOIN borrowers USING (borrowernumber) WHERE ... AND items.homebranch = ? => items is not defined, the hold is not counted -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 8409] New: purchase order saying 'Books'
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '15

07 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8409 Priority: P5 - low Change sponsored?: --- Bug ID: 8409 Assignee: koha-bugs(a)lists.koha-community.org Summary: purchase order saying 'Books' Severity: normal Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: rel_3_8 Component: Acquisitions Depends on: 6394 Product: Koha Created attachment 10755 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=10755&action=edit purchase order I'm not sure where this is coming from - but if you look at the page with the item info it says 'Books published by' ... not sure where Books is coming from but it should be clear if it's an item type or removed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3