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

[Bug 6254] New: can't set patron privacy by default
by bugzilla-daemon＠bugs.koha-community.org 04 Feb '15

04 Feb '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6254 Bug #: 6254 Summary: can't set patron privacy by default Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Patrons AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When you do a bulk patron import you can choose a privacy setting for your patrons, but when you create a new patron you can't. Many libraries want the default to be 'Never' and have the patrons opt in - while others want the patrons to choose to opt-out instead. Given this librarians should be able to set the default per patron or patron category and then never be allowed to edit that once it's set (in order to let the patron have control over the preference). -- 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 60

[Bug 6138] New: Show local help and isbd punctuation automatically when we are cataloguing
by bugzilla-daemon＠bugs.koha-community.org 23 Jan '15

23 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6138 Bug #: 6138 Summary: Show local help and isbd punctuation automatically when we are cataloguing Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: juan.sieira(a)xercode.es QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Created attachment 3828 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=3828 proposed patch Show local help and isbd punctuation automatically when we are cataloguing. In administration->MARC Bibliographic framework->Marc Structure->Subfields->Edit subfields there are two new fields, punctuacion and help. We have to fill those fields with some help and the isbd punctuation to a determinate subfield. Those values will appear when we are cataloguing. Our libraries requested this change because they need help in the cataloguing process to follow its their procedures manual. If you dont want to execute updatedatabase.pl, simply execute this statement in you database ALTER TABLE `marc_subfield_structure` ADD `punctuation` VARCHAR( 5 ) NULL , ADD `help` VARCHAR( 255 ) NULL; -- 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 14

[Bug 5632] New: SIP improvements = Date formatting & debarrement management
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '15

18 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5632 Summary: SIP improvements = Date formatting & debarrement management Change sponsored?: Sponsored Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: ASSIGNED Severity: enhancement Priority: PATCH-Sent Component: SIP2 AssignedTo: paul.poulain(a)biblibre.com ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 * the dates should be printed in human-readable format, not in timestamp * The patron debarment can now have a date (new feature of BibLibre circ improvements). We have to deal with this date on the SIP messages -- 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 5592] New: circ rule cloning can be dangerous
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '15

