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

[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 31517] New: C4::Tags should use Koha::Tags objects
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '23

18 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31517 Bug ID: 31517 Summary: C4::Tags should use Koha::Tags objects Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: joonas.kylmala(a)iki.fi Reporter: joonas.kylmala(a)iki.fi QA Contact: testopia(a)bugs.koha-community.org C4::Tags module does currently a lot of raw SQL queries. We should use the Koha object methods for these instead (Koha::Tags and so on). -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 32086] New: Consistent classes for primary buttons: Patrons
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '23

18 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32086 Bug ID: 32086 Summary: Consistent classes for primary buttons: Patrons 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 CC: testopia(a)bugs.koha-community.org Depends on: 32085 As part of Bug 32067 - [OMNIBUS] Consistent classes for submit and/or primary buttons: This patch will update buttons in patron module templates so that buttons which are currently styled as primary buttons will have the the "btn btn-primary" classes. In some places, the classes have been added to buttons which were not input[type='submit'] but which should be styled as primary. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32085 [Bug 32085] Consistent classes for primary buttons: Labels -- You are receiving this mail because: You are watching all bug changes.

1 11

[Bug 32085] New: Consistent classes for primary buttons: Circulation
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '23

18 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32085 Bug ID: 32085 Summary: Consistent classes for primary buttons: Circulation 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 CC: testopia(a)bugs.koha-community.org Blocks: 32067 As part of Bug 32067 - [OMNIBUS] Consistent classes for submit and/or primary buttons: This patch will update buttons in label-creation templates so that buttons which are currently styled as primary buttons will have the the "btn btn-primary" classes. In some places, the classes have been added to buttons which were not input[type='submit'] but which should be styled as primary. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32067 [Bug 32067] [OMNIBUS] Consistent classes for submit and/or primary buttons -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 32066] New: User can get stuck on login screen
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '23

18 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32066 Bug ID: 32066 Summary: User can get stuck on login screen Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Depends on: 30588 To recreate: 1. Set the syspref TwoFactorAuthentication (enforce or enabled) 2. Configure 2FA for a patron 3. Logout 4. Authenticate but don't enter the 2FA code 5. Switch off the syspref (disabled) => Patron is stuck on the login screen (actually can access Same can happens when the patron needs to setup 2FA. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30588 [Bug 30588] Add the option to require 2FA setup on first staff login -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[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 32550] New: 'Clear on loan' link on Batch item modification doesn't untick on loan items
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '23

18 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32550 Bug ID: 32550 Summary: 'Clear on loan' link on Batch item modification doesn't untick on loan items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Steps to replicate: 1. Enter a checked-out barcode in the 'Batch item modification' page 2. Click 'Continue' 3. Notice a table is loaded displaying the on-loan item with a ticked checkbox 4. Click the 'Clear on loan' link above the table 5. Notice the on-loan item still has a ticked checkbox Notes: The 'Clear on loan' link was added in bug 10599 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15