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

[Bug 5262] New: authority plugin doesn't copy indicators
by bugzilla-daemon＠bugs.koha-community.org 20 Aug '15

20 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5262 Summary: authority plugin doesn't copy indicators Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: MARC Authority data support AssignedTo: gmcharlt(a)gmail.com ReportedBy: januszop(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 While adding/editing a bibliographic record, the authority plugin inserts the content of an authority record (subfields) into a bibliographic record (e.g. PERSO_NAME --> bibliographic 100/700/800 field), BUT the indicators doesn't copy (i.e. ind1=1 for surname in authority 100 field doesn't appear in bibliographic). At first sight changes in (at least) following files are needed: intranet/cgi-bin/authorities/blinddetail-biblio-search.pl intranet/htdocs/intranet-tmpl/prog/en/modules/authorities/blinddetail-biblio-search.tmpl Regards! Janusz -- 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 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 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 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 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

[Bug 5025] New: discrepancy between opac doc-head-open.inc and staff doc-head-open.inc
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '15

10 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5025 Summary: discrepancy between opac doc-head-open.inc and staff doc-head-open.inc Change sponsored?: --- Product: Koha Version: rel_3_4 Platform: All OS/Version: All Status: NEW Severity: trivial Priority: P5 Component: Templates AssignedTo: oleonard(a)myacpl.org ReportedBy: gmcharlt(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 The OPAC version includes a starting <title> tag, the intranet version does not. Hardly earth-shattering, but if there's no reason for the difference, reconciling them would might be a nice activity for a rainy day when there are no more important bugs to fix. -- 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 24

[Bug 5362] New: Simple (non-MARC) cataloging interface
by bugzilla-daemon＠bugs.koha-community.org 20 Jun '15

20 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5362 Summary: Simple (non-MARC) cataloging interface 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: koha(a)cpbibliography.com QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Estimated Hours: 0.0 We would like to add a simple (non-MARC) cataloging interface back into Koha. The interface is described in more detail in the RFC on the wiki at http://wiki.koha-community.org/wiki/Simple_cataloging_interface -- 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 5566] New: Misleading grouping of lost items in staff client search results
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '15

06 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5566 Summary: Misleading grouping of lost items in staff client search results Change sponsored?: --- Product: Koha Version: HEAD Platform: All URL: /cgi-bin/koha/catalogue/search.pl OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Searching AssignedTo: gmcharlt(a)gmail.com ReportedBy: oleonard(a)myacpl.org QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Created attachment 2931 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=2931 Screenshot of the described problem If a title has multiple items with different lost statuses, the output of search results in the staff client is misleading because of the way statuses are labeled. This is true if: - items are the from the same branch - items have the same call number - items have different values for itemlost In the example screenshot 2 Athens DVDs are Lost (lost) and one is Lost (missing). These items should either be grouped by authorized value category ("LOST") or each line should output the authorized value description ("Lost","Missing") to make it clear why they are grouped separately. -- 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 5196] New: 006 subfields 01-17 should be populated depending on the 00 value
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '15

06 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5196 Summary: 006 subfields 01-17 should be populated depending on the 00 value Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: major 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 And depending on what value is selected for 006/00, there are need more options for 006/01 through 006/17 as well. All of these can be found at: http://www.loc.gov/marc/bibliographic/bd006.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 6

[Bug 5198] New: HOLDPLACED being logged in patron messages
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '15

06 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5198 Summary: HOLDPLACED being logged in patron messages Change sponsored?: --- Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Notices AssignedTo: henridamien(a)koha-fr.org ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Estimated Hours: 0.0 Created attachment 2601 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=2601 hold placed logged on patron record When the hold placed message is sent it goes out to the librarian only. I have confirmed this in the message queue in the database. However as you see in the attachment the message is being logged on the patron record for some reason. This is confusing to librarians and should not happen. The default message also looks like it's formatted for being sent to the patrons - not to the librarians so the message should be changed to make it clear (at least in new installs) that this message goes to librarians, not patrons. -- 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