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

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

[Bug 31596] New: LDAP ACTIVE DIRECTORY with different domain suffix
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '23

18 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31596 Bug ID: 31596 Summary: LDAP ACTIVE DIRECTORY with different domain suffix Change sponsored?: --- Product: Koha Version: unspecified Hardware: Other OS: Linux Status: NEW Severity: blocker Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: hamsiah(a)interxs.com.my QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Koha version: 18.11.13.000 OS version ('uname -a'): Linux 3.16.0-6-amd64 #1 SMP Debian 3.16.57-2 (2018-07-14) x86_64 Hi, I have success connecting KOHA with ACTIVE DIRECTORY for staff. However if I want to authenticate student, login is failed due to different domain suffix. This is my working ldap-activedirectory authentication. ------------------------------------------------------------ <useldapserver>1</useldapserver> <ldapserver id="ldapserver" listenref="ldapserver"> <hostname>ldap://ldaphostname:389</hostname> <base>OU=Staf,OU=Student,OU=User,OU=uuu,DC=dc,DC=local</base> <replicate>0</replicate> <update>0</update> <auth_by_bind>1</auth_by_bind> <anonymous_bind>0</anonymous_bind> <principal_name>%s(a)uuu.edu.my</principal_name> <update_password>0</update_password> <mapping> <userid is="CN" ></userid> </mapping> </ldapserver> ------------------------------------------------------------- This config is already working smoothly. But since STUDENT's email has different suffix domain such as %s(a)student.uuu.edu.my, hence the login is failed. Is there a way to combine multiple principal_name to make this work? I have read other bugs that said multiple ldapserver is not developed. In this case, it's not multiple ldapserver cause it has the same hostname and details. Only the domain in principal_name is different. ------------------------------------------------------------- The error I got when student is logged in is: >> LDAP bind failed as kohauser MA19126: LDAP error #49: LDAP_INVALID_CREDENTIALS >> The wrong password was supplied or the SASL credentials could not be processed -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 31508] New: Authorities link in new marc fields created
by bugzilla-daemon＠bugs.koha-community.org 18 Jan '23

18 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31508 Bug ID: 31508 Summary: Authorities link in new marc fields created Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: vbovictor(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl I created a new field MARC 697 – local subject I also created a “local subjectc” authority type and then linked it to field MARC 697. I imported some records and authorities with the information into the appropriate fields. I ran the misc/link_bibs_to_authorities.pl script to link the authorities with the records information. Fields 650, 100, etc. were linked normally, but field 697 was not linked. Is this a bug in the system? Is Koha not linking newly created MARCS fields? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 29788] New: Make Koha::Item->safe_to_delete return a Koha::Result::Boolean object
by bugzilla-daemon＠bugs.koha-community.org 17 Jan '23

17 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29788 Bug ID: 29788 Summary: Make Koha::Item->safe_to_delete return a Koha::Result::Boolean object Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29746 Same as bug 29765 for the existing Koha::Item->safe_to_delete Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29746 [Bug 29746] Add a handy Koha::Result::Boolean class -- You are receiving this mail because: You are watching all bug changes.

1 39