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

[Bug 26491] New: With Elastisticsearch search results in staff show always only 1 item even if record has multiple
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26491 Bug ID: 26491 Summary: With Elastisticsearch search results in staff show always only 1 item even if record has multiple Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de This is kind of a strange thing I just noticed while looking for a record with multiple items: With Elasticsearch active, the result list always says: 1 item... for all records. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 26105] New: Incorrect hold status shown if hold is ignored after transfer to pickup location
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26105 Bug ID: 26105 Summary: Incorrect hold status shown if hold is ignored after transfer to pickup location Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: - Have an item at Branch A - Place a hold for pickup at Branch B - Check the item in at Branch A, confirm hold and transfer - Confirm request.pl and detail.pl for your bib show item is in transit to Branch B - Confirm circulation.pl and moremember.pl for your patron show item is in transit to Branch B - Check item in at Branch B, click Ignore on the hold popup - Detail.pl shows "There is an item level hold on this item (priority = 0)." -- the expected message for an item with an item-level hold with no Found value - Request.pl shows priority of "In transit" and message of "Item waiting at Branch B since" with no waiting date - Circulation.pl and moremember.pl show no priority or status for this hold - the database shows found=T for this hold To be honest, it's hard to think of a good reason why a library would ignore a hold at the end of its transfer, but this is still confusing and worth addressing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[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 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 20783] New: Cannot embed some YouTube videos due to 403 errors
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '20

18 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20783 Bug ID: 20783 Summary: Cannot embed some YouTube videos due to 403 errors Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: juan.sieira(a)xercode.es QA Contact: testopia(a)bugs.koha-community.org Some YouTube videos cannot be played beacause of a 403 error of the videoplayback URL. Video for testing: https://www.youtube.com/watch?v=haT8g7oKnns -- You are receiving this mail because: You are watching all bug changes.

1 61

[Bug 25768] New: Add details to permission Remaining system parameters permissions (parameters_remaining_permissions)
by bugzilla-daemon＠bugs.koha-community.org 18 Oct '20

18 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25768 Bug ID: 25768 Summary: Add details to permission Remaining system parameters permissions (parameters_remaining_permissions) Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com There are no details on what this specific permission entails in the Admin area of Staff permissions. It looks like these remaining permissions are all Acquisition based, and it would be more beneficial to the library to know that when setting/adjusting permissions. If this permission is set, the patron will have access to the Acquisitions Parameters, currency, budgets, funds, EDI accounts, and EAN. However, if the patron doesn't already have acquisition permission, choosing this Admin permission doesn't appear to give any more access - just the Admin button itself. Could the permission be more specific in detail Remaining system parameters permissions (parameters_remaining_permissions) and also indicate it needs Acq permissions? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 26219] New: "Display in OPAC" option not working for patron attributes
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '20

17 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26219 Bug ID: 26219 Summary: "Display in OPAC" option not working for patron attributes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When adding patron attributes, there is an option: Check to display this attribute on a patron's details page in the OPAC. But when checked, the option will still not show up :( -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 26396] New: Hide toolbar and actions buttons from display when printing OPAC lists
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '20

17 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26396 Bug ID: 26396 Summary: Hide toolbar and actions buttons from display when printing OPAC lists 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org We should hide the toolbar and action buttons from display when printing OPAC lists, they are not very useful on the printed page -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 26568] New: Adding branchcode to PatronSelfRegistrationBorrowerUnwantedField causes internal server errors
by bugzilla-daemon＠bugs.koha-community.org 17 Oct '20

17 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26568 Bug ID: 26568 Summary: Adding branchcode to PatronSelfRegistrationBorrowerUnwantedField causes internal server errors Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: -Turn on self registration. -Add branchcode to PatronSelfRegistrationBorrowerUnwantedField -Try to self register -kabloom Users should not be allowed to do this, or we should at least warn them that it is a bad idea. -- You are receiving this mail because: You are watching all bug changes.

1 2