February 2015 - Koha-bugs - lists.koha-community.org

[Bug 12993] New: Add a default tax rate on item types
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '15

09 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12993 Bug ID: 12993 Summary: Add a default tax rate on item types 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 This enhancement will permit to set a default tax rate for item types. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47

[Bug 9321] New: holds queue printable version
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '15

09 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9321 Bug ID: 9321 Summary: holds queue printable version Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.8 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com It would be nice if there were a printable stylesheet for the holds queue. Right now it's a print screen basically and that means that the table doesn't always fit on the page - in fact it never has for me. I think it should be a list or a thinner table or something a bit more printer friendly. -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 10662] New: Build OAI-PMH Harvesting Client
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '15

09 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10662 Bug ID: 10662 Summary: Build OAI-PMH Harvesting Client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, Koha only acts as a OAI-PMH server, I propose to add a harvesting client as well (likely using the HTTP::OAI::Harvester module), so that Koha can ingest records from other data sources (such as digital repositories like Dspace). I've only started reading about it but despite initial reservations about resumption tokens, I think the hardest part will not be with the retrieval of records so much as the parsing of those records into MARC. The Library of Congress does provide some crosswalks (http://www.loc.gov/standards/marcxml/) for converting other metadata formats into MARC21. However, the DC to MARC crosswalk (which is the obvious choice for Dspace) does not produce records of a high quality. So, as part of this new feature, I will also be working on a more complete DC to MARC crosswalk. Their DCMI terms (http://dublincore.org/documents/2012/06/14/dcmi-terms/?v=elements#type) have been mapped reasonably well to the MARC21 LEADER 6th and 7th positions, which improves the quality of the record and helps to produce a "best guess" 008. I'll be looking at adding more datafields and providing better fixed field transformation. Of course, some OAI-PMH repositories serve MARC so this crosswalk might not always be necessary. However, I've looked at Dspace's DC=>MARC crosswalk and it's similar to the LoC one, so I think this will be a valuable addition (both to Koha and to anyone wanting to transform DC to MARC21). As I mentioned, I'm just starting out with OAI-PMH, but I imagine having Koha as a OAI-PMH harvester might be useful in union catalogue situations where other servers might send quality MARC records. -- My plan: 1) Set up a script that is able to continuously harvest records from a OAI-PMH server (likely Dspace or Koha itself for my trials) 2) Set up a database table to handle harvester configuration (such as baseurl, sets, (possibly dates), metadata format, and any pointers to XSLTs. 3) Set up a solid (yet likely basic) DC => MARC XSLT. If anyone has comments or advice, I'd love to hear it. Hopefully, I'll be able to focus on this over the next little while... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 79

[Bug 7985] New: In Checkout, list of items checked out should show Charge from table accountlines
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '15

08 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7985 Priority: P5 - low Change sponsored?: --- Bug ID: 7985 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: In Checkout, list of items checked out should show Charge from table accountlines QA Contact: koha.sekjal(a)gmail.com Severity: normal Classification: Unclassified OS: All Reporter: veron(a)veron.ch Hardware: All Status: NEW Version: unspecified Component: Circulation Product: Koha Created attachment 9262 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=9262&action=edit List of fines&charges (above) and list of checkouts (below). Do the following: ----------------- - Check out some items from a certain item type (to saem patron) - Modify item type, change Rental charge - Check out additional item to same patron Result: ------- In the list of checkouts, all items show the new rental charge and not the Rental charge that was applied at chckout time. Totals differ. This situation will result in a lot of support questions. See screenshot in attachment, first and second item were issued with a rental charge of 1.01 and 3rd with a rental charge of 1.02. The values are displayed correctly under the fines tab. Fazit: ------ The list of checkouts should be linked with the table accountlines instead of grabbing the current value of the rental charge from the item type. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 7041] New: Sort >1000 search results with sortmax parameter in zebra config file
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '15

