June 2022 - Koha-bugs - lists.koha-community.org

[Bug 23979] New: "Account is locked" message on moremember.pl should be displayed on the "Check out" tab in addition to the "Details" tab
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '23

20 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23979 Bug ID: 23979 Summary: "Account is locked" message on moremember.pl should be displayed on the "Check out" tab in addition to the "Details" tab Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: george(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Bug 21311 removes the "This account has been locked!" message from the OPAC when a patron account has been locked because someone has attempted to log into that account with an incorrect password more than the number of times specified by the system preference FailedLoginAttempts. This means that a patron may not know that their account has been locked if someone other than themselves has attempted to hack their account. Bug 21312 adds an "Account is locked" message on the patron's "Details" tab when a patron has locked their account by logging in with an incorrect password more than the number of times specified by the system preference FailedLoginAttempts. Most public library staff access a patron's account through the "Check out" tool which takes them directly to the "Check out" tab on the patron's account rather than the "Details" tab. The "Check out" tool is, after all, the default action of the header_search input box on the Koha home page. Having the "Account is locked" message only on the "Details" tab means that when a patron comes into the library and says "I don't understand why I can't get into my account" when staff look up the patron's account through "Check out", as they normally do, they have to take the extra step of switching to the "Details" tab to find out that the "Account is locked." The "Account is locked" message on moremember.pl should be displayed on the "Check out" tab in addition to the "Details" tab. George -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 22854] New: Add separate column for administrative locked patron
by bugzilla-daemon＠bugs.koha-community.org 20 Jan '23

20 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22854 Bug ID: 22854 Summary: Add separate column for administrative locked patron Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- See bug 21336. This is now arranged by using the same column login_attempts. login_attempts > pref_value means locked login_attempts < 0 means admin lock Do we need one or even two new columns? [1] locked: regular lock (resulting from entering wrong password), boolean replacing the check attempts > pref. Note that changing the pref might lock or unlock users now. Do we want that? [2] admin_locked: administrative lock, resulting from e.g. removing GDPR consent, boolean -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 22785] New: Manage Multiple Matches when importing through Stage Marc Record Import
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '23

19 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22785 Bug ID: 22785 Summary: Manage Multiple Matches when importing through Stage Marc Record Import Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: joy(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Work to be done: On the stage-marc-import.pl screen, the wording would change from: [X] records with at least one match in catalog per matching rule "Y" To [X] records with one match in catalog per matching rule "Y" [X] records with two or more matches in catalog per matching rule "Y" On the manage-marc-import.pl?import_batch_id=#### screen, each record number that is a match would be displayed (multiple matches). The user would then be able to click to see all matches (modal/popup) and select (checkbox) which record(s) they would like to overlay. User would have the option of selecting none, one, or multiple records. - if there are items on the imported record and items are being imported then only one record could be selected - selecting multiple records would overlay the record onto each selected record - no records existing in the catalog would be merged by this tool - the default selection would be the first record found -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 123

[Bug 21924] New: Make default subfields order to correspond with MARC21 habit
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '23

19 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21924 Bug ID: 21924 Summary: Make default subfields order to correspond with MARC21 habit Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In the MARC21 specifications, there is habit to write first subfields with alphabetical codes and then subfields with numerical code. Koha do it in other way by default and we need to change the order manually very often. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 27162] New: Automatic debian/control updates (19.11.x)
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '23

19 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27162 Bug ID: 27162 Summary: Automatic debian/control updates (19.11.x) Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mtj(a)kohaaloha.com QA Contact: testopia(a)bugs.koha-community.org CC: mtj(a)kohaaloha.com Automatic updates for debian/control in 19.11.x -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 17084] New: Nightly build bot bug
by bugzilla-daemon＠bugs.koha-community.org 19 Jan '23

19 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17084 Bug ID: 17084 Summary: Nightly build bot bug Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mirko(a)abunchofthings.net QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net Things the nightly build bot says. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 149

[Bug 21472] New: Links in Additional Formats section of bib details do not work
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '23

