October 2009 - Koha-bugs - lists.koha-community.org

[Bug 3595] New: Items seen at checkin should always go to 1st priority hold
by bugzilla-daemon＠kohaorg.ec2.liblime.com 11 Feb '10

11 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3595 Summary: Items seen at checkin should always go to 1st priority hold Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Hold requests AssignedTo: gmcharlt(a)gmail.com ReportedBy: wizzyrea(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- For full discussion, see: http://stats.workbuffer.org/irclog/koha/2009-09-09#i_299913 Item 1 has 3 items. Patron A has a hold on item 1, Next available. She is first on the list. Library A gets pick list, has item 1a on the list. They ignore it. Patron B places a hold on item 1, next available. Item 1b crosses a scanner gun at library B, item 1b goes to fill hold for Patron B (who is 2nd in line). So to summarize, if an item is on the holds queue report, it will be treated as already allocated for the top person on the holds list. Any other copies scanned will then go to the next person on the hold list. This is incorrect behavior. The pick list (hold queue) should only be a suggestion to the librarians to go grab the book, and should not affect behavior. Other things to watch for when fixing this: - items on the holds queue that are crossing the scanner gun may be going to fill holds that have already been filled (especially for popular items). Processing the item should initiate a transfer for the next first available patron in the queue for that bib (and that may not necessarily be the patron for whom the item was initially picked) - There needs to be some sort of message alerting librarians to the fact that "this hold has already been filled, put this item back on the shelf," should there be no other holds and the hold has been filled in the interim between generation and processing of the pick list. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3

[Bug 3185] New: Mobile Library/Bookmobile Mode
by bugzilla-daemon＠liblime.com 11 Feb '10

11 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3185 Summary: Mobile Library/Bookmobile Mode Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Circulation AssignedTo: galen.charlton(a)liblime.com ReportedBy: nicole.engard(a)liblime.com Estimated Hours: 0.0 I have an idea for a Circ enhancement. In addition to the dropbox mode, why not have a Bookmobile or Mobile Library mode. This would mean that when you check items in at the Bookmobile instead of automatically transferring them back to the home library (as it does now) it keeps the books on the Bookmobile. The way it works now, if you transfer a book to the Bookmobile it's permanent location stays as the main library and it's current location is the mobile library. This is good. But if you keep a book on the mobile library for a period of time you may check it out more than once. If you check a book out and then back in it automatically goes into transfer mode back to the home library - this option would stop that from happening and allow the librarian to decide when the book goes back to the main library. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 5

[Bug 3648] New: INSTALLATION / SAX Parser Config Instructions a little cryptic
by bugzilla-daemon＠kohaorg.ec2.liblime.com 10 Feb '10

10 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3648 Summary: INSTALLATION / SAX Parser Config Instructions a little cryptic Product: Koha Version: HEAD Platform: All OS/Version: Linux - Debian Status: NEW Severity: trivial Priority: P5 Component: Installation (command-line installer) AssignedTo: gmcharlt(a)gmail.com ReportedBy: reedwade(a)gmail.com Estimated Hours: 0.0 Change sponsored?: --- PROBLEM: There are some inconsistencies in the SAX parser configuration instructions. The test is clear but how to fix if test fails is cryptic for debian, debian-lenny and ubuntu install instructions saying: "you'll need to edit your ini file" FIX: need to replace cryptic message with instructions that talk about commenting out all but- [XML::LibXML::SAX::Parser] http://xml.org/sax/features/namespaces = 1 from /etc/perl/XML/SAX/ParserDetails.ini assuming that works (seems to on lenny anyhow). ALSO: I'm happy to be assigned to patch this. -reed -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 5

[Bug 3162] New: Authority subfileds defintions and Show/Show Collapsed/Hide option
by bugzilla-daemon＠liblime.com 10 Feb '10

10 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3162 Summary: Authority subfileds defintions and Show/Show Collapsed/Hide option Product: Koha Version: rel_3_0 Platform: All OS/Version: All Status: NEW Severity: normal Priority: P5 Component: Cataloging AssignedTo: galen.charlton(a)liblime.com ReportedBy: tajoli(a)cilea.it CC: tajoli(a)cilea.it Estimated Hours: 0.0 The defintion of visibilty of MARC subfields in the enviroments used (Opac, Intranet, Editor) is different between MARC Bibliographic framework [http://<your site>:8080/cgi-bin/koha/admin/biblio_framework.pl] and Authority framework [http://<your site>:8080/cgi-bin/koha/admin/authtypes.pl] In MARC Bibliographic framework to setup this option we use an input box that accepts values between -7 to 8. The meaning of the values is explained into the on-line help. No problems here. In Authority framework there are 3 List boxes (one for Opac, one for Intranet, one for Editor). The CGI with the bug is .../admin/auth_subfields_structure.pl For example see the defintion of field 035 (on Unimarc or MARC21 default framework): http://<your site>:8080/cgi-bin/koha/admin/auth_subfields_structure.pl?op=add_form&tagfield=035&authtypecode= But those 3 values are managed by only one SQL field, auth_subfield_structure.hidden. This field is a tinyint(3) field. So, when the system tries to save a value like '000', Mysql transform it into '0'. So not all option avaible in the inteface are recoredable into auth_subfield_structure.hidden The defintions of Authority subfields in installer/data/mysql/fr-FR/marcflavour/unimarc_complet/Obligatoire/autorites_norme_unimarc.sql and in installer/data/mysql/en/marcflavour/marc21/mandatory/authorities_normal_marc21.sql still use the scale -7 ... 8 And in fact the CGI for the display .../opac/opac-authoritiesdetail.pl .../authorities/detail-biblio-search.pl .../authorities/detail.pl still use the scale -7 ... 8 with problems. In fact the lines used in ../opac/opac-authoritiesdetail.pl .../authorities/detail-biblio-search.pl .../authorities/detail.pl to check the value of auth_subfield_structure.hidden are: $subfield_data{visibility} = "display:none;" if ( ($tagslib->{$tag}->{$subfield}->{hidden} % 2 == 1) and $value ne '' or ($value eq '' and !$tagslib->{$tag}->{$subfield}->{mandatory}) ); So the only two values that it is possible to use are 0 (or every evan value that means 'show all') and -7 (or ever odd value that means hide all). Well, this the problem. About solution ? My proposal is: -- for tree 3.0 I will write a patch to use the values '0','-5' with the meanings 'show all' vs 'hide all'. I select those two values because are just now used into SQL authority default defintions. So I need to change only the code of ../admin/auth_subfields_structure.pl, the help template and display template No changes in SQL defintion, into others CGI or into SQL authority default defintions. -- for tree 3.2 I think we need to plan a better system. Probably use 3 list box is better but we need to decide: a)Do we do the work with one SQL field or with three fields ? b)And what about MARC Bibliographic framework c)And about migration of framework from 3.0 to 3.2 ? That's all, I think Bye -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 11

[Bug 3640] New: Problem with ModItemFromMarc
by bugzilla-daemon＠kohaorg.ec2.liblime.com 10 Feb '10

10 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3640 Summary: Problem with ModItemFromMarc Product: Koha Version: rel_3_2 Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: MARC Bibliographic data support AssignedTo: gmcharlt(a)gmail.com ReportedBy: henridamien(a)koha-fr.org Estimated Hours: 0.0 Change sponsored?: --- Created an attachment (id=1144) --> (http://bugs.koha.org/cgi-bin/bugzilla3/attachment.cgi?id=1144) testexemplaire is a script making the problem show up I encountered a problem ModItemFromMarc Here is a dump of Marcrecord input : LDR 00255 2200049 4500 100 _aMonchamp de test 995 _f12314123113 _010/08/2007 _10 _40 _aS 7175*BULA _d0 _gXPHIM _i17/09/2002 _md _p103513 _q213647 _sa _w17/09/2002 _z0 _vPetite Note au passage _9130837 _cU1BULA _kS 7175*BULA _rLIV _o0 _eMAG _hPJ _bU1BUCG at testexemplaires line 27. Here is a dump of the marcrecord edited 995 _f12314123113 _010/08/2007 _10 _40 _aS 7175*BULA _d0 _gXPHIM _i17/09/2002 _md _p103513 _q213647 _sa _w17/09/2002 _z0 _vPetite Note au passage _9130837 _cU1BULA _kS 7175*BULA _rLIV _o0 _eMAG _hPJ _bU1BUCG a dump of the marc record after update : 995 _f12314123113 _aMonchamp de test _9130837 _cU1BULA _kS 7175*BULA _rLIV _o0 _eMAG _hPJ _bU1BUCG -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 6

[Bug 3255] New: [3.0.x], [3.2] With dev install you must create and use a 'koha' user
by bugzilla-daemon＠liblime.com 10 Feb '10

10 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3255 Summary: [3.0.x], [3.2] With dev install you must create and use a 'koha' user Product: Koha Version: HEAD Platform: All OS/Version: All Status: NEW Severity: minor Priority: P5 Component: Installation (command-line installer) AssignedTo: galen.charlton(a)liblime.com ReportedBy: tajoli(a)cilea.it Estimated Hours: 0.0 Change sponsored?: --- If you install Koha with the 'dev' option, you can't select the value of $KOHA_USER and KOHA_GROUP variables. The installer force you to use the values 'koha', 'koha'. In fact is not a big bug, if you use a different user/group name you need only to correct by hand 2 lines of the scripts misc/bin/koha-zebraqueue-ctl.sh misc/bin/koha-pazpar2-ctl.sh misc/bin/koha-zebra-ctl.sh I send a patch about it that is only a warning during installation. I think that 'dev' option is for few user, that they are more expert of average. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 5

[Bug 3647] New: Patron Info Response Summary Item Fields contain HASH(x)
by bugzilla-daemon＠kohaorg.ec2.liblime.com 09 Feb '10

09 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3647 Summary: Patron Info Response Summary Item Fields contain HASH(x) Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: normal Priority: P5 Component: SIP2 AssignedTo: joe.atzberger(a)liblime.com ReportedBy: colin.campbell(a)ptfs-europe.com Estimated Hours: 0.0 Change sponsored?: --- In Patron Info Response if requested a list of item id should be returned. (Charged Items etc) Currently these are being populated by HASH(xxx) as the datastructure rather than one of its fields is passed to the output routine Patch to follow -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 4

[Bug 3434] New: Serials Claims Not working
by bugzilla-daemon＠liblime.com 09 Feb '10

09 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3434 Summary: Serials Claims Not working Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Serials AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: colin.campbell(a)ptfs-europe.com Estimated Hours: 0.0 Change sponsored?: --- When you try to issue a serials claim the email is not being sent and the subscription record is not updated. Causes appear to be: Invalid SQL in C4/Serials.pm Value of op is not being set correctly when clains.pl is called. Problem also present in stable release Will submit patches when they are tested -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

2 4

[Bug 3696] New: checking in invalid item causes break of comm
by bugzilla-daemon＠kohaorg.ec2.liblime.com 09 Feb '10

09 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3696 Summary: checking in invalid item causes break of comm Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: major Priority: P3 Component: SIP2 AssignedTo: joe.atzberger(a)liblime.com ReportedBy: patrick.langer(a)easycheck.org Estimated Hours: 0.0 Change sponsored?: --- When checking in an invalid (unknown) item via SIP2, communication is broken. This may be related to Bug 2653. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 5

[Bug 3723] New: Patron Information Response missing mandatory field
by bugzilla-daemon＠kohaorg.ec2.liblime.com 09 Feb '10

09 Feb '10

http://bugs.koha.org/cgi-bin/bugzilla3/show_bug.cgi?id=3723 Summary: Patron Information Response missing mandatory field Product: Koha Version: HEAD Platform: PC OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: SIP2 AssignedTo: joe.atzberger(a)liblime.com ReportedBy: colin.campbell(a)ptfs-europe.com Estimated Hours: 0.0 Change sponsored?: --- When an invalid barcode is sent in a patron information request the system is correctly responding with 'invalid patron' however the mandatory field instituition id is missing. On some selfcheck units this causes a failure in parsing the message causing an interruption in service. -- Configure bugmail: http://bugs.koha.org/cgi-bin/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are watching all bug changes.

1 3