April 2021 - Koha-bugs - lists.koha-community.org

[Bug 20854] New: Redirect after logout with CAS 3.0 broken
by bugzilla-daemon＠bugs.koha-community.org 25 May '21

25 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20854 Bug ID: 20854 Summary: Redirect after logout with CAS 3.0 broken Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org There has been a change in the parameters for the logout request between CAS 2.0 und CAS 3.0: Redirect URL parameter CAS 2.0: url CAS 3.0: service The CAS module used by Koha officially only support CAS 2.0, so when you logout from a CAS 3.0 server now, the redirect to Koha will be broken. See here: https://github.com/apereo/cas/blob/master/docs/cas-server-documentation/pro… Note: The url parameter defined in the former CAS 2.0 specification is not a valid parameter in CAS 3.0 anymore. CAS Servers MUST ignore given url parameters. A CAS client MAY provide the service parameter as described above, as this ensures the parameter is validated against the registered service URLs when operating in non-open mode. See 2.3.2 for details. We are using the following 'hack' to make the redirect work correctly: C4/Auth_with_cas.pm $uri =~ s/\?logout\.x=1//; # We don't want to keep triggering a logout, if we got here, the borrower is already logged out of Koha - print $query->redirect( $cas->logout_url(url => $uri)); + my $logout_url = $cas->logout_url(url => $uri); + $logout_url =~ s/url/service/; + print $query->redirect( $logout_url ); We won't have time to fix this properly, but wanted to document problem and workaround at least. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 28028] New: fix_onloan.pl broken by bug 23463
by bugzilla-daemon＠bugs.koha-community.org 25 May '21

25 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28028 Bug ID: 28028 Summary: fix_onloan.pl broken by bug 23463 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Our data migrations specialists have found that the misc/migration_tools/fix_onloan.pl script was broken by 23463. It's clear that the Koha::Items line is missing its method, but I'm also not sure that the call to store() in the loop below will actually fix the onloan field the way ModItem used it either. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 26940] New: debarred comment in borrowers table is lost on patron modifications in memberentry.pl page
by bugzilla-daemon＠bugs.koha-community.org 25 May '21

25 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26940 Bug ID: 26940 Summary: debarred comment in borrowers table is lost on patron modifications in memberentry.pl page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Patrons Assignee: didier.gautheron(a)biblibre.com Reporter: didier.gautheron(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi Debarred comment is copied in borrowers table but it's set to an empty string on a patron is modified in memberentry. In my understanding AddDebarrement and DelDebarment already properly update debarredcomment -- You are receiving this mail because: You are watching all bug changes.

1 45

[Bug 26989] New: Ensure no CR occurs in an Edifact Order message
by bugzilla-daemon＠bugs.koha-community.org 25 May '21

25 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26989 Bug ID: 26989 Summary: Ensure no CR occurs in an Edifact Order message Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org It is possible that a Carriage Return may occur in a field derived from a Koha note or shelfmark. If it persists in the message it can cause some parser software to truncate the message. Add a safeguard that no CRs persist in the generated message -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 27836] New: Document that CircControl syspref changes which library's calendar to use
by bugzilla-daemon＠bugs.koha-community.org 25 May '21

25 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27836 Bug ID: 27836 Summary: Document that CircControl syspref changes which library's calendar to use Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Currently CircControl syspref changes also which library's calendar to use when calculating opening days for example for fines. This should be documented in the syspref (now it is not). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 27827] New: The Authority type input field for new authority types should be wider
by bugzilla-daemon＠bugs.koha-community.org 25 May '21