18 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21472 Bug ID: 21472 Summary: Links in Additional Formats section of bib details do not work Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul(a)flo.org QA Contact: testopia(a)bugs.koha-community.org The links that appear under the heading Additional Formats, built using data from 776 fields, are hardcoded to be like this in the OPAC: /cgi-bin/koha/opac-search.pl?q=control-number:__________ And like this in the staff interface: /cgi-bin/koha/catalogue/search.pl?q=control-number:__________ The blanks are filled in with the contents of the 776 field, subfield $w, with any parenthesized organization code stripped. Thus, for example, a 776 field like this: 776 08 $i Online version: [...] $z 9781938168000 $w (OCoLC)895896190 Would yield a staff URL like this: /cgi-bin/koha/opac-search.pl?q=control-number:895896190 But that link won't work, at least not in our case; control numbers found in 035 $a are indexed as other-control-number, not control-number, and the organization code is not stripped when indexing. However, a link like this does retrieve the bib record with the 776 field given above: /cgi-bin/koha/catalogue/search.pl?idx=other-control-number,phr&q=(OCoLC)895896190 These links are built in /usr/share/koha/opac/htdocs/opac-tmpl/bootstrap/en/xslt/MARC21slim2OPACDetail.xsl (lines 808 ff.) and /usr/share/koha/intranet/htdocs/intranet-tmpl/prog/en/xslt/MARC21slim2intranetDetail.xsl (lines 756 ff.); for example, the latter looks like this:  <xsl:if test="marc:datafield[@tag=776]"> <span class="results_summary add_physical_form"> <span class="label">Additional physical formats: </span> <xsl:for-each select="marc:datafield[@tag=776]"> <xsl:variable name="linktext"> <xsl:choose> <xsl:when test="marc:subfield[@code='t']"> <xsl:value-of select="marc:subfield[@code='t']"/> </xsl:when> <xsl:when test="marc:subfield[@code='a']"> <xsl:value-of select="marc:subfield[@code='a']"/> </xsl:when> <xsl:otherwise> <xsl:text>No title</xsl:text> </xsl:otherwise> </xsl:choose> </xsl:variable> <xsl:if test="@ind2=8 and marc:subfield[@code='i']"> <xsl:call-template name="subfieldSelect"> <xsl:with-param name="codes">i</xsl:with-param> </xsl:call-template> <xsl:text>: </xsl:text> </xsl:if> <xsl:choose> <xsl:when test="marc:subfield[@code='w']"> <a> <xsl:attribute name="href"> <xsl:text>/cgi-bin/koha/catalogue/search.pl?q=control-number:</xsl:text> <xsl:call-template name="extractControlNumber"> <xsl:with-param name="subfieldW"> <xsl:value-of select="marc:subfield[@code='w']"/> </xsl:with-param> </xsl:call-template> </xsl:attribute> <xsl:value-of select="$linktext"/> </a> </xsl:when> <xsl:otherwise> <xsl:value-of select="$linktext"/> </xsl:otherwise> </xsl:choose> <xsl:if test="position() != last()"> <xsl:text>; </xsl:text> </xsl:if> </xsl:for-each> </span> </xsl:if> The template "extractControlNumber" extracts the control number (minus parenthesized prefix) from the value in 776 $w. Unfortunately, this template is used elsewhere so I'm not sure it's safe to change it so that it does *not* strip the parenthesized prefix. Perhaps we could add a second parameter to it that specifies whether or not to strip it, with the default set to true. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 28670] New: api/v1/patrons_holds.t is failing randomly
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '23

18 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28670 Bug ID: 28670 Summary: api/v1/patrons_holds.t is failing randomly Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com First time we get this one (Koha_Master/1700): 12:01:12 koha_1 | # Failed test 'Holds retrieved' 12:01:12 koha_1 | # at t/db_dependent/api/v1/patrons_holds.t line 56. 12:01:12 koha_1 | # Structures begin differing at: 12:01:12 koha_1 | # $got->[0]{hold_id} = '256' 12:01:12 koha_1 | # $expected->[0]{hold_id} = '255' 12:01:12 koha_1 | # Looks like you failed 1 test of 9. 12:01:12 koha_1 | 12:01:12 koha_1 | # Failed test 'list() tests' 12:01:12 koha_1 | # at t/db_dependent/api/v1/patrons_holds.t line 70. -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 29224] New: OMNIBUS: Replace the use of jQueryUI Accordion
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '23

18 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29224 Bug ID: 29224 Summary: OMNIBUS: Replace the use of jQueryUI Accordion Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Blocks: 29222 As part of Bug 29222, "OMNIBUS: Replace the use of jQueryUI," we should replace the use of the jQueryUI accordion component on the following pages with Bootstrap's Collapse component. - Administration -> Table settings - Patrons -> Patrons requesting modifications - Tools -> Notices Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29222 [Bug 29222] OMNIBUS: Replace the use of jQueryUI -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 30011] New: Upgrade jQueryUI to 1.13.1 in the OPAC and staff interface
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '23

18 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30011 Bug ID: 30011 Summary: Upgrade jQueryUI to 1.13.1 in the OPAC and staff interface Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 29115 I would like to upgrade jQueryUI to 1.13.1 everywhere. At the same time, the library will be re-compiled to get rid of unused modules like datepicker. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29115 [Bug 29115] Placing a club hold is not showing warnings when unable to place a hold -- You are receiving this mail because: You are watching all bug changes.

1 31