September 2018 - Koha-bugs - lists.koha-community.org

[Bug 19173] New: Make OPAC online payments pluggable
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '18

28 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19173 Bug ID: 19173 Summary: Make OPAC online payments pluggable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org While PayPal is fairly universally used worldwide, there is a plethora of online payment system that are far more localized, servicing a single country ( e.g. Bug 18968 ) or even a single city! Instead of adding support for each and every one of these payment options directly into Koha, it makes more sense to add the ability to create online payment plugins. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 21321] New: Use marc field 264 (when exists) to get (and show) information about place/name/date of production
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '18

28 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21321 Bug ID: 21321 Summary: Use marc field 264 (when exists) to get (and show) information about place/name/date of production Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: theod(a)lib.auth.gr QA Contact: testopia(a)bugs.koha-community.org The use of Marc field 264 (instead of 260) is currently promoted very much by LC because it is more flexible and versatile (also because it used by RDA). Many records downloaded from Library of Congress nowadays have all the place/name/date of production information only in 264. Koha must take this into account when storing such information in various database tables (and consequently when displaying it in UI tables). To give an example workararound scenario (maybe not the best, I'm just thinking out loud): one should check the presence of 264 and if found, it's data should take precedence when populating ie biblio.copyrightdate. If not, the current functionality (that uses 260) can still be used. This must be repeated for all new and modified bibs. This implies changes to core Koha structure, so a relevant discussion might be required beforehand... ps. Having said that, maybe the (gradual) use of biblio_metadata in all UI tables might give administrators the flexibility to be able to choose one marc field over the other in the UI tables for their installations, but at least the issue of this new field -and it's implications- must be known to the community... After all we will all come across it sooner or later! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 21344] New: C4::Biblio::MungeMarcPrice doesn't appear to be used anywhere
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '18

28 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21344 Bug ID: 21344 Summary: C4::Biblio::MungeMarcPrice doesn't appear to be used anywhere Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Whilst QAing bug 12310 I came accross the MungeMarcPrice routine inside C4::Biblio. This method does not appear to be called from anywhere in the current codebase and as such can likely be removed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 21394] New: after hold is put into place, can not check out to patron and hold can not be removed
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '18

28 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21394 Bug ID: 21394 Summary: after hold is put into place, can not check out to patron and hold can not be removed Change sponsored?: --- Product: Koha Version: 18.05 Hardware: PC OS: Windows Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: kmadden(a)oaklynschool.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com once Hold is confirmed and I try to check it out to a student, a message pops up saying software error 'duplicate id' at that point I can't remove hold in any of the different screens, the book seems to be locked and can no longer be checked out, removed or anything. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 21400] New: Cronjobs: processes exited with return code 1
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '18

28 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21400 Bug ID: 21400 Summary: Cronjobs: processes exited with return code 1 Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: costalc(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz I have recently updated Koha to 18.05. From this moment on, two emails are sent from Debian's cronjob system with these msg: run-parts: /etc/cron.weekly/koha-common exited with return code 1 run-parts: /etc/cron.hourly/koha-common exited with return code 1 Weekly: cleanup_databases.pl Hourly: process_message_queue.pl cleanup_databases.pl runs daily too, together with other scripts, but no email is sent. Well, has anybody experience or suggestion about this? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 20980] New: Manual credit offsets are stored as debits
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '18

27 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20980 Bug ID: 20980 Summary: Manual credit offsets are stored as debits Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org mancredit.pl calls C4::Accounts::manualinvoice, which records debits. This leads to: - account_offsets.type = 'Manual Debit' - account_offsets.credit_id = NULL - account_offsets.debit_id = accountlines_id So we need to: - Add 'Manual Credit' offset type - Make sure accountlines_id is stored in credit_id column instead of debit_id - Fix existing offsets. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 36

[Bug 20265] New: Add syspref to hide news published date
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '18

27 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20265 Bug ID: 20265 Summary: Add syspref to hide news published date Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dilan(a)calyx.net.au QA Contact: testopia(a)bugs.koha-community.org We suppress the display of the published date of news items on client OPACs with some custom CSS code at present in opacusercss. It would be nice to instead have a syspref to toggle this feature on and off in Koha for those who use it and those who would prefer not to. -- You are receiving this mail because: You are watching all bug changes.

1 20

[Bug 19617] New: Development - Allow partial writeoff
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '18

27 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19617 Bug ID: 19617 Summary: Development - Allow partial writeoff Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jesse(a)bywatersolutions.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Add “Write off selected” button -- You are receiving this mail because: You are watching all bug changes.

1 22

[Bug 18405] New: Self checkout: Fix broken silent printing
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '18

27 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18405 Bug ID: 18405 Summary: Self checkout: Fix broken silent printing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org Fix broken 'silent printing' (without printer dialog) in self checkout. To reproduce: Set up silent printing to slip printers as described in: https://wiki.koha-community.org/wiki/Setting_up_slip_printer_to_print_silen… Verify that it works for check-outs in staff client. Verify that it does not work in Self checkout. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 17378] New: Add ability to specify maximum number of items per record
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '18

26 Oct '18

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17378 Bug ID: 17378 Summary: Add ability to specify maximum number of items per record Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Some libraries want to be able to specify a hard limit on the number of items a record can have. It would be nice to have this set per record type, but since most libraries use item level itemtypes, that would make it confusing and non-intuitive. The simplest and most straight forward approach would just be to have a system preference. Koha should then just report that it failed to create an item if the librarian has hit the upper limit specified in the system preference. -- You are receiving this mail because: You are watching all bug changes.

1 12