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

[Bug 5153] New: Patron Import tool does not show progress of upload
by bugzilla-daemon＠bugs.koha-community.org 13 Aug '15

13 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5153 Summary: Patron Import tool does not show progress of upload Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Tools AssignedTo: gmcharlt(a)gmail.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 When importing patron data through the staff client, large files cause the browser to appear to hang... no progress is shown, causing many to think something has gone wrong. The Background Job code that's used in MARC importing could likely be applied to this tool to provide users with some kind of feedback about the status of their upload. -- 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 3

[Bug 5983] New: Change the wording around the CAS login
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '15

11 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5983 Bug #: 5983 Summary: Change the wording around the CAS login Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: chris(a)bigballofwax.co.nz QAContact: koha-bugs(a)lists.koha-community.org Blocks: 5584 -- 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 6864] New: add a syspref to allow custom text for OPAC user/pass information
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '15

11 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6864 Bug #: 6864 Summary: add a syspref to allow custom text for OPAC user/pass information Classification: Unclassified Change sponsored?: --- Product: Koha Version: unspecified Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: mtj(a)kohaaloha.com QAContact: koha-bugs(a)lists.koha-community.org Created attachment 5401 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=5401 image -- 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 30

[Bug 7377] New: Feature Request: Add Lexile Search for Ranges of Lexile Scores
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '15

07 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7377 Bug #: 7377 Summary: Feature Request: Add Lexile Search for Ranges of Lexile Scores Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_6 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: lzuares(a)collsk12.org QAContact: ian.walls(a)bywatersolutions.com I would really appreciate the ability to search by Lexile range from within the OPAC and/or Staff Client. I was doing some Googling and came across two submitted patches, which don't appear to have made it into 3.6. The links are listed below. -Thanks http://lists.koha-community.org/pipermail/koha-patches/2010-January/010872.… http://lists.koha-community.org/pipermail/koha-patches/2010-January/010874.… -- 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 5

[Bug 4925] New: Remove Smithsonian as a delivered z39.50 target
by bugzilla-daemon＠bugs.koha-community.org 25 Jul '15

25 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4925 Summary: Remove Smithsonian as a delivered z39.50 target Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Z39.50 / SRU / OpenSearch Servers AssignedTo: gmcharlt(a)gmail.com ReportedBy: jwagner(a)ptfs.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 I propose to remove Smithsonian Institution as a delivered sample z39.50 target for several reasons. Its collection would seem to be of limited utility for most libraries. Also, and more important, I spent a long time working with them on search problems a while back. Something has changed on their server which seems to require particular search attributes to be sent as part of the search. As it stands now in Koha, only a raw (keyword) search and an author search will produce any results. A title search fails unless it's the full, exact title -- no partial entries. ISBN/ISSN, subject headings, LC call number, and other searches all fail even if a known entry is sent. Koha is using title attr 1=4 for all z39.50 title search, as near as I can tell, and Smithsonian says they're set to use 44. Similar for subject -- Koha is set to 21 and Smithsonian is using 121. A manual yaz z39.50 search specifying the right attributes does work on Smithsonian, but changing them would screw up other z39.50 searches that are now working properly. Any objections to just removing Smithsonian from the list? -- 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 7372] New: RoadTypes should be folded into Authorised Values
by bugzilla-daemon＠bugs.koha-community.org 21 Jul '15

21 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7372 Bug #: 7372 Summary: RoadTypes should be folded into Authorised Values Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_8 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing AssignedTo: ian.walls(a)bywatersolutions.com ReportedBy: ian.walls(a)bywatersolutions.com QAContact: jonathan.druart(a)biblibre.com The current data structure for Road Types is essentially the same as for Authorised Values, but it gets it's own admin page and database table. In an effort to simply both the Koha data structure, and the admin main page, I suggest moving this into Authorised Values. This development is marked as "(OUEST-PROVENCE)". Is there a reason for the separate table and admin page that I don't understand, (not being in a European library)? -- 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 29

[Bug 5515] New: Leading 'and' in search never returns a result
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5515 Summary: Leading 'and' in search never returns a result Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: PC OS/Version: Linux Status: NEW Severity: major Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: bob-ewart(a)bobsown.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Searching on "and the band played on" returns no results. There are 3 biblios for that title, a book, a DVD and a video. The error log shows: [Thu Dec 16 17:18:27 2010] [error] [client 127.0.0.2] [Thu Dec 16 17:18:27 2010] search.pl: WARNING: query problem with kw,wrdl,rtrn=and band played ZOOM error 10014 "CCL parsing error" (addinfo: "Search word expected") from diag-set 'ZOOM' at /usr/share/koha/lib/C4/Search.pm line 346., referer: http://127.0.0.2:8080/cgi-bin/koha/mainpage.pl This happens with Koha 3.02.01 on openSUSE 11.3 (32-bit and 64-bit) and on Debian squeeze/sid (64-bit) with zebra. Searching on 'the band played on' gets all three records. -- 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 10

[Bug 6976] New: User hold limit can be avoided by users in OPAC
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6976 Bug #: 6976 Summary: User hold limit can be avoided by users in OPAC Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: colin.campbell(a)ptfs-europe.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com Problem as reported: borrowers are only allowed 5 holds. If holds are done individually, it is obeying that law i.e. X has held 5 separate books – when I tried to do a 6th book it told me that I could not place a hold. However, if a borrower checks the catalogue, gets the intial list up and clicks items on the “results” box and then clicks “place hold” they can hold more than 5 items – I have been able to hold 8 (and I suspect could do more) Looks like the logic is a bit flawed when placing multiple holds as the variable canreserve is not reset for each iteration of the loop. Testing fix on site patch to follow -- 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 37

[Bug 5711] New: Distinction between authors/additional authors in opac normal view (MARC21/XSLT)
by bugzilla-daemon＠bugs.koha-community.org 13 Jul '15

13 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5711 Summary: Distinction between authors/additional authors in opac normal view (MARC21/XSLT) Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: OPAC AssignedTo: oleonard(a)myacpl.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 The patch for bug 5701 put the additional authors with their relator codes on their own line in the staff client and we should do the same in the OPAC. I suggest a further break out that looks like this: Author: Editor: Illustrator: Translator: Additional Authors: Otherwise the editor or translator will appear as an author and that's confusing I think to the patrons. Relator Codes here: http://www.loc.gov/marc/relators/relaterm.html -- 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 7

[Bug 5533] New: marking item lost diff in two places
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '15

10 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5533 Summary: marking item lost diff in two places Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: critical Priority: P5 Component: Cataloging AssignedTo: gmcharlt(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 Please see this screencast for details: http://screencast.com/t/6CJlMGQn2r42 Basically if you mark an item lost via edit items there is one behavior and if you mark it lost via the items tab there is another behavior. I think that the behavior that happens on the items tab is what we want (marking the item lost charges the patron the replacement fee). -- 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 49