08 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7041 Bug #: 7041 Summary: Sort >1000 search results with sortmax parameter in zebra config file Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: m.de.rooy(a)rijksmuseum.nl QAContact: koha-bugs(a)lists.koha-community.org By default, zebra does not sort more than 1000 records (search results). You can increase this number by adding the sortmax parameter in zebra-biblios.cfg. Putting this value in Koha's zebra config file will make this default value visible and make it easier to increase it if one prefers that. This patch therefore adds the default of 1000 to zebra-biblios.cfg. Does not change any Koha/Zebra behavior. If you want to test it, look for a search in your catalog with >1000 results. Look at the order of the records. Now apply the patch and copy the zebra-biblios.cfg to your zebra directory. Increase sortmax, reindex and search again. If you increased sortmax above the number of hits, you should see a difference in sort order now. -- 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 11

[Bug 13029] New: Allow to pass additional parameters to SMS::Send drivers
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '15

08 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13029 Bug ID: 13029 Summary: Allow to pass additional parameters to SMS::Send drivers Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Notices Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 13376] New: Include a user-editable area/page for terms and conditions of use in the opac
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '15

08 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13376 Bug ID: 13376 Summary: Include a user-editable area/page for terms and conditions of use in the opac Change sponsored?: --- Product: Koha Version: 3.16 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: liz(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org Since Koha collects user data, we should have a place for libraries to include their website terms and conditions (and/or cookie policy information). I am thinking a link that appears in the footer area of every page if there is text in a system preference (along the lines of OpacMainUserBlock - free text area that accepts html). The contents of the syspref would be displayed in a page that has the same layout as the home page. I realise that libraries can use a page on their website to do that, but as Koha sometimes stands in for a website for libraries, I think it's important to at least offer a place to put the terms and conditions of use. We could also offer a standardised set of terms and conditions for the syspref (default value) - but a problem here is that people might not edit it, and getting one general enough might be problematic. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 12802] New: Sent notices using several email addresses
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '15

08 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12802 Bug ID: 12802 Summary: Sent notices using several email addresses Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org At the moment, the only place where a library can sent several emails to 1 patron is the overdue_notices.pl script. The mechanism will be extended to all notices. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 66

[Bug 9163] New: Cataloguing validation workflow
by bugzilla-daemon＠bugs.koha-community.org 08 Dec '15

08 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9163 Bug ID: 9163 Summary: Cataloguing validation workflow Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: vfernandes(a)keep.pt CC: m.de.rooy(a)rijksmuseum.nl New feature to have cataloguing validation workflow (some user validates the cataloguing of others and put the record online in OPAC). The idea is the following: - all framework needs to have suppress subfield hidden - the normal cataloguers uses this frameworks to catalogue the record - the record will not have suppress subfield filled (I don't know what happens when the record has no suppress - if it appears there is the need of set suppress = 1 automatically) - there is special framework with suppress subfield visible - only some users have access to the special framework - those users uses the special framework to validate the cataloguing and set suppress = 0 if everything is OK (after indexation the record appears online in OPAC) To have this working there is the need of a multi system preference with 3 options: 1 - Turn on/off the validation workflow (controll the appearing of the special framework in the dropdown list in addbook.pl and addbiblio.pl, set suppress = 1 if needed, etc) 2 - Set which will be the special framework (text box to set the framework code) 3 - List of users with access to this functionallity separated by comma (can be a permission but if the validation is off the permission has no sense, can be a file in the Koha structure with each username in one line, etc...) -- You are receiving this mail because: You are watching all bug changes.

1 40

[Bug 10121] New: unhighlight doesn't carry over to other pages
by bugzilla-daemon＠bugs.koha-community.org 07 Dec '15

07 Dec '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10121 Bug ID: 10121 Summary: unhighlight doesn't carry over to other pages Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com I I click 'unhighlight' on page 1 of my results and then go to page 2 it's highlighted. My option to 'unhighlight' should carry over. -- You are receiving this mail because: You are watching all bug changes.

1 4