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

[Bug 11581] New: HTTP 404s generated badly in some cases
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '14

25 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11581 Bug ID: 11581 Summary: HTTP 404s generated badly in some cases Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org There are several scripts that do the following when they want to signal that a resource (usually a MARC record) does not exist: print $query->redirect("/cgi-bin/koha/errors/404.pl"); This is not great, because what actually happens is that an HTTP 302 redirect is issued, followed by the 404. This wastes a bit of time for the user agent, and might be problematic if you let search engines crawl your OPAC. Better would be doing print $cgi->header( -status => '404 record not found'); or if a more specific message should be displayed, constructing it and calling output_with_http_headers $query, $cookie, $error_template->output, 'html', '404 Not Found'; The affected scripts are: catalogue/showmarc.pl opac/opac-ISBDdetail.pl opac/opac-MARCdetail.pl opac/opac-authoritiesdetail.pl opac/opac-detail.pl opac/opac-export.pl opac/opac-showmarc.pl opac/opac-topissues.pl opac/tracklinks.pl -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 11473] New: View log template has malformed conditionals, and logging info incorrect/inconsistent/unexpected
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '14

25 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11473 Bug ID: 11473 Summary: View log template has malformed conditionals, and logging info incorrect/inconsistent/unexpected Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Transaction logs Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org 1) Malformed conditionals Currently, the majority of "viewlog.tt" is ignored, because we haven't formed the conditionals correctly. (e.g. Using 'module' when we should be using 'loopro.module' [or 'loopro.MODULENAME' like 'loopro.CIRCULATION'], 'info' instead of 'loopro.info', etc.) This means that we always get the raw "loopro.object", which is either a borrowernumber, biblionumber, itemnumber, subscriptionid, or authid, with absolutely no qualifier at all. *SOLUTION* Alas, the solution requires a few systematic changes. Detecting an object as a 'borrowernumber' is easy, since MEMBERS, CIRCULATION, and FINES always use it as its object. Same goes for 'subscriptionid' for SERIALS and 'authid' for AUTHORITIES. For these cases, we just need to fix the variables called in the conditions. However, unfortunately, CATALOGUING sometimes uses biblionumber and sometimes uses itemnumber as its object. This causes the following problem... 2) Conditions in viewlog.pl and viewlog.tt do not correctly differentiate items and biblios. There are conditions that check to see if the 'info' column says 'item'. However, this has erratic results, because 'item' is only logged for item adds and deletions - not modifications. (Authorities also only track 'authority' for additions and deletions - not modifications.) 'biblio' is only tracked for biblio additions. Deletions have no info, while modifications include the record content. In viewlog.tt, logs without an 'info' of 'item' will be labelled and linked as 'biblio'. That means that all item modifications will be treated as biblios and not items. *SOLUTION* Change logaction to prepend the info column with "biblio" for all biblio transactions and "item" for all item transactions. Then, check for the applicable substring in viewlog.pl and viewlog.tt to determine how to link and label the number. For legacy data, have a third option that doesn't label/link the object. Just have the raw number (as we currently do). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 11476] Opac self registration title pull down offers 2 empty options
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '14

25 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11476 Fridolin SOMERS <fridolyn.somers(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to Master |Pushed to Stable CC| |fridolyn.somers(a)biblibre.co | |m --- Comment #5 from Fridolin SOMERS <fridolyn.somers(a)biblibre.com> --- Patch pushed to 3.14.x, will be in 3.14.5 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11018] New: Add order from a reverted file
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '14

25 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11018 Bug ID: 11018 Summary: Add order from a reverted file Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org If a batch is reverted, it is not possible to create an order from this file. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 11985] New: Auto insert MARC 005 (Date and Time of Latest Transaction) detail when saving new catalog record
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '14

24 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11985 Bug ID: 11985 Summary: Auto insert MARC 005 (Date and Time of Latest Transaction) detail when saving new catalog record Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: imingchan(a)yahoo.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Automatically insert detail for MARC 005 (Date and Time of Latest Transaction) when saving a new catalog record. Currently, a pop-up message may appears when MARC 005 is left blank as you save a new catalog record. Clear this message, and it automatic insert necessary detail into this field. This should be improved, so user don't have to click into MARC 005 (to insert detail) field as part of cataloguing activity. It should automatically get inserted when the record is saved! -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 11987] New: Add date ranges to patron and cataloguing stat wizards
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '14

24 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11987 Bug ID: 11987 Summary: Add date ranges to patron and cataloguing stat wizards Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org It would be nice if the patron and cataloguing statistics wizards had more date range options. For instance, patrons could add the "dateenrolled" and "dateexpiry" options. Likewise, cataloguing could have a "datecreated" filter added. At the moment, the stat wizard code looks a bit convoluted and fragile to me. I took a look at adding "dateenrolled" to a 3.8 instance, but the result was being picked up by the "sort" filters instead, so I'm reporting the enhancement idea and putting my work on ice for now. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9210] New: Automatic carriage return are missing in print letters generated for holds
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '14

24 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9210 Bug ID: 9210 Summary: Automatic carriage return are missing in print letters generated for holds Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: sophie.meynieux(a)biblibre.com When you generate print letters (pdf) for holds with gather_print_notices.pl, lines that are too long are truncated and not automatically wrapped to another line. This patch modify styles in the template used for generation of pdf files. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 11505] New: Untranslatable table headers in Label batch manager
by bugzilla-daemon＠bugs.koha-community.org 24 Mar '14

24 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11505 Bug ID: 11505 Summary: Untranslatable table headers in Label batch manager Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)pttk.fi QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr In Label Batch manager, after adding the items to the batch, you're presented with a table showing information about the items. The table column headers are in English, and cannot be translated. The texts are hard-coded in $display_columns in labels/label-edit-batch.pl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 5993] New: tags not searchable
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '14

23 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5993 Bug #: 5993 Summary: tags not searchable Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com The only way to search tags is to click on the term on the bib record or in the tag cloud. tags are keywords and should be searched in the keyword search. -- 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 11983] New: code to select patrons to purge needs to be centralized
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '14

22 Mar '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11983 Bug ID: 11983 Summary: code to select patrons to purge needs to be centralized Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org The patch for bug 11352 introduces a routine in tools/cleanborrowers.pl called skip_borrowers_with_nonzero_balance. This filters out patrons who have active fine balances so that the patron purge does not inadvertently delete/trash them. This logic should be put in a central routine, e.g., perhaps in GetBorrowersToExpunge(). At present, misc/cronjobs/delete_patrons.pl also has logic to not purge patrons with fine balances, but it implements it differently. Having two different implementations of the same functionality is not great, but I (in my role as 3.16 RM) allowed it because of the potential for data loss that the patch for bug 11352 fixed. However, this situation should not be allowed to persist. -- You are receiving this mail because: You are watching all bug changes.

1 1