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

[Bug 2394] canreservefromotherbranches preference not working
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '13

10 Jul '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2394 --- Comment #7 from Srdjan Jankovic <srdjan(a)catalyst.net.nz> --- Yes. But maybe we should consult whoever introduced canreservefromotherbranches. -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 2394] canreservefromotherbranches preference not working
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '13

10 Jul '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2394 --- Comment #6 from Julian Maurice <julian.maurice(a)biblibre.com> --- (In reply to Srdjan Jankovic from comment #5) > I don't think // is in order here. Besides, maybe it should check both > holdingbranch and homebranch? And allow reserve if one of those is the user's branch ? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 10561] New: DisplayOPACiconsXSLT shouldn't control more than icon display
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '13

10 Jul '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10561 Bug ID: 10561 Summary: DisplayOPACiconsXSLT shouldn't control more than icon display Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au Currently, DisplayOPACiconsXSLT has a description of "On pages displayed with XSLT stylesheets on the OPAC, "show|don't show" icons for itemtype and authorized values." However, that is not its actual behaviour! Turning it on/off does show/hide OPAC icons in the XSLT... However, turning on/off "DisplayOPACiconsXSLT" also displays/hides information on the "Type", "Format", "Literary Form", etc. In other words, lots of valuable information from the fixed fields in the Leader, 006, 007, and/or 008. We should probably be checking $DisplayOPACiconsXSLT each time we go to print an IMG element, rather than encasing that whole block of text inside the $DisplayOPACiconsXSLT flag. We're losing valuable information if we turn off a system preference that is supposed to govern the display of icons. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 9691] New: Acquisition's "Statistic" fields not being populated by Asort authorised_value categories
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '13

10 Jul '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9691 Bug ID: 9691 Summary: Acquisition's "Statistic" fields not being populated by Asort authorised_value categories Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au Currently, when you are adding an order to a basket in the Acquisitions module, there are two "Statistic" input fields which link to the Sort1 and Sort2 fields in the aqorders table. These "Statistic" input fields should also be linked to the Asort1 and Asort2 authorised value categories, which should cause drop-down menus to replace the free-text input fields, when there are values in these categories. Currently, this is not happening. To test: 1) Go to Acquisitions 2) Do a Vendor search (Note: an empty value in the search will retrieve all vendors) 3) Click on New Basket, and type in a test basket name 4) Add order to the basket by one of the means provided 5) Note that the "Statistic 1" and "Statistic 2" fields are free-text inputs fields (example URL: (/cgi-bin/koha/acqui/neworderempty.pl?booksellerid=1&basketno=27&biblionumber=1)) 6) In a new tab, go to Administration->Authorized Values 7) Add values to the Asort1 and Asort2 categories 8) Refresh the page showing "Statistic 1" and "Statistic 2" 9) Note that the input fields are still free-text and not drop-down menus (Note: feel free to flush your memcache to check to see if it's a template caching issue. I've already done this and it doesn't seem to be the case.) For an example of the behaviour that should occur: 1) Add values to Bsort1 2) Create a new Patron 3) Note that BSort2 is a free-text input field (if the BSort2 authorised value category is empty), while Bsort1 will be a drop-down list of the values you added to the authorised value list. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 10562] New: Improve Leader06 Type Labels in MARC21slim2OPACResults.xsl
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '13

10 Jul '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10562 Bug ID: 10562 Summary: Improve Leader06 Type Labels in MARC21slim2OPACResults.xsl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au Within the $DisplayOPACiconsXSLT block in MARC21slim2OPACResults.xsl, we're mapping fixed field data to non-standard human-readable labels. While I think the non-standard labels we use are far more useful for users than the standard labels supplied by the LoC, I think that ours, at least in the case of position 6 of the Leader, are not entirely accurate. Here are the actual mappings (from http://www.loc.gov/marc/bibliographic/bdleader.html) a - Language material c - Notated music d - Manuscript notated music e - Cartographic material f - Manuscript cartographic material g - Projected medium i - Nonmusical sound recording j - Musical sound recording k - Two-dimensional nonprojectable graphic m - Computer file o - Kit p - Mixed materials r - Three-dimensional artifact or naturally occurring object t - Manuscript language material Below, I show our basic mappings in Koha (plus add my suggestion in brackets behind it) a => Book [Text] c => Score d => Score e => Map f => Map g => Visual Material [Film] i => Sound j => Music k => Visual Material [Picture] m => Computer File o => Kit p => Mixed Materials r => Visual Material [Object] t => Book [Text] -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 2394] canreservefromotherbranches preference not working
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '13

10 Jul '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2394 Srdjan Jankovic <srdjan(a)catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |srdjan(a)catalyst.net.nz --- Comment #5 from Srdjan Jankovic <srdjan(a)catalyst.net.nz> --- I don't think // is in order here. Besides, maybe it should check both holdingbranch and homebranch? -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 9539] New: Make visible "Add" and "Clear" buttons when receiving an document
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '13

09 Jul '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9539 Bug ID: 9539 Summary: Make visible "Add" and "Clear" buttons when receiving an document 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 If you create items when you receive documents, you must click on "Add" at the bottom of the each item block. Very often, librarians don't see the "Add" and "Clear" links and just click on "Save" button at the end of the form So, it would improve Koha usability to make "Add" and "Clear" more visible. M. Saby Rennes 2 University -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 2394] canreservefromotherbranches preference not working
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '13

09 Jul '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2394 Julian Maurice <julian.maurice(a)biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff CC| |julian.maurice(a)biblibre.com -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 2394] canreservefromotherbranches preference not working
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '13

09 Jul '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2394 --- Comment #4 from Julian Maurice <julian.maurice(a)biblibre.com> --- Created attachment 19498 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=19498&action=edit Bug 2394: Use syspref canreservefromotherbranches in CanItemBeReserved -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 7291] New: claims management improvement
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '13

09 Jul '13

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7291 Bug #: 7291 Summary: claims management improvement Classification: Unclassified Change sponsored?: Sponsored Product: Koha Version: rel_3_8 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions AssignedTo: claire.hernandez(a)biblibre.com ReportedBy: claire.hernandez(a)biblibre.com QAContact: ian.walls(a)bywatersolutions.com Blocks: 7163 claim: button "check all" & estimated date. Add a button to "check all" on the acquisition claim page. A filter on estimated dates will be added (BibLibre MT6546) -- 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 30