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

[Bug 11239] New: show hour of due date in history circulation
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '15

08 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11239 Bug ID: 11239 Summary: show hour of due date in history circulation Change sponsored?: --- Product: Koha Version: 3.12 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 22887 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=22887&action=edit checkout_history It will be fine to see in history circulation hour of a checkout and of due date. We can specify now in 3.12 an hour when we choose a due date but the hour do not display in history circulation. We should have the same display as checkout history (see image). Thanks Marjorie -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 10

[Bug 12344] New: Multi transport types for issues and checkins
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '15

08 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12344 Bug ID: 12344 Summary: Multi transport types for issues and checkins Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: benjamin.rokseth(a)kul.oslo.kommune.no QA Contact: testopia(a)bugs.koha-community.org This bug relates to bug #9016 - multi transport types already pushed to master (3.16). If a patron has enabled notice for checkin/checkout other than email, the message transport type (e.g. sms) is ignored in the notice generation. The affected method is C4::Circulation::SendCirculationAlert Generation of notice (C4::Letters::GetPreparedLetter) is done before the check for borrower's chosen transport types -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[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 11926] New: Render community koha statistic usages
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '15

08 Apr '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11926 Bug ID: 11926 Summary: Render community koha statistic usages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Websites, Mailing Lists, etc Assignee: wizzyrea(a)gmail.com Reporter: claire.hernandez(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org http://wiki.koha-community.org/wiki/KohaUsageStat_RFC -- You are receiving this mail because: You are watching all bug changes.

1 67

[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