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

[Bug 14477] New: Indicators
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14477 Bug ID: 14477 Summary: Indicators Change sponsored?: --- Product: Koha Version: 3.16 Hardware: PC OS: Windows Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: joao.pinto(a)ua.pt QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi there Does anyone have validation over indicators in the marc fields, working for UNIMARC? And if so how? Do you use a drop down list so operators can choose from, the diferent indicatores values? I trying to put something working for this and nothing it's working about indicators. Thank you -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 11112] New: Koha::Calendar->new loads all holidays
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11112 Bug ID: 11112 Summary: Koha::Calendar->new loads all holidays Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Each time a new Koha::Calendar is created, all holidays are retrieved from the DB. On a 3.8 installation, with 11000 holidays and without caching system, a checkin is extremely slow. -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 12329] New: Inventory setting date last seen to 0
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12329 Bug ID: 12329 Summary: Inventory setting date last seen to 0 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 28554 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=28554&action=edit inventory settings I have tested on 3.14.6 and master. When you run inventory on a file you load of barcodes it sets the datelastseen to 0000-00-00 no matter what date you enter in to have it set to. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 12327] New: option to not check in with inventory
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12327 Bug ID: 12327 Summary: option to not check in with inventory Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be nice if Inventory offered a check box that said "don't check in items scanned during inventory". -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 14429] New: Barcode is not updated in databse
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14429 Bug ID: 14429 Summary: Barcode is not updated in databse Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: Linux Status: NEW Severity: major Priority: P5 - low Component: Developer documentation Assignee: gmcharlt(a)gmail.com Reporter: mr.bnikhil(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org while adding a new book/journals we are not able to update the barcode into database. Its always or only null values are being updated into tables(Items,biblioitems,biblio) where as barcode is in only Items table. we are not able trace whats happening and where the problem is. In administration tab barcode is mapped to items.barcode (952$p). please suggest the solution. Its High priority. -- You are receiving this mail because: You are watching all bug changes.

1 3

[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 8697] New: slips not using custom lists on all pages
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8697 Priority: P5 - low Change sponsored?: --- Bug ID: 8697 Assignee: koha-bugs(a)lists.koha-community.org Summary: slips not using custom lists on all pages Severity: major Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Notices Product: Koha When on the patron record on the Details or Fines tab if you choose to print slip or quick slip it chooses the 'all libraries' slip. Other tabs - like the checkout tab use the custom slip for that branch. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[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 7830] New: return policy error in hold policy by item type after upgrade
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7830 Priority: P5 - low Change sponsored?: --- Bug ID: 7830 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: return policy error in hold policy by item type after upgrade QA Contact: koha.sekjal(a)gmail.com Severity: major Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Circulation Depends on: 7144 Product: Koha Created attachment 8633 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8633&action=edit error message After upgrading to master (as of this morning) I see the attached on my circ and fine rules. Shouldn't this have a default value set on upgrade so that there isn't an error? I think this comes from the Floating Collections dev - but I'm not sure. Adding a 'depends on' for that bug report. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 9730] New: The sub 'AnonymiseIssueHistory' fails quietly if 'AnonymousPatron' is not a valid entry
by bugzilla-daemon＠bugs.koha-community.org 14 Jul '15

14 Jul '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9730 Bug ID: 9730 Summary: The sub 'AnonymiseIssueHistory' fails quietly if 'AnonymousPatron' is not a valid entry Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: christophe.croullebois(a)biblibre.com it fails also if 'AnonymousPatron' = 0 With the patch in this case the borrowernumber becomes NULL -- You are receiving this mail because: You are watching all bug changes.

1 10