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

[Bug 8261] New: Cannot search system preferences from Local Use tab
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '12

06 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8261 Priority: P5 - low Change sponsored?: --- Bug ID: 8261 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Cannot search system preferences from Local Use tab Severity: blocker Classification: Unclassified OS: All Reporter: dcook(a)prosentient.com.au Hardware: All Status: NEW Version: master Component: System Administration Product: Koha Searching the system preferences from the Local Use tab generates a Software error as follows: "Template process failed: file error - .../intranet/htdocs/intranet-tmpl/prog/en/modules/admin/preferences/all.pref: not found at .../lib/C4/Templates.pm line 127." I notice that early versions (such as 3.2) produce search results under an "all preferences" heading. However, I don't see an all.pref file in 3.2 either. The "all preferences" result list seems archaic though, since searching "OPAC" or "MARC" from any other tab provides a much more well formatted list where results are grouped by tab and subheading. Any thoughts on this one? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 7613] New: OCLC Connexion Gateway
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '12

06 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7613 Bug #: 7613 Summary: OCLC Connexion Gateway Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: srdjan(a)catalyst.net.nz QAContact: koha.sekjal(a)gmail.com Work to be done: * C4::ImportBatch: create sub GetImportBatchByFilename($filename) which will get the last import_batches record with the filename * Create svc/import_bib - POST request structure: param1: val param2: val <?xml version="1.0" encoding="UTF-8"?> <record ... </record> - call C4::ImportBatch::GetImportBatchByFilename("webservice"); if in 'stage' status use it, otherwise create new one AddImportBatch() using POST param - call C4::ImportBatch::AddBiblioToBatch() and AddItemsToImportBiblio() - if import mode = 'direct' call C4::ImportBatch::BatchCommitBibRecords() * misc/cronjobs/import_webservice_batch.pl: - input params: framework (default 'default') - call C4::ImportBatch::GetImportBatchByFilename("webservice"); if in 'stage' status - call C4::ImportBatch::BatchCommitBibRecords() * create OCLC requests listening daemon connexion_import.pl - base on HTTP::Server or similar - command line params: config file - config values as per spec - first get the auth cooki from auth url, then make request to import url How to test: * using some tool (wget or curl) make a request with some MARC xml to OCLC daemon * check koha import batches that a webservice batch is created with params as in the config file * run cron job from the command line and check the batch status -- 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 50

[Bug 6903] New: Quantity for odering from suggestion should not default to 0
by bugzilla-daemon＠bugs.koha-community.org 06 Sep '12

06 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6903 Bug #: 6903 Summary: Quantity for odering from suggestion should not default to 0 Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: katrin.fischer(a)bsz-bw.de QAContact: koha-bugs(a)lists.koha-community.org When ordering from suggestions is the only ordering option where quantity defaults to 0 instead of ''. So if you forget to change that it will not complain and you will not create an order when saving. -- 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 8293] New: Software error when clicking on first or last result of each page on OPAC
by bugzilla-daemon＠bugs.koha-community.org 05 Sep '12

05 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8293 Priority: P5 - low Change sponsored?: --- Bug ID: 8293 Assignee: oleonard(a)myacpl.org Summary: Software error when clicking on first or last result of each page on OPAC Severity: critical Classification: Unclassified OS: All Reporter: koha(a)univ-lyon3.fr Hardware: All Status: NEW Version: rel_3_8 Component: OPAC Product: Koha When you click on the last result of first page or first/last result of following pages of results you get this : Unsupported UNIMARC character encoding [] for XML output for UNIMARC; 100$a -> at /usr/share/perl5/MARC/File/XML.pm line 505. This happens because of the following patch : "bug_6488 followup - fixes issue with bibs with no items and serials being suppressed". + if ($items_count > 0) { next if $is_opac && $hideatopac_count >= $items_count; next if $hidelostitems && $itemlost_count >= $items_count; - + } When commented the 2 conditions lines that have been added, the records display correctly again. Strangely, this patch seems not to have been validated (cf comments thread in Bug 6488). But may be, I missed something... -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 8012] New: defaultSortOrder and OPACdefaultSortOrder are set to "ascending" on install
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '12

