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

[Bug 18420] New: t/dbdependent/Budgets.t fails without patron category 'S'
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '20

20 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18420 Bug ID: 18420 Summary: t/dbdependent/Budgets.t fails without patron category 'S' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: veron(a)veron.ch QA Contact: gmcharlt(a)gmail.com If no patron category 'S' is defined, t/dbdependent/Budgets.t fails. -- You are receiving this mail because: You are watching all bug changes.

1 48

[Bug 26237] New: Move translatable strings out of preferences.tt and into JavaScript files
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '20

20 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26237 Bug ID: 26237 Summary: Move translatable strings out of preferences.tt and into JavaScript files Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr, testopia(a)bugs.koha-community.org Depends on: 21156 Strings defined for translation in admin/preferences.tt can now be wrapped in the new translation function and put in the corresponding JavaScript files, ajax.js or preferences.js. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21156 [Bug 21156] Internationalization: plural forms, context, and more for JS files -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 26229] New: Move translatable strings out of categories.tt and into categories.js
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '20

20 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26229 Bug ID: 26229 Summary: Move translatable strings out of categories.tt and into categories.js Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr, testopia(a)bugs.koha-community.org Depends on: 21156 Strings defined for translation in admin/categories.tt can now be wrapped in the new translation function and put in categories.js. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21156 [Bug 21156] Internationalization: plural forms, context, and more for JS files -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 17458] New: ID of logged user is displayed when just consult an invoice (parcel.pl)
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '20

20 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17458 Bug ID: 17458 Summary: ID of logged user is displayed when just consult an invoice (parcel.pl) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org Hi, When we just consult receipt summary (parcel.pl), the ID of logged user is displayed in field "Received by" But effective receipt were done by someone else. Id of user who done receipt is logged somewhere? Regards, Marjorie -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 21259] New: Add search filters to staged imports
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21259 Bug ID: 21259 Summary: Add search filters to staged imports Change sponsored?: --- Product: Koha Version: 16.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org We can sort on the whole table, but sometimes you are just looking for a specific record in a bigger batch. A search option would be really nice. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 17849] New: Show only unpaid fees/fines in OPAC
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17849 Bug ID: 17849 Summary: Show only unpaid fees/fines in OPAC 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Currently all payments, credits, paid and unpaid fine entries are shown in the OPAC. It would be less confusing, if we only showed unpaid fines and credits. -- You are receiving this mail because: You are watching all bug changes.

1 2

[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 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