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

[Bug 5646] New: translated message names on sql level break messaging
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '12

01 Apr '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5646 Summary: translated message names on sql level break messaging Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 Component: I18N/L10N AssignedTo: frederic(a)tamil.fr ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 If you tranlate the message names in the installer sql files your messages will stop working, because the code relies on those have a specific value. - advance_notices.pl - C4/Members/Messaging.pm - C4/Form/MessagingPreferences.pm ... In C4/Members/Messaging.pm I found following lines: 47 my $preferences = C4::Members::Messaging::GetMessagingPreferences( { borrowernumber => $borrower->{'borrowernumber'}, 48 message_name => 'DUE' } ); 50 my $preferences = C4::Members::Messaging::GetMessagingPreferences( { categorycode => 'LIBRARY', 51 message_name => 'DUE' } ); We don't have DUE as a message name in the en file. Bug? Patch will undo my translation and other people's translations of those values. This means message names in borrower category and borrower account are not translatable at the moment. I think we need to change the templates to make them translatable? -- 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 16

[Bug 7090] New: Add "AllowItemsOnHandCheckout" syspref to allow issue to the patron regardless of hold status
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '12

28 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7090 Bug #: 7090 Summary: Add "AllowItemsOnHandCheckout" syspref to allow issue to the patron regardless of hold status Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Self checkout AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: srdjan(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org an item scanned at a self check station connected to Koha over SIP2 should issue regardless of whether there is a hold on the item. If the patron has the book in hand, they should be allowed to check it out; otherwise, what's to stop them from just taking it? This also prevents patrons from self-checking out holds that are waiting for THEM. Work To Be Done: - Add new system preference that asks whether self-check blocks checkout if the material in hand is on hold for someone else - Controls checkouts using Koha’s SCO - Controls checkouts over SIP2 How to test: - Set preference to allow checkouts of items in hand - Checkout a book with a hold on it for another via SIP. Checkout should proceed, hold should still exist - Checkout a book with a hold on it for another via SCO. Checkout should proceed, hold should still exist - Check out a book with a hold on it for yourself via SIP. Checkout should proceed, hold should be marked filled. - Check out a book with a hold on it for yourself via SCO. Checkout should proceed, hold should be marked filled. - Set preference to not allow checkouts of items in hand if hold is on them - Checkout a book with a hold on it for another via SIP. Checkout should not proceed, hold should still exist - Checkout a book with a hold on it for another via SCO. Checkout should not proceed, hold should still exist - Check out a book with a hold on it for yourself via SIP. Checkout should proceed, hold should be marked filled. - Check out a book with a hold on it for yourself via SCO. Checkout should proceed, hold should be marked filled. -- 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 21

[Bug 6199] New: Allow bulkmarcimport to blank duplicate barcodes rather than skipping items
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '12

28 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6199 Bug #: 6199 Summary: Allow bulkmarcimport to blank duplicate barcodes rather than skipping items Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org If bulkmarcimport.pl sees a duplicate barcode, it throws away the whole item. The forthcoming patch allows it to optionally blank out the barcode of any duplicates found. This is useful when migrating from software that may have created duplicates. -- 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 34

[Bug 5354] New: Partial duplication of a subscription
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '12

28 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5354 Summary: Partial duplication of a subscription Change sponsored?: Sponsored Product: Koha Version: rel_3_4 Platform: All URL: http://wiki.koha-community.org/wiki/Partial_duplicatin g_serials_RFC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Serials AssignedTo: henridamien(a)koha-fr.org ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Deadline: 2011-05-01 A syspref will be added that contains the list of fields to duplicate when duplicating a subscription. The library will be able to define that, for example, the internal note should not be duplicated -- 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 23

[Bug 6853] New: branch set wrong in fast add
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '12

