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

[Bug 5069] New: Authority clean-up scripts
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '15

14 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5069 Summary: Authority clean-up scripts Change sponsored?: --- Product: Koha Version: rel_3_0 Platform: PC OS/Version: Linux Status: NEW Severity: enhancement Priority: P5 Component: Command-line Utilities AssignedTo: chris(a)bigballofwax.co.nz ReportedBy: ccurry(a)amphilsoc.org QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 When we originally migrated our data, we loaded ~ 40,000 auth records corresponding to ~ 200,000 bib records. I ran the link_bibs_to_authorities.pl script, but it appears that we have some bad data in our authorities (or our bibs?), because some did not link correctly. I wonder if there's a way to utilize the process that creates authority records from the appropriate fields during the record creation process to generate authority records from unlinked headings of existing bibs. In addition, we'd like to be able to delete the authorities we imported that have no bibs linked. I asked this question yesterday on IRC#koha and Chris Cormack mentioned that a script could be written for both of these and it "might be a good koha code learning exercise for someone at catalyst." He asked me to submit this enhancement and assign it to him. One thing I should add is this: If there is not already a duplicate auth record checking functionality built into the process which auto-generates authorities during the record creation process, it seems that this would be important for a command line script, since we wouldn't want to create a bunch of identical authorities (which would then not function correctly as authority records). Perhaps the link_bibs_to_authorities.pl script contains the necessary dup finding code? We're running 3.00.05.001 (on Debian Lenny), so it would be useful for us if the scripts were compatible with 3.0 & 3.2. If necessary, we'd be willing to upgrade to 3.00.06 (we're hoping to do so soon, anyway, unless 3.2 becomes stable before we get around to it :) ). -- 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 2

[Bug 6973] New: Allow reply-to on cart emails to go to the sender of the cart.
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '15

13 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6973 Bug #: 6973 Summary: Allow reply-to on cart emails to go to the sender of the cart. Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org When you send a cart and the person attempts to reply to it, the email goes to the library admin address. This will add a syspref that allows a Reply-To header to be set that will be set to the user of the cart, if they're logged in and have an email address set. Which email address is used will be determined by the AutoEmailPrimaryAddress preference. -- 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 25

[Bug 5377] New: Database fields too small for multiple ISBN and ISSN
by bugzilla-daemon＠bugs.koha-community.org 13 Apr '15

13 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5377 Summary: Database fields too small for multiple ISBN and ISSN Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Database AssignedTo: gmcharlt(a)gmail.com ReportedBy: fridolyn.somers(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Hie, I noticed a wrong behavior in "koha to MARC mapping". Using a mapping for ISBN and ISSN fields, I noticed that fields "isbn" and "issn" where truncated in "biblioitems" table when using multiple values. With multiple values, ISBN and ISSN are separated by a " | ". In fact, "isbn" field is a VARCHAR(30) and "issn" field is a VARCHAR(9). This is far to small. I propose a VARCHAR(255). Regards, -- 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 38

[Bug 7561] New: cannot fast catalog with fast cataloging permissions
by bugzilla-daemon＠bugs.koha-community.org 11 Apr '15

11 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7561 Bug #: 7561 Summary: cannot fast catalog with fast cataloging permissions Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 - low Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha.sekjal(a)gmail.com If you have a user with fast cataloging permissions and no other cataloging permissions the user can catalog the bib record using fast cataloging, but when they click save they are not brought to the item record anymore they're brought to the normal view. Fast cataloging is both bib and item record for a fast record so it can be checked out and this is how it was in 3.6 - but appears to have changed in master and a later 3.6.x release. -- 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 25

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