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

[Bug 10145] New: The acquisition details block is badly placed
by bugzilla-daemon＠bugs.koha-community.org 13 May '13

13 May '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10145 Bug ID: 10145 Summary: The acquisition details block is badly placed Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.12 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)biblibre.com CC: colin.campbell(a)ptfs-europe.com Bug 5335 introduced a new "Acquisition details" block on the subscription details page. It is placed between to tabs and causes an ergonomic issue. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 10199] New: Move fields type, options and explanation from systempreferences table?
by bugzilla-daemon＠bugs.koha-community.org 13 May '13

13 May '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10199 Bug ID: 10199 Summary: Move fields type, options and explanation from systempreferences table? Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: In Discussion Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl CC: gmcharlt(a)gmail.com Currently, only local use preferences use the fields options and explanation. The normal preferences ignore these fields; they come from the YAML file now (.pref file). The use of type is somewhat hybrid. There are still some references in the code (especially for YesNo), but the preferences script again looks at the YAML file. My question is: Saving a pref file for the local use prefs does not seem an option (at least from the web interface). But could we move them elsewhere? Separate table? Another idea? If you would delete a regular pref from the yaml file now, but not from the database, it will popup without an explanation or an older one and perhaps without options or older options in the local use tab. How do you think that we should resolve this situation best? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 10175] New: Software error in opac-detail.pl when CGISESSID cookie is not set
by bugzilla-daemon＠bugs.koha-community.org 13 May '13

13 May '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10175 Bug ID: 10175 Summary: Software error in opac-detail.pl when CGISESSID cookie is not set Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: julian.maurice(a)biblibre.com Steps to reproduce: 1. Remove CGISESSID cookie (for Firefox: Edit » Preferences » Privacy » Remove specific cookie) 2. Go directly to this URL: http://YOUROPACBASEURL/cgi-bin/koha/opac-detail.pl?biblionumber=X (where X is a valid biblionumber) Message: Software error: Can't use an undefined value as a HASH reference at /home/koha/src/opac/opac-detail.pl line 445. This is related to bug 8197 -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 8840] New: ubuntu-pkg-check.sh script doesn't work on non englush setups
by bugzilla-daemon＠bugs.koha-community.org 13 May '13

13 May '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8840 Priority: P5 - low Change sponsored?: --- Bug ID: 8840 Assignee: gmcharlt(a)gmail.com Summary: ubuntu-pkg-check.sh script doesn't work on non englush setups Severity: normal Classification: Unclassified OS: All Reporter: tomascohen(a)gmail.com Hardware: All Status: NEW Version: master Component: Command-line Utilities Product: Koha The script queries for the 'Installed:' string, which only appears on english setups. -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 10079] New: HomeOrHoldingBranch controlling who can delete when IndependantBranchess should
by bugzilla-daemon＠bugs.koha-community.org 13 May '13

13 May '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10079 Bug ID: 10079 Summary: HomeOrHoldingBranch controlling who can delete when IndependantBranchess should Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: kyle(a)bywatersolutions.com Reporter: nengard(a)gmail.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Read the conversation below - the short explanation for this bug is that HomeOrHoldingBranch controls who can delete things, but that shouldn't be the case. [09:54] <nengard> "If the HomeOrHoldingBranch (HOHB) is set to 'home' an item cannot be checked out from a different branch, even if it's holding it. HOHB also controls if the the holding or home library can delete an item when IndependantBranches (IB) is on." [09:54] <nengard> but that means if you wnat to allow ILLs within the system [09:55] <nengard> you can't check out items at diff branches if it's set to HOME? [09:55] <khall> yup [09:55] <nengard> but if you set it to holding then the holding branch can delete the item even if its' not theirs [09:55] <khall> so you can either have it so other libraries can check out your items AND delete them, or neither [09:55] <nengard> that's not good [09:56] <khall> nope! File me a bug ; ) [09:56] <nengard> that needs to be split [09:56] <nengard> will do [09:56] <khall> Yeah, I think the deleting should be hard coded to home library for IndependantBranches [09:57] <khall> the other part makes a bit more sense [09:57] <khall> so the bug report should just be "When ID is enabled, don't let ID control which library can delete an item" [09:57] <khall> does that make sense? [09:57] <nengard> No [09:58] <nengard> "When ID is enabled, don't let HOHB control which library can delete an item" [09:58] <nengard> right? [09:58] <khall> right, just make it home library [09:58] <nengard> right -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 10100] New: OPAC News dates need an CSS handle (class)
by bugzilla-daemon＠bugs.koha-community.org 13 May '13

13 May '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10100 Bug ID: 10100 Summary: OPAC News dates need an CSS handle (class) Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: OPAC Assignee: adrien.saurat(a)biblibre.com Reporter: adrien.saurat(a)biblibre.com On the admin side, the footer of each news contain a P html tag associated with the "newsfooter" class. It's useful if we need to hide this through CSS. Alas, this is more often needed on the OPAC side, but there's nothing like this there. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 10116] New: Subscription history notes should be TEXT not VARCHAR(150)
by bugzilla-daemon＠bugs.koha-community.org 12 May '13

12 May '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10116 Bug ID: 10116 Summary: Subscription history notes should be TEXT not VARCHAR(150) Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: jcamins(a)cpbibliography.com CC: colin.campbell(a)ptfs-europe.com The subscription history notes (subscriptionhistory.opacnote and subscriptionhistory.librariannote) should be TEXT columns and not VARCHAR(150) columns because if a journal has been published irregularly for over a century, there could be a lot more than 150 characters worth of notes required to explain its history. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 9680] New: cart aligned right in CCSR
by bugzilla-daemon＠bugs.koha-community.org 12 May '13

12 May '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9680 Bug ID: 9680 Summary: cart aligned right in CCSR Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com Created attachment 15576 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15576&action=edit cart in prog When you're using CCSR the cart contents have a big margin on the left that's pushing them off screen. Attached are images of the same cart in both themes - the window is the same size in both. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 10054] New: When SingleBranchMode is enabled, allow superlibrarians to set logged in library
by bugzilla-daemon＠bugs.koha-community.org 12 May '13

12 May '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10054 Bug ID: 10054 Summary: When SingleBranchMode is enabled, allow superlibrarians to set logged in library Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle.m.hall(a)gmail.com Currently, when SingleBranchMode is enabled, nobody can change the logged in library in Koha. To change it requires disable SingleBranchMode, switching the library, and re-enabling it. It seems reasonable to allow superlibrarians to switch the logged in library even if SingleBranchMode is enabled. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 10156] New: Fix usr/bin/perl path for get_report_social_data.pl
by bugzilla-daemon＠bugs.koha-community.org 12 May '13

12 May '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10156 Bug ID: 10156 Summary: Fix usr/bin/perl path for get_report_social_data.pl Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au Currently, get_report_social_data.pl begins with "#!/bin/perl" rather than "#!/usr/bin/perl". While perl -c says the syntax is fine, it's been shown in one Debian install that the file won't work "zsh: no such file or directory: /bin/perl". -- You are receiving this mail because: You are watching all bug changes.

1 7