27 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6853 Bug #: 6853 Summary: branch set wrong in fast add Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com We discovered that when you create a Fast Add/Temp record from Cataloging > New Record > Fast Add the Set Library defaults to Atchison (the first branchcode in the table), rather than the Set Library for that session. When you create a Fast Add/Temp record for Circulation, the Set Library defaults correctly. When you create any other kind of framework record from Cataloging, the Set Library defaults correctly. Looks like addbiblio.pl was modified to take the branch in from the circulation page (according to the new Fast Add at barcode scan dev we reimplemented from Harley), but that parameter is absent if you come at Fast Add from Circulation -> Fast Add or Cataloging. I think this can be fixed with a simple "default" value set on these lines: addbiblio.pl line 862 additems.pl line 592 -- 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 4903] New: OAI doesn't work out of the box - XSL path
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '12

23 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4903 Summary: OAI doesn't work out of the box - XSL path Change sponsored?: --- Product: Koha Version: rel_3_0 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Z39.50 / SRU / OpenSearch Servers AssignedTo: gmcharlt(a)gmail.com ReportedBy: tomascohen(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 In opac/oai.pl, the /koha-tmpl/intranet-tmpl/prog/en/xslt/ path is not available in a normal install: OAI harvesting fails and koha-opac-error.log says: "oai.pl: Could not create file parser context for file "/usr/share/koha_ffyh/intranet/cgi-bin/koha-tmpl/intranet-tmpl/prog/en/xslt/MARC21slim2OAIDC.xsl": No such file or directory" I'm not sure this xsl should be on intranet dir thou. To+ -- 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 14

[Bug 5158] New: Koha needs its own cookie, ice cream, and fudge flavors
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '12

22 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5158 Summary: Koha needs its own cookie, ice cream, and fudge flavors Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: P5 Component: Developer documentation AssignedTo: camins(a)numismatics.org ReportedBy: camins(a)numismatics.org QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 In order to encourage members of the Koha community to write documentation and test cases, Koha should have its own special cookie, ice cream, and fudge flavors. I propose that the cookie flavor be "curried coconut breakfast cookies" (with chocolate chips or dried fruit, depending on how you anticipate your day going). See http://www.cookiemadness.net/2009/05/curry-coconut-oatmeal-chocolate-chip-c… -- 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 4

[Bug 6140] New: Set a timeout to z3950 servers that could have network problems occasionally
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '12

22 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6140 Bug #: 6140 Summary: Set a timeout to z3950 servers that could have network problems occasionally Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Z39.50 / SRU / OpenSearch Servers AssignedTo: gmcharlt(a)gmail.com ReportedBy: juan.sieira(a)xercode.es QAContact: koha-bugs(a)lists.koha-community.org Created attachment 3832 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=3832 pro Set a timeout to z3950 servers that could have network problems occasionally Some of z3950 servers that our libraries must use, have network problems occasionally and when they are cataloguing and do a search over a z3950 server, if any of those Z selected have net problems, this search could have a delay of lot of time. If you dont want to execute updatedatabase.pl, simply execute this statement in you database ALTER TABLE `z3950servers` ADD `timeout` INT( 11 ) NOT NULL DEFAULT '0' AFTER `syntax`; -- 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 6831] New: Enhanced Workflow for adding analytical records
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '12

22 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6831 Bug #: 6831 Summary: Enhanced Workflow for adding analytical records Classification: Unclassified Change sponsored?: Sponsored Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: colin.campbell(a)ptfs-europe.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Facility to make the workflow easier for entering analytical records In cataloguing after searching for the parent record the new tool bar option 'add child' takes you into the addbiblio screen but with the Host Item Tag already populated with data derived from the parent record -- 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 26

[Bug 5028] New: catmaintain.pl doesn't exist
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '12

22 Mar '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5028 Summary: catmaintain.pl doesn't exist Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Staff Client AssignedTo: chris(a)bigballofwax.co.nz ReportedBy: oleonard(a)myacpl.org QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 A couple of the templates include links to catamaintain.pl: opac-detail.tmpl and detail.tmpl. From detail.tmpl:  <td><a href="/cgi-bin/koha/maint/catmaintain.pl?type=fixitemtype&bi=&item=">Fix Itemtype</a></td>  I'm assuming "type" never evaluates as true, because as far as I can tell this link never shows up. If it did it would point to a nonexistent file. There is no maint/catmaintain.pl. Is it safe to remove catmaintain.tmpl and the links to catmaintain.pl? -- 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 10