03 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8012 Priority: P5 - low Change sponsored?: --- Bug ID: 8012 Assignee: gmcharlt(a)gmail.com Summary: defaultSortOrder and OPACdefaultSortOrder are set to "ascending" on install QA Contact: koha.sekjal(a)gmail.com Severity: trivial Classification: Unclassified OS: All Reporter: ruth(a)bywatersolutions.com Hardware: All Status: NEW Version: rel_3_8 Component: Searching Product: Koha ...which, given that defaultSortField and OPACdefaultSortField are both set to "relevance" out of the box, is just plain silly--the results are sorted with *lowest* relevance first! Trivial to fix, but can save new installs mucho frustration... -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 7922] New: Fixing typos and improving translations in German sample data
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '12

03 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7922 Priority: P5 - low Change sponsored?: --- Bug ID: 7922 CC: gmcharlt(a)gmail.com Assignee: katrin.fischer(a)bsz-bw.de Summary: Fixing typos and improving translations in German sample data QA Contact: koha.sekjal(a)gmail.com Severity: normal Classification: Unclassified OS: All Reporter: katrin.fischer(a)bsz-bw.de Hardware: All Status: ASSIGNED Version: master Component: Installation and upgrade (web-based installer) Product: Koha -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 7562] New: KohaDates plugin not found for 3.6.3 running off packages
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '12

03 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7562 Bug #: 7562 Summary: KohaDates plugin not found for 3.6.3 running off packages Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging AssignedTo: robin(a)catalyst.net.nz ReportedBy: magnus(a)enger.priv.no QAContact: koha.sekjal(a)gmail.com I have built my own packages of 3.6.3 with build-git-snapshot, and now I'm getting this: "Template process failed: plugin error - KohaDates: plugin not found at /usr/share/koha/lib/C4/Templates.pm line 126." on /cgi-bin/koha/acqui/ordered.pl?fund=1&fund_code=STOR_VOKS (Click on one of the amounts in the table on the front page of the Acquisitions module.) I'm guessing the Koha namespace/directory is not getting created somewhere along the line... -- 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 6000] New: Performance enhancements for C4::Context and C4::Languages
by bugzilla-daemon＠bugs.koha-community.org 03 Sep '12

03 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6000 Bug #: 6000 Summary: Performance enhancements for C4::Context and C4::Languages Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org Blocks: 5999 -- 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 20

[Bug 7430] New: ModZebra should not be in C4::Biblio
by bugzilla-daemon＠bugs.koha-community.org 02 Sep '12

02 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7430 Bug #: 7430 Summary: ModZebra should not be in C4::Biblio Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing AssignedTo: jcamins(a)cpbibliography.com ReportedBy: jcamins(a)cpbibliography.com QAContact: ian.walls(a)bywatersolutions.com ModZebra is currently in C4::Biblio. This is not a logical place for it, since ModZebra is also used for modifying authorities. The logical place to have that functionality is in Koha::Search::Engine to help prepare us for the solr integration. I propose breaking the ModZebra code into separate parts for NoZebra and Zebra (in Koha::Search::Engine::NoZebra and Koha::Search::Engine::Zebra, respectively), and have Koha::Search::Engine::add_to_index_queue dispatch to the appropriate engine. C4::Biblio can remain as a wrapper around Koha::Search::Engine::add_to_index_queue for legacy scripts. -- 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 31

[Bug 7513] New: MARC Import Hangs
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '12

01 Sep '12

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7513 Bug #: 7513 Summary: MARC Import Hangs Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_8 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: henridamien.laurent(a)biblibre.com QAContact: koha.sekjal(a)gmail.com When commiting biblio file from file 7510 (UNIMARC), the commit biblio file hangs because of a Wide Character. In fact, using the commit_biblios_file.pl in command line, the script dies. This patch is using C4::Context->preference('marcflavour') in as_xml It should be tested on a MARC21 installation in order to validate that patch. -- 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 10