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

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

24 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 24 May '21

24 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 24 May '21

24 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 14300] siplogs do not record process IDs
by bugzilla-daemon＠bugs.koha-community.org 24 May '21

24 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14300 Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |RESOLVED Resolution|--- |FIXED CC| |andrew(a)bywatersolutions.com --- Comment #8 from Andrew Fuerste-Henry <andrew(a)bywatersolutions.com> --- Enhancement, not backported to 20.05 -- You are receiving this mail because: You are watching all bug changes.

1 0

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

24 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 24 May '21

24 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 24 May '21

24 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 24 May '21

24 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

[Bug 27125] New: Show authority type for UNIMARC in authority search result display
by bugzilla-daemon＠bugs.koha-community.org 24 May '21

24 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27125 Bug ID: 27125 Summary: Show authority type for UNIMARC in authority search result display Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Bug 12533 added authority type in authority search result display. But it does not work for UNIMARC, due to : https://git.koha-community.org/Koha-community/Koha/src/commit/be9f64b638335… I propose to use result->{authtype} -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 27695] New: Fix style of messages on Elasticsearch configuration page
by bugzilla-daemon＠bugs.koha-community.org 24 May '21

24 May '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27695 Bug ID: 27695 Summary: Fix style of messages on Elasticsearch configuration page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org There some error messages on the Elasticsearch configuration page which are unstyled because they're given a class ("error") which doesn't exist in the CSS. There is also a message which I think should be styled as a note since it contains instructions which are always present. -- You are receiving this mail because: You are watching all bug changes.

1 25