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

[Bug 8088] New: Png-images of covers lost transparency
by bugzilla-daemon＠bugs.koha-community.org 03 Mar '13

03 Mar '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8088 Priority: P5 - low Change sponsored?: --- Bug ID: 8088 Assignee: gmcharlt(a)gmail.com Summary: Png-images of covers lost transparency Severity: enhancement Classification: Unclassified OS: All Reporter: dubyk(a)library.lviv.ua Hardware: All Status: NEW Version: unspecified Component: Tools Product: Koha Images of covers must preserve transparency of png-images. This is useful for example for the covers of CD/DVD disks. -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 9445] New: Use DataTables in local use system preferences editor
by bugzilla-daemon＠bugs.koha-community.org 02 Mar '13

02 Mar '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9445 Bug ID: 9445 Summary: Use DataTables in local use system preferences editor Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/admin/systempreferences.pl OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org The "old" system preferences editor, used now only for local use preferences, uses the old tablesorter plugin. It should use DataTables instead. -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 9449] New: Use Datatables on staff client cart
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '13

28 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9449 Bug ID: 9449 Summary: Use Datatables on staff client cart Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org The staff client cart uses the old tablesorter plugin. It should use the DataTables plugin. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 7146] New: Update timestamps when deleting a biblio
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '13

28 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7146 Bug #: 7146 Summary: Update timestamps when deleting a biblio Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: m.de.rooy(a)rijksmuseum.nl QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Currently, when you delete an item, the timestamp column in deleteditems is updated with current time. (This comes from an [unintentional] additional update statement in DelItem.) It makes deletion time visible. In the past, the marcxml was updated too at that moment, resulting in an updated timestamp in biblioitems too. The timestamp in biblio was not touched. If you delete a biblio however, the timestamps in deletedbiblio and deletedbiblioitems do not reflect time of deletion. They still show the time of last update before the record was deleted. This last update can be extracted from MARC field 005 too. This behavior is not consistent nor logical. I would suggest to add a statement in DelBiblio to force updating the timestamp in deletedbiblio(items) too. It makes the time of deletion visible in the record too. The time of deletion of a biblio can be very useful for e.g. synchronizing purposes. -- 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

[Bug 5791] New: Robust handling of deleted biblios/authorities
by bugzilla-daemon＠bugs.koha-community.org 28 Feb '13

28 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5791 Bug #: 5791 Summary: Robust handling of deleted biblios/authorities Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Architecture, internals, and plumbing AssignedTo: gmcharlt(a)gmail.com ReportedBy: tomascohen(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org When a biblio/authority is deleted, and for some reason one tries to access it via a (saved) URL (as when you reach the link via log viewer) koha presents the user a very ugly system error: Software error: Can't call method "field" on an undefined value at /home/tomas/Work/koha/devel/koha-community-3.2.x/authorities/detail.pl line 82. This is correctly handled for patrons, presenting a convenient "This patron does not exist." A similar approach should be implemented for biblios AND authorities. -- 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 27

[Bug 4882] New: Integrate debian/scripts/* upstream
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '13

27 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4882 Summary: Integrate debian/scripts/* upstream Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Packaging AssignedTo: lars(a)catalyst.net.nz ReportedBy: lars(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 The command line tools in debian/scripts are mostly not specific to Debian at all. It would be good to integrate them with the upstream code to make them available on all platforms. -- 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 4967] New: edit item not pulling call number
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '13

27 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4967 Summary: edit item not pulling call number Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal 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 Estimated Hours: 0.0 In this scenario a brief record was created at the time or ordering. the cataloger then goes in when the item is received and adds the additional details to the item record - but there is no way to auto fill the call number on editing (only on adding) and so the cataloger now has to go into the bib record, find the call number and type (or paste) it themselves. There should be a way to have the call number auto fill on edit item as well as on add item -- 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 5727] New: Use of uninitialized value in concatenation (.) or string
by bugzilla-daemon＠bugs.koha-community.org 27 Feb '13

27 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5727 Summary: Use of uninitialized value in concatenation (.) or string 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: frederic(a)tamil.fr QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 A lot of 'Use of uninitialized value in concatenation (.) or string' pollute log files and make them unreadable. -- 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 6

[Bug 7538] New: in transit items say available in the staff client
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '13

26 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7538 Bug #: 7538 Summary: in transit items say available in the staff client Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All URL: /cgi-bin/koha/catalogue/search.pl?q=mashups OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: koha.sekjal(a)gmail.com When in the staff client on the search results it lists the available items on the right of an item, but it's listing items that are in transit as available. They should either say in transit or unavailable or something to make it clear that they are not available. -- 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 8

[Bug 9395] New: Problem with callnumber and standard number search in OPAC and Staff Client
by bugzilla-daemon＠bugs.koha-community.org 26 Feb '13

26 Feb '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9395 Bug ID: 9395 Summary: Problem with callnumber and standard number search in OPAC and Staff Client Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: vfernandes(a)keep.pt This problem happens because there isn't a operator "phr" in the values of callnumber and standard number search. So many results aren't the corrects ones. For example if a search for a standard number "1" there isn't results even in OPAC and Staff Client. If the value is changed for "sn,phr" there is one result which is the biblionumber 1. When searching in OPAC for callnumbers the results are accurated because it's searching for "lcn,phr" in the advanced search. In staff client are only looking for "callnum" which uses the operator wrdl. -- You are receiving this mail because: You are watching all bug changes.

1 12