November 2016 - Koha-bugs - lists.koha-community.org

[Bug 16734] New: getLanguages() in opac-search.pl should be called only if needed
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '25

08 Jan '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16734 Bug ID: 16734 Summary: getLanguages() in opac-search.pl should be called only if needed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: abl(a)biblos.pk.edu.pl QA Contact: testopia(a)bugs.koha-community.org There is no need to always call getLanguages() in opac/opac-search.pl (especially not if it's an actual search), it's output is used only in opac-advsearch.tt template. This patch moves it into 'if ( ... $template_type eq 'advsearch' )' block. Speed gain is rather moderate (40 - 80 msec, if the mysql server is no too busy, and the results are already in query cache), but it eliminates a lot of small DBI calls, making a further profiling of OPAC searches a bit easier. -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 15725] New: Merge permission
by bugzilla-daemon＠bugs.koha-community.org 25 Dec '24

25 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15725 Bug ID: 15725 Summary: Merge permission Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: hbraum(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be nice if Koha had a permission to limit access to the merge records option (Merge selected button) on the addbooks.pl search results page and the virtualshelves/shelves.pl page (lists). This is especially important in a consortial catalog environment where many people have cataloging permissions, but most probably shouldn't have the ability to merge records. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 17138] New: UpdateFine() modyfies existing fine records even when there is no need
by bugzilla-daemon＠bugs.koha-community.org 19 Dec '24

19 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17138 Bug ID: 17138 Summary: UpdateFine() modyfies existing fine records even when there is no need 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: abl(a)biblos.pk.edu.pl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In C4/Overdues.pm: 574: # we're updating an existing fine. Only modify if amount changed 577: if ( $data->{'amount'} != $amount ) { for some numbers (e.g. 5.60) the comparison in line 577 fails ($data->{'amount'} is decimal(28,6) i.e. a string, and $amount may be a floating point number with no exact binary representation). E.g. when the fine amounts are multiple of 0.20, it fails for the 33.3% of the amounts (on average). Depending on the fine charging settings, this may trigger unnecessary database writes (and a lot of them). If 'Fine Charging Interval' is 1 day, this has very little practical consequences (misc/cronjobs/fines.pl script is usually run once per day, and all fines need an increase anyway). But if the charging interval is longer, e.g. 7 days, in a given day amount changes only for the 1/7 of the fines (again, on average), and over 60% of the database writes would be redundant. To reproduce: 1) run misc/cronjobs/fines.pl 2) add warn "AMOUNT ".$data->{'amount'}." vs $amount"; below line 577 in C4/Overdues.pm 3) run misc/cronjobs/fines.pl again 4) you'll see some warnings like 'AMOUNT 5.600000 vs 5.6' or: dump accountlines table after step 1), run the script 2nd time, dump the table again and compare the contents - some of the records would have a different timestamp. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 17600] New: Standardize the EXPORT
by bugzilla-daemon＠bugs.koha-community.org 11 Dec '24

11 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17600 Bug ID: 17600 Summary: Standardize the EXPORT 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(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org On bug 17591 we discovered that there was something weird going on with the way we export and use subroutines/modules. I tried to standardize our EXPORT to use EXPORT_OK only. -- You are receiving this mail because: You are watching all bug changes.

1 215

[Bug 16694] New: Limit SIP2 auth by patron attribute
by bugzilla-daemon＠bugs.koha-community.org 10 Dec '24

10 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16694 Bug ID: 16694 Summary: Limit SIP2 auth by patron attribute Change sponsored?: Sponsored Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: magnus(a)libriotech.no Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org In Scandinavia "more open" (Swedish: "Meröppet", Norwegian: "Meråpent") is a hot issue at the moment. What this means is that patrons can use their card and password/PIN to lock themselves into the library even when staff is not around. Typically, this means that patrons can get access to the library building from 7 am to 11 pm, even if the library is only staffed from 8 am to 5 pm. Typically, SIP2 is used to communnicate between the "more open"-system and the ILS, specifically to authenticate the user with a username and password/PIN. Also, you want the ability to turn "more open" access on and off for patrons. An extended patron attribute with possible values of NULL/empty, 0 or 1 should serve well for this. SIP2 does not have a field for saying "this is a moreopen login", so we need a way to identify a SIP2 user as a moreopen user. My plan is to add another attribute to the login element in SIPConfig.xml to achieve this: <login id="koha" password="koha" delimiter="|" error-detect="enabled" institution="kohalibrary" patron-attribute="MEROPPET" /> "MEROPPET" is then the name of an extended patron attribute which can be set to NULL or 0 (patron should not have access to moreopen) or 1 (patron should have access). This should be flexible enough to allow other, similar schemes to use some other patron attribute. -- You are receiving this mail because: You are watching all bug changes.

1 43

[Bug 17628] New: Move bibliographic related code to Koha::Biblio
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '24

05 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17628 Bug ID: 17628 Summary: Move bibliographic related code to Koha::Biblio 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(a)bugs.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 watching all bug changes.

1 31

[Bug 17598] New: Make use of itemtypes.summary
by bugzilla-daemon＠bugs.koha-community.org 28 Nov '24

28 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17598 Bug ID: 17598 Summary: Make use of itemtypes.summary Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org There is a field called itemtypes.summary in the DB, but as far as I have been able to tell, it is not displayed anywhere. Please enlighten me if I am wrong! :-) Here is the definition in installer/data/mysql/kohastructure.sql: summary text, -- information from the summary field, may include HTML -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 16846] New: Move patron related code to Koha::Patron
by bugzilla-daemon＠bugs.koha-community.org 19 Nov '24

19 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16846 Bug ID: 16846 Summary: Move patron related code to Koha::Patron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.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 watching all bug changes.

1 70

[Bug 17318] New: Make 'Normalization rule' configurable on matchpoint definition
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '24

12 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17318 Bug ID: 17318 Summary: Make 'Normalization rule' configurable on matchpoint definition Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt(a)gmail.com Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Currently, there's a free text field on matchpoint definition, that is of no use, as the code does some default normalization no matter what you put there (se screenshot). As pointed out on 17304 and other bugs, this normalization routine is counter productive. The purpose of this bug is to introduce a way for defining the normalization rules we'd like to apply. IT will make use of bug 17302 to have a small (but useful) list of normalization routines. This could be expanded if needed, or we could even make plugins do it (that'd certaintly belong to another bug report). I don't think removing the 'feature' is a good move now, but we could consider it with broader discussion. Someone should rise it in koha-devel, meetings, etc. This will provide a way out, until we end that fine-grained discussion. -- You are receiving this mail because: You are watching all bug changes.

1 36

[Bug 16264] New: Confirm message on deleting an authority framework subfield
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '24

07 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16264 Bug ID: 16264 Summary: Confirm message on deleting an authority framework subfield Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: gmcharlt(a)gmail.com Reporter: aleishaamohia(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org Just using this as an example because it appears in many places on the intranet Is there a reason that we navigate to a new page to confirm or cancel a delete rather than just using a Javascript confirm message? A JS message would use much less code. I realise that in the past we had a rule that everything had to work without JS enabled but a lot of stuff on the intranet wouldn't work at all without JS so I'm not sure how much that applies anymore. Anyway, just wondering if these extra pages for confirm or cancelling a delete are still necessary or if we can do this via JS now :) -- You are receiving this mail because: You are watching all bug changes.

1 6