July 2020 - Koha-bugs - lists.koha-community.org

[Bug 15765] New: Request to replace patron number list by patron barcode list
by bugzilla-daemon＠bugs.koha-community.org 25 Jan '23

25 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15765 Bug ID: 15765 Summary: Request to replace patron number list by patron barcode list Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: Heinrich.Hartl(a)email.de QA Contact: testopia(a)bugs.koha-community.org Change request: Substitute patron barcodes for patron numbers Patron card creator is working with something called a batch. A batch is a list of patron numbers where patron number is the koha internal index of a patron. Unfortunately the patron number is to my knowledge a patron property that is not known elsewhere. E.g. it is not shown when displaying patron details. But even in the patron search part of patron card creator that number is not shown. In the patron search we see e.g. name and barcode of the patron. Patron barcodes are familiar and found in many reports, in patron import and in patron displays. I suggest to replace the list of patron numbers by a list of patron barcodes. Patron barcodes are also unique identifers of patrons, an unambigous index into the borrowers table. An entered barcode not necessarily identifies an existing patron. However an entered patron number is not more reliable since a patron may have been deleted or may not be existent. -- You are receiving this mail because: You are watching all bug changes.

1 7

[Bug 20621] New: Add ability for Koha::Object objects to update themselves with database generated value automatically
by bugzilla-daemon＠bugs.koha-community.org 24 Jan '23

24 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20621 Bug ID: 20621 Summary: Add ability for Koha::Object objects to update themselves with database generated value automatically Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Koha objects should, on store() update themselves from the db if the database creates any of the columns. That way we don't have to call discard_changes() manually. This patch has no particular use yet, but I wanted to put it here for posterity. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 25441] New: Improve columns.def by adding more descriptions
by bugzilla-daemon＠bugs.koha-community.org 24 Jan '23

24 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25441 Bug ID: 25441 Summary: Improve columns.def by adding more descriptions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org I've noticed in training lately that we don't have descriptions for some of the fields shown in guided reports through columns.def. Maybe time for an update there! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 25640] New: [OMNIBUS] Ubuntu 20.04 support
by bugzilla-daemon＠bugs.koha-community.org 24 Jan '23

24 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25640 Bug ID: 25640 Summary: [OMNIBUS] Ubuntu 20.04 support Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

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