25 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27827 Bug ID: 27827 Summary: The Authority type input field for new authority types should be wider Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: a.roussos(a)dataly.gr QA Contact: testopia(a)bugs.koha-community.org Created attachment 117470 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=117470&action=e… The 'Authority type:' input field is too narrow When adding a new authority type in the Staff client, the 'Authority type' input field is too narrow. If you enter something like "OOP_CORPUS" inside the textbox, you will have to scroll right and left inside the textbox in order to view its contents (please see the attached screenshot). This, IMHO, is a nuisance, so I'm choosing a Severity of 'minor' for this bug ("The component mostly works, but causes some irritation to users."). I suggest we increase the 'size' property of the HTML input element from 10 to 20 in order to make it twice as wide (thus allowing even the widest of entries to be displayed in their entirety without any scrolling) while the 'maxlength' property will remain at its current value of 10 since the max. number of characters allowed for an authtype in the database is 10. -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 21883] New: Show authorized value description for withdrawn in check-in
by bugzilla-daemon＠bugs.koha-community.org 25 May '21

25 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21883 Bug ID: 21883 Summary: Show authorized value description for withdrawn in check-in 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: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com During check-in (circ/returns.pl) the withdrawn information may be displayed in a message : "Item is withdrawn". Like Bug 21877 we should display the withdrawn authorized value description during check-in. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 27830] New: OPAC library list does not use AddressFormat
by bugzilla-daemon＠bugs.koha-community.org 25 May '21

25 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27830 Bug ID: 27830 Summary: OPAC library list does not use AddressFormat Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org Bug 13388 introduced the page of library info at /cgi-bin/koha/opac-library.pl. As far as I can tell, the address display on this page does not respect the AddressFormat syspref. Specifically, it displays the ZIP code after the city/state, but both the fr and de setting would display it the other way round. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 27277] New: Queued vs Enqueued
by bugzilla-daemon＠bugs.koha-community.org 25 May '21

25 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27277 Bug ID: 27277 Summary: Queued vs Enqueued Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org See bug 27109 comment 5: """ Rather than "Enqueued" I think I would prefer "Queued". Enqueued is a valid English word, according to Oxford English Dictionary (https://www.lexico.com/definition/enqueue) However, it is not something in common usage or that I have come across before except in Koha. As this one improves the display, I've signed it off. I will add a new bug for changing the term and see what others think. Testing notes: - Applied patch: applied successfully - Reviewed diff, makes sense to me """ Then comment 9 """ (In reply to David Nind from comment #5) > Rather than "Enqueued" I think I would prefer "Queued". Enqueued is a valid > English word, according to Oxford English Dictionary > (https://www.lexico.com/definition/enqueue) However, it is not something in > common usage or that I have come across before except in Koha. I love enqueue/dequeue and they come up a lot for me, but they do seem to be computing terms, so I am willing to admit that they probably should be reserved for backend systems and not displayed to users. I also love splitting hairs so... Should it be "Queued on" or "Queued at"? """ And don't forget there is also "Started on" -- You are receiving this mail because: You are watching all bug changes.

1 25

[Bug 28140] New: Accessibility: OPAC - "sort_by" select isn't labelled on search results page
by bugzilla-daemon＠bugs.koha-community.org 25 May '21

25 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28140 Bug ID: 28140 Summary: Accessibility: OPAC - "sort_by" select isn't labelled on search results page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: bolshawh(a)parliament.uk QA Contact: testopia(a)bugs.koha-community.org The <select> element used to sort search results on the OPAC search results page (opac-search.pl) isn't labelled. This makes it harder for users of screen readers and other assistive technologies to identify the purpose of the sort function. <select id="sort_by" class="resort form-control form-control-sm" name="sort_by"> should become: <label for="sort_by" class="sr-only">Sort by:</label> <select id="sort_by" class="resort form-control form-control-sm" name="sort_by"> We should add a <label> with class .sr-only to identify this to screenreaders only because the purpose of the sort function is clear from visual context. (We could use an aria-label instead of <label> but the 'first rule of ARIA' is to use native HTML where possible: "2.1 First Rule of ARIA Use If you can use a native HTML element [HTML51] or attribute with the semantics and behavior you require already built in, instead of re-purposing an element and adding an ARIA role, state or property to make it accessible, then do so." (From https://www.w3.org/TR/using-aria/#firstrule) -- You are receiving this mail because: You are watching all bug changes.

1 13