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

[Bug 6819] Don't offer cancel order links for received order lines on basket summary
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6819 Séverine Queune <severine.queune(a)bulac.fr> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 26733] New: Javascript crashes - makes all holds reservable
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26733 Bug ID: 26733 Summary: Javascript crashes - makes all holds reservable Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: rickard.lindfors(a)sh.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 111953 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=111953&action=e… JS Crash example Hello! We've just tested the new version, 20.05.04 a bit and had some problems with placing a hold in the staff interface. 1. Set On shelf holds allowed to If all unavailable to an item type. 2. Search the catalog for a book with available items with the item type above. 2. Place a hold and choose a user that can make that hold. 3. circ-patron-search-results_20.0504000.js crashes. var override_items should use a "," instead of a ";". (See picture). This crash result: the librarians can place a hold on this book, which should not be possible. Note: there is no problem in the OPAC. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 25779] New: ExcludeHolidaysFromMaxPickUpDelay has opposite effect
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25779 Bug ID: 25779 Summary: ExcludeHolidaysFromMaxPickUpDelay has opposite effect Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Holds are set to expire during holidays, although the system has been configured to not expire holds on holidays. In C4/Hold.pm this code can be found: my $expirationdate = $today->clone; $expirationdate->add(days => $max_pickup_delay); if ( C4::Context->preference("ExcludeHolidaysFromMaxPickUpDelay") ) { $expirationdate = $calendar->days_forward( dt_from_string(), $max_pickup_delay ); } However, if we look in the html-code for setting the system preference we can see that the "true" value is labelled "Ignore the calendar". <select name="pref_ExcludeHolidaysFromMaxPickUpDelay" id="pref_ExcludeHolidaysFromMaxPickUpDelay" class="preference preference-choice valid"> <option value="" selected="selected"> Use the calendar </option> <option value="1"> Ignore the calendar </option> </select> So, I believe this condition should be reversed: my $expirationdate; if ( C4::Context->preference("ExcludeHolidaysFromMaxPickUpDelay") ) { $expirationdate->add(days => $max_pickup_delay); } else { $expirationdate = $today->clone; $expirationdate = $calendar->days_forward( dt_from_string(), $max_pickup_delay ); } -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 26371] New: Prevent MARC tags from import when using Z39.50
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26371 Bug ID: 26371 Summary: Prevent MARC tags from import when using Z39.50 Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl We get brief bib records when we order from our vendor. When the item is received we overlay the brief bib with a full MARC record via Z39.50. Sometimes the incoming record has tags that we do not want in our bibs (local 9XX tags, 852, local 59x notes, etc.) We'd like a way to prevent those tags from being imported instead of having to delete them from every incoming record. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 7972] GUI for Crons
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7972 --- Comment #8 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- You are right, I missed the point of scheduling them. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 7972] GUI for Crons
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7972 --- Comment #7 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #6) > Some of our cronjob scripts are already controlled by system preferences. I > think that would be the easiest way to move on here: Schedule them all by > default for all instances, but allow libraries to configure (and turn off by > configuration) using system preferences or possibly a separate page. > > Examples would be the *LongOverdue prefs*. Could you clarify what you mean? I think Christopher and Barbara were referring to changing the time that the cronjobs run? (For instance, as a vendor, we only run /usr/share/koha/bin/cronjobs/process_message_queue.pl between certain hours so that we're not sending emails out in the middle of the night. I could see libraries wanting to do that.) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 7972] GUI for Crons
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7972 --- Comment #6 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Some of our cronjob scripts are already controlled by system preferences. I think that would be the easiest way to move on here: Schedule them all by default for all instances, but allow libraries to configure (and turn off by configuration) using system preferences or possibly a separate page. Examples would be the *LongOverdue prefs*. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 7972] GUI for Crons
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7972 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #5 from David Cook <dcook(a)prosentient.com.au> --- I don't think that this is practical. Generally speaking, cronjobs are really handled at the system administration level rather than the application level. With Koha Debian packages, there are cronjobs deployed out of the box, but they're not manageable by the Koha instance. I suppose the cronjobs could be re-engineered, at least for the Koha Debian packages, but then that becomes a logistical problem for system administrators. That being said, there is more work being done in terms of background tasks. What kind of cronjobs do people have in mind here? It could be more practical to move some functionality from cronjobs into a different kind of scheduled task. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 26304] New: Better failure message when patrons can't log into the Opac due to self check permissions
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26304 Bug ID: 26304 Summary: Better failure message when patrons can't log into the Opac due to self check permissions Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: margaret(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org If a staff member is assigned self check permissions and tries to log into the Opac it fails. This is just fine and the permission says so on the label when it is expanded. However we really really should fix the Failure message on the Opac to reflect what the real reason why the patron cannot log in. In Koha 19.11 it says: "You entered an incorrect username or password. Please try again! But note that passwords are case sensitive. Please contact a library staff member if you continue to have problems." When in reality it should say: "Your Self Checkout permission prevents the you from using any other OPAC functionality." This is a bug because (a) the patron's username and password is just fine so we're giving them the wrong error message and (b) every quarter or so I get a support ticket with this issue and that is just enough time to completely forget about the permissions pitfall. Evidently that note on the permission is insufficient warning to staff member themselves or the staff admin doling out permissions. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 8676] Show vendor name in source of acquisition
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8676 --- Comment #15 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hi Jonathan, I think this could be really nice for libraries just starting out with Koha, but could be an issue for libraries that already have a lot of data in $e (existing vendor ids, non-existing vendor ids and actual vendor names). Which means it probably should be an optional feature. We run into problems here when: - Libraries have entered the vendor's name in $e (think of libraries not using the acq module) - Libraries have values in $e that cannot be resolved as a vendor, which could lead to a data loss issue. Could we somehow allow to display the data directly in the input field, if it cannot be resolved to a value from the pull down? Maybe we could split display in the items table (display vendor name when it can be resolved, otherwise display $e) and the form? -- You are receiving this mail because: You are watching all bug changes.

1 0