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

[Bug 7673] New: New patron permissions
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '15

16 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7673 Priority: P5 - low Change sponsored?: --- Bug ID: 7673 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: New patron permissions QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: stephane.delaye(a)biblibre.com Hardware: All Status: NEW Version: rel_3_8 Component: Patrons Product: Koha refine permissions again : # limited_item_edition Limit item modification to barcode, status and note (please note that edit_item is still required) # manage_shelves Allows to manage shelves # delete_all_items Delete all items # merge_from_shelves Allows to merge records from shelves # items_limited_batchmod Limit batch item modification to item status (please note that items_batchmod is still required) -- You are receiving this mail because: You are watching all bug changes.

1 156

[Bug 6950] New: Cannot sort the results of a tag search
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '15

16 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6950 Bug #: 6950 Summary: Cannot sort the results of a tag search Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: oleonard(a)myacpl.org QAContact: koha-bugs(a)lists.koha-community.org If you click a link from the Tag Cloud, the results page offers the usual select menu to resort your results. However, doing so resubmits the search as a standard keyword search. I'm assuming there isn't even a way to pass a different sort to the tag search, so it might be necessary to simply hide the resort option when displaying the results of a tag 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 19

[Bug 10338] New: Search history can cause "Out of memory" errors
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '15

16 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10338 Bug ID: 10338 Summary: Search history can cause "Out of memory" errors Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P3 Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jweaver(a)bywatersolutions.com After a certain number of searches, thawing the search history cookie (line ~296 of C4/Auth.pm) can cause an "Out of memory" error, causing all OPAC scripts to stop working. This seems to occur after a certain number of searches, but does not seem to be related to corruption or truncation due to the max cookie size. The current workaround is to disable OPAC search history (the EnableOpacSearchHistory syspref). -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 10340] New: deleted orders should not be taken into account for Item count calculation in booksellers.pl
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '15

16 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10340 Bug ID: 10340 Summary: deleted orders should not be taken into account for Item count calculation in booksellers.pl Classification: Unclassified 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: mathieu.saby(a)univ-rennes2.fr in booksellers.pl, the "Item count" column contains all items, even if the order was deleted. I think it is a wrong behavior. M. Saby -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 7890] New: highlight required in yellow
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '15

16 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7890 Priority: P5 - low Change sponsored?: --- Bug ID: 7890 Assignee: gmcharlt(a)gmail.com Summary: highlight required in yellow QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Cataloging Product: Koha When you're cataloging if you forget to fill in some fields an error pops up and then the fields you forgot to fill in are highlighted in yellow - why not highlight them in yellow to start with so that they stand out better? -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 7015] New: Fixup Template Code to Accommodate More Variety of Label Styles
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '15

15 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7015 Bug #: 7015 Summary: Fixup Template Code to Accommodate More Variety of Label Styles Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Label printing AssignedTo: cnighswonger(a)foundations.edu ReportedBy: cnighswonger(a)foundations.edu QAContact: koha-bugs(a)lists.koha-community.org Modify template code to allow the use of a greater variety of label styles (such as Gaylord LSL04, and friends). A cursory review reveals this basic spec: 1. Modify the Template view code to allow addition of columns of multiple dimensions. 2. Modify the Template control code to translate template specs into and out of xml format. 3. Modify the Template model to reduce the existing number of fields to the minimum needed to store the new template format. 4. Modify any other control code which requires access to template specs. -- 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 9988] New: Unneeded timeouts when saving authorities (Can we merge smarter?)
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '15

15 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9988 Bug ID: 9988 Summary: Unneeded timeouts when saving authorities (Can we merge smarter?) Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl When saving an authority used in many biblios, Koha may have a timeout due to updating all those bib records. But in case I just update e.g. a 551 tag for the auth record, there is no need at all to update all those bib records. We should have a smarter merge function in C4/AuthoritiesMarc.pm. Note that you could use the pref to move updating all biblios to a cron job. Wouldn't it be nicer if we could do something in between? If we really need to update a handful of records, do it rightaway. If we really (!!) need to update 2000 records (in my example Koha is updating 2000 records for nothing), we could perhaps leave that to a cron job. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 10169] New: Software error if one of multiple titles selected for hold in the OPAC has no items
by bugzilla-daemon＠bugs.koha-community.org 15 Apr '15

15 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10169 Bug ID: 10169 Summary: Software error if one of multiple titles selected for hold in the OPAC has no items Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org CC: gmcharlt(a)gmail.com If you select multiple titles to place on hold in the OPAC and at least one of them has no items you will get a nasty error: Can't call method "field" on an undefined value at C4/Items.pm line 1398. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 10234] New: MySQL error when adding entry to z39.50servers
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '15

14 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10234 Bug ID: 10234 Summary: MySQL error when adding entry to z39.50servers Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Database Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au Recently, someone reported getting an error when trying to add an entry into z39.50servers (http://irc.koha-community.org/koha/2013-05-09#i_1250075) Here is a snippet of their log: log: "z3950servers.pl: DBD::mysql::st execute failed: Field 'description' doesn't have a default value at /usr/share/koha/intranet/cgi-bin/admin/z3950servers.pl line 133" I believe the problem is the result of using a strict SQL mode: Strict mode controls how MySQL handles input values that are invalid or missing. A value can be invalid for several reasons. For example, it might have the wrong data type for the column, or it might be out of range. A value is missing when a new row to be inserted does not contain a value for a non-NULL column that has no explicit DEFAULT clause in its definition. (For a NULL column, NULL is inserted if the value is missing.) (http://dev.mysql.com/doc/refman/5.5/en/server-sql-mode.html [You can check different versions, they all seem to have the same behaviour from what I can tell.]) * In this case, the field 'description' has no default value but is also NOT NULL field. If your SQL mode isn't strict, you'll get a warning but the insert will succeed (using a blank value rather than a null value). However, it if it strict, you'll get an error and a rolled back/failed insert. * If we observe other fields in kohastructure.sql that are NOT NULL and don't have a "real" default value, we typically use a default of ''. This will stop the warnings and the errors. Admittedly, the field "description" is documented as not being used, so perhaps the best thing to do is remove the field or perhaps make it NULL, but...using a default of '', will be the least potentially hazardous as it won't really change anything. It'll just enforce what we know as a default behaviour of using '' when the default value is missing. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 10252] New: File Print of Checkout History Truncates Results
by bugzilla-daemon＠bugs.koha-community.org 14 Apr '15

14 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10252 Bug ID: 10252 Summary: File Print of Checkout History Truncates Results Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: bugs.koha-community.org Assignee: koha-bugs(a)lists.koha-community.org Reporter: thatcher.rea(a)bywatersolutions.com We're observing that printing of the checkout history is truncating some of the results. To replicate: Find a patron with more than 8 checkouts. Do a File-> Print of the page, and spool to PDF. The printout will drop results after 8 items. This seems to be affected in both 3.10.5 as well as master. Printing to hard copy is also affected. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2