08 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5592 Summary: circ rule cloning can be dangerous Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: System Administration AssignedTo: paul.poulain(a)biblibre.com ReportedBy: gmcharlt(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 The clone circ rules widget on the circ rules page unconditionally deletes the target library's existing rules and replaces them with copies of the rules from the source library. Consequently, if the clone rule button is accidentally clicked, a lot of configuration work can be destroyed in an instant. To avoid this: * there should *always* be a required confirmation step, whether the clone-rules.pl script is accessed directly or via the smart-rules.pl page * even better, a backup copy of the previous version of the target library's rules could be made The library who ran into this bug had tried cloning the rules form a different library because they thought that would be a way to copy over that library's rules and add them to the rules that the target library had previously entered -- that kind of cloning-via-merge feature also seems like a good idea, in fact. -- 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 4

[Bug 6341] New: Request for multiple calendar support option
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6341 Bug #: 6341 Summary: Request for multiple calendar support option Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Holidays AssignedTo: henridamien(a)koha-fr.org ReportedBy: indradg(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Koha provides only a single calendar option - the Gregorian calendar. However, in places like India, the *official* national calendar is not Gregorian, although it is used alongside. Plus in rural parts of country, many people still using the "old" non-Gregorian standard. See http://en.wikipedia.org/wiki/Indian_national_calendar It will be nice if Koha can support the option of choosing from multiple calendars. I believe support for Hejri (the Islamic calendar) may also be required for middle-East deployments. -- 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 6416] New: koha-remove fails when dropping user
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6416 Bug #: 6416 Summary: koha-remove fails when dropping user Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Packaging AssignedTo: robin(a)catalyst.net.nz ReportedBy: magnus(a)enger.priv.no QAContact: koha-bugs(a)lists.koha-community.org I have MySQL running on the same machine as Apache/Koha, and have created a new library with "sudo koha-create --create-db demo". When i do "sudo koha-remove demo" I get this: Removing Koha instance demo ERROR 1396 (HY000) at line 1: Operation DROP USER failed for 'koha_demo'@'%' When I log in to mysql as root and do this: DROP USER failed for 'koha_demo'@'%'; I get pretty much the same message. But when I replace % with localhost and do this: DROP USER failed for 'koha_demo'@'localhost'; it succeeds. -- 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 4

[Bug 5851] New: SIP Slips printed in wrong circumstances -- Local hold and no hold items
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5851 Bug #: 5851 Summary: SIP Slips printed in wrong circumstances -- Local hold and no hold items Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: SIP2 AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: wizzyrea(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Here is how we would like the check-in process to work in Koha on the SIP connection: 1) a WALKIN item type should never generate a hold slip (currently does) 2) a LOCALHOLD type should only generate a hold slip if there is an unfilled hold for a local patron (currently does for any hold) 3) If a hold slip is generated for any valid circumstances... a) the item processed should be tied to the patron on the slip b) the item should be in the proper status (hold should be confirmed and put in transit if necessary) In summary, when a hold slip is generated we should be able to place the slip in the item and put it in the courier or on our hold shelf. -- 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 4892] New: Make the accounts page page, so that the list of records doesn't end up being huge.
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4892 Summary: Make the accounts page page, so that the list of records doesn't end up being huge. Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Patrons AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: robin(a)catalyst.net.nz QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Estimated Hours: 0.0 The Patrons > Account for John Smith page has a list of every transaction ever involving that user. This can get pretty big, so this patch makes that list have 'Newer' and 'Older' links to make this less of an issue. -- 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 15

[Bug 5348] New: currency handling & display
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5348 Summary: currency handling & display Change sponsored?: Sponsored Product: Koha Version: rel_3_4 Platform: All URL: http://wiki.koha-community.org/wiki/Currencly_handling _RFC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Acquisitions AssignedTo: henridamien(a)koha-fr.org ReportedBy: paul.poulain(a)biblibre.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Deadline: 2011-05-01 We will generalise the use of Locale::Currency::Format and improve it (EUR & USD being hardcoded atm) -- 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 5842] New: Cross-Reference links to authorized fields give incomplete search results
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '15

06 Jan '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5842 Bug #: 5842 Summary: Cross-Reference links to authorized fields give incomplete search results Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: jwagner(a)ptfs.com QAContact: koha-bugs(a)lists.koha-community.org The end-result problem is that clicking on cross-reference links in OPAC or staff XSLT title displays (authors, subjects) can produce incomplete results. The underlying problem is fairly complex. (Kudos to Bev Church for doing a lot of the in-depth research.) At the moment, there is only one system preference that controls authority creation -- BiblioAddsAuthorities. If you set the preference to OFF, staff cannot enter data in any authority controlled subfield. o Staff must first create an authority record and then link it to the bibliographic record if they manually create a bibliographic record. This is not a viable option for a lot of sites; they do not want to work with authority records or don't have the knowledge to create and then link a record. o Koha does no automatic bib/authority linking or authority creation if bibliographic records are imported using Z39.50 and the MARC import tool. If you set the preference to ON, staff can enter data in any authority controlled subfield. o Koha does automatic bib/authority linking and authority creation if bibliographic records are manually added or imported using Z39.50. o Koha does NO automatic bib/authority linking and authority creation if bibliographic records are added using the MARC import tool. With BiblioAddsAuthorities on, if a site does batch imports, the end result is that some authority controlled tags in their bibliographic records are linked to authority records while others are not. This affects the way Koha retrieves titles when users/staff click on the authority links in the full bibliographic record due to a searching enhancement. As it stands, the XSLT for both staff and OPAC checks for any authority record number in subfield $9 of authority controlled tags (the various author and subject fields) in the bibliographic record. If one exists, Koha uses the authority number as the search parameter instead of the name/subject string itself. For example, in an OPAC XSLT title record display, clicking on the author or one of the subjects will search against the titles linked to the authority record, not the equivalent author or subject zebra index. The search results may not be complete -- there are most probably fewer hits than if the search was done as a zebra title or subject search. See the following difference in how those cross-reference search links are formed with and without the link to the authority record: http://myserver/cgi-bin/koha/opac-search.pl?q=an:37 http://myserver/cgi-bin/koha/opac-search.pl?q=au:Carroll,%20Jonathan, http://myserver/cgi-bin/koha/opac-search.pl?q=an:38 http://myserver/cgi-bin/koha/opac-search.pl?q=su:Children%27s%20stories The most complete fix would be to modify the batch import tool to create the brief authority records, and do some substantial work on linking and merging authority records. I don't have the skill to do that, but I came up with a partial lipstick-on-a-pig solution. I created a system preference called CrossRefsUseAuthorities with this description: "If on, author and subject cross-references from title displays will use authority record to find related titles in staff and OPAC XSLT title display. If off, forces author and subject cross-reference searches to use the zebra indexes rather than the authority indexes; needed when BiblioAddsAuthorities is on but not all records have authorities (or there are multiple authority records). In that situation, a cross-reference search on the authority entry will not retrieve all titles." This tested and worked OK for OPAC XSLT, but I could not make it work for staff XSLT. The problem there seems to be that the part of C4/XSLT.pm which passes variables to the XSLT stylesheet is not being obeyed: foreach my $syspref ( qw/OPACURLOpenInNewWindow DisplayOPACiconsXSLT URLLinkText viewISBD OPACBaseURL CrossRefsUseAuthorities/ ) { Therefore, when I tried to modify the staff XSLT files similar to the change I did in the OPAC XSLT files: <xsl:choose> <xsl:when test="marc:subfield[@code=9] and $CrossRefsUseAuthorities!='0'"> <xsl:attribute name="href">/cgi-bin/koha/opac-search.pl?q=an:<xsl:value-of select="marc:subfield[@code=9]"/></xsl:attribute> </xsl:when> <xsl:otherwise> <xsl:attribute name="href">/cgi-bin/koha/opac-search.pl?q=au:<xsl:value-of select="marc:subfield[@code='a']"/></xsl:attribute> </xsl:otherwise> </xsl:choose> I got error messages about invalid variables from trying to use the system preference. I don't know how to fix that problem. I am attaching a patch file for the part that I do have working (the syspref and the OPAC XSLT files). Can someone test those? Any takers to (a) solve the staff XSLT problem and/or (b) solve the underlying problem of authorities not being created with imports? -- 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 8