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

[Bug 7480] New: authorisedbyname filled twice in neworderempty.pl
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '15

11 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7480 Bug #: 7480 Summary: authorisedbyname filled twice in neworderempty.pl Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: ASSIGNED Severity: trivial Priority: P5 - low Component: Acquisitions AssignedTo: adrien.saurat(a)biblibre.com ReportedBy: adrien.saurat(a)biblibre.com QAContact: koha.sekjal(a)gmail.com In the "neworderempty.pl" file, as we are filling the template->param(*) info beginning on line 346, we have a value appearing twice: - in line 359, authorisedbyname => $basket->{'authorisedbyname'}, - in line 365, authorisedbyname => $borrower->{'firstname'} . " " . $borrower->{'surname'}, Moreover, this line 365 generates log lines like the following: [Tue Jan 31 14:39:41 2012] neworderempty.pl: Use of uninitialized value in concatenation (.) or string at /home/asaurat/workspace/versions/community/acqui/neworderempty.pl line 346. [Tue Jan 31 14:39:41 2012] neworderempty.pl: Use of uninitialized value in concatenation (.) or string at /home/asaurat/workspace/versions/community/acqui/neworderempty.pl line 346. These log entries are easy to correct if we keep the $borrower version, but that's my question: which line should we keep? Or maybe both values can be ok but one has priority over the other one? This authorisedbyname variable is linked to a "Managed by:" label in the template. -- 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 16

[Bug 8050] New: debian/build-git-snapshot should warn user if it fails
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '15

11 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8050 Priority: P5 - low Change sponsored?: --- Bug ID: 8050 Assignee: robin(a)catalyst.net.nz Summary: debian/build-git-snapshot should warn user if it fails Severity: normal Classification: Unclassified OS: All Reporter: jcamins(a)cpbibliography.com Hardware: All Status: NEW Version: master Component: Packaging Product: Koha The script debian/build-git-snapshot returns success even if the package building fails. Automating package build requires some sort of feedback if the package build fails, preferably a non-success return value for the debian/build-git-snapshot script. -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 5458] New: length of items.ccode disagrees with authorised_values.authorised_value
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '15

09 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5458 Summary: length of items.ccode disagrees with authorised_values.authorised_value Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Database AssignedTo: gmcharlt(a)gmail.com ReportedBy: pete.huerter(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Koha allows you to define an authorised value having length 80, but then you can't use it. Here is why: The SQL field items.ccode is a varchar(10). The SQL field authorised_values.authorised_value is a varchar(80). Therefore the authorised value is truncated to length 10 in items.ccode and the mapping from authorised value to description string fails in Koha. Not sure how this change will "bubble up" in Koha but the change to the table schema seems straightforward: increase the size of items.ccode to varchar(80). This is preferable to shortening authorised_values.authorised_value since we have many category codes (CCODE) that are longer than length 10. -- 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 3

[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 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 7178] New: Improve order item creation
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '15

07 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7178 Bug #: 7178 Summary: Improve order item creation Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: julian.maurice(a)biblibre.com QAContact: ian.walls(a)bywatersolutions.com Created attachment 6233 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=6233 neworderempty.pl This development change the behaviour of item creation while ordering or receiving. Only one item block is displayed at a time, and the others are "minimized" in a table row. Moreover, adding a new item no longer clone the html block, but it call PrepareItemRecordDisplay via ajax, so the fields ids are different and cataloguing plugins can be used on these fields. Only items shown in items list will be created, so it requires to click the '+' button at least one time, even for creating a single item. See screenshot attached to see what it looks like. BibLibre infos: Repository: git://git.biblibre.com/koha_biblibre.git Branch: stetienne/ft/MT6523 -- 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 77

[Bug 6820] New: hide receive option if there is nothing to receive
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '15

06 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6820 Bug #: 6820 Summary: hide receive option if there is nothing to receive Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Created attachment 5227 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=5227 vendor search Maybe we should hide the receive shipment link on the vendor search if there is nothing to receive - or rename it to say 'received shipments' since that's what you see when you go there. -- 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 7391] New: Return to cart after adding items to a list
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '15

06 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7391 Bug #: 7391 Summary: Return to cart after adding items to a list Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: oleonard(a)myacpl.org QAContact: ian.walls(a)bywatersolutions.com If you select items in your cart and choose to add them to a list, upon completion of the transaction the pop-up window, which was originally opened for the cart, is closed. Instead you should be returned to the Cart view. -- 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 11