July 2013 - Koha-bugs - lists.koha-community.org

[Bug 8579] New: Need script for updating authority 001s
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '15

09 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8579 Priority: P5 - low Change sponsored?: --- Bug ID: 8579 Assignee: jcamins(a)cpbibliography.com Summary: Need script for updating authority 001s Severity: enhancement Classification: Unclassified OS: All Reporter: jcamins(a)cpbibliography.com Hardware: All Status: NEW Version: master Component: MARC Authority data support Product: Koha Because bulkmarcimport.pl does not correctly set the 001 field for authority records, libraries end up with authority files full of records with invalid 001 fields. There should be a script that can retroactively populate the 001 field with the authid. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 9712] New: Add command line script to recalculate existing due dates based on current issuing rules and retroactively update the issues
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '15

09 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9712 Bug ID: 9712 Summary: Add command line script to recalculate existing due dates based on current issuing rules and retroactively update the issues Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 9678] New: fields in wrong tab in books framework
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '15

08 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9678 Bug ID: 9678 Summary: fields in wrong tab in books framework Classification: Unclassified Change sponsored?: --- Product: Koha Version: 3.10 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: nengard(a)gmail.com CC: m.de.rooy(a)rijksmuseum.nl Created attachment 15575 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=15575&action=edit 9 tab with other fields On the books framework there are a lot of non-9 fields in the 9 tab. See attached. Shouldn't they be in their corresponding number tab? -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 9327] New: Database update system should provide utility function for adding sysprefs
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '15

08 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9327 Bug ID: 9327 Summary: Database update system should provide utility function for adding sysprefs Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: jcamins(a)cpbibliography.com CC: gmcharlt(a)gmail.com Depends on: 7167 Right now in order to add sysprefs we use the dbh directly. Instead the database update system should provide functions like C4::Update::Database::AddSyspref and C4::Update::Database::RemoveSyspref for adding and removing sysprefs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 9071] New: Updates adding systempreferences should verify the absence of those preferences prior to attempting to add them
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '15

08 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9071 Priority: P5 - low Change sponsored?: --- Bug ID: 9071 CC: gmcharlt(a)gmail.com Assignee: koha-bugs(a)lists.koha-community.org Summary: Updates adding systempreferences should verify the absence of those preferences prior to attempting to add them Severity: enhancement Classification: Unclassified OS: All Reporter: cnighswonger(a)foundations.edu Hardware: All Status: NEW Version: master Component: Installation and upgrade (web-based installer) Product: Koha Performing a blind INSERT of a new system preference causes the webinstaller to complain loudly. If the user happens to have DEBUG set, updatedatabase.pl bails on the error. In any case, this is generally bad behavior, and should be fixed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 9482] New: set library redirects wrong on fines
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '15

08 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9482 Bug ID: 9482 Summary: set library redirects wrong on fines Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I was on the Pay Fines page: cgi-bin/koha/members/pay.pl and went to change my library by clicking 'set library' in the top right. When I reset my library it redirected me back to cgi-bin/koha/members/pay.pl but it no longer had the patron's info on the screen. It should just redirect to circulation main or to the pay fines on the patron's record (where I was). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 9500] New: GetNormalizedISBN only ever checks the first populated ISBN field
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '15

08 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9500 Bug ID: 9500 Summary: GetNormalizedISBN only ever checks the first populated ISBN field Classification: Unclassified 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: kyle(a)bywatersolutions.com If you take a look at C4::Koha::GetNormalizedISBN you will see code like this: if ($marcflavour eq 'UNIMARC') { @fields = $record->field('010'); foreach my $field (@fields) { my $isbn = $field->subfield('a'); if ($isbn) { return _isbn_cleanup($isbn); } else { return undef; } } } If I read this correctly, if we have say two ISBNs in a record, with the first being invalid and the second being valid, GetNormalizedISBN will still return undef because it never bothers to check the second isbn! -- You are receiving this mail because: You are watching all bug changes.

1 6

[Bug 5998] New: Error "failed to submit form parsererror" and empty staged
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '15

08 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5998 Bug #: 5998 Summary: Error "failed to submit form parsererror" and empty staged Classification: Unclassified Change sponsored?: --- Product: Koha Version: rel_3_2 Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: MARC Bibliographic record staging/import AssignedTo: gmcharlt(a)gmail.com ReportedBy: dubyk(a)library.lviv.ua QAContact: koha-bugs(a)lists.koha-community.org CC: ian.walls(a)bywatersolutions.com Created attachment 3513 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=3513 marcxml, that gives error Trying stage 1 MARC record with many items. (about record: Unimarc, items in 995, Cyrillic text) File loaded ok. Choose Unimarc and push "Stage for import". After this jumps out the window with an error "failed to submit form parsererror". (Job progress: 0% and stopped) Look on "Staged MARC management": File_name Status # Bibs # Items suchasna.xml staged 0 0 (must be 1 bibs and many items) Also looked at the logs /var/log/koha - nothing that could describe the problem. Next I trying import from command line: /usr/share/koha/bin/migration_tools/bulkmarcimport.pl -b -file=/home/dubyk/Dropbox/Koha/suchasna.xml -c=UNIMARC -m=MARCXML ...all ok (imported 1 record and 198 items) -- 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 5

[Bug 7550] New: Self checkout should limit display of patron image to logged-in patron
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '15

08 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7550 Bug #: 7550 Summary: Self checkout should limit display of patron image to logged-in patron Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All URL: /cgi-bin/koha/sco/sco-patron-image.pl?cardnumber=XXXX OS/Version: All Status: NEW Severity: normal Priority: P5 - low Component: Self checkout AssignedTo: koha.sekjal(a)gmail.com ReportedBy: oleonard(a)myacpl.org QAContact: koha.sekjal(a)gmail.com The patron image display in the self-checkout takes a GET parameter from the image source, so if someone copied the image location and substituted the barcode string they could browse through all patron images: <img alt="" src="/cgi-bin/koha/sco/sco-patron-image.pl?cardnumber=XXXX"> It would offer patrons better privacy to limit that request based on the currently-logged-in user. -- 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 2

[Bug 8059] New: local use recorded on lost items
by bugzilla-daemon＠bugs.koha-community.org 07 Apr '15

07 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8059 Priority: P5 - low Change sponsored?: --- Bug ID: 8059 CC: gmcharlt(a)gmail.com Assignee: kyle.m.hall(a)gmail.com Summary: local use recorded on lost items Severity: minor Classification: Unclassified OS: All Reporter: nengard(a)gmail.com Hardware: All Status: NEW Version: master Component: Circulation Product: Koha Created attachment 9457 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=9457&action=edit checking in lost item I have the sys pref set to record local use when I check in an item that is not checked out. Now I don't know if this is a bug, but probably should be discussed. As you see in my attachment when I check in an item that was lost it records a local use and marks the item as 'found.' My question/comment is should this track a local use? There wasn't any usage here, just the returning of an item that was thought lost. It's not a big deal so I've marked this as minor, but thought I should mention that this is happening and maybe effecting stats. -- You are receiving this mail because: You are watching all bug changes.

1 1