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

[Bug 21190] New: GDPR: Log successful/unsuccessful login attempts
by bugzilla-daemon＠bugs.koha-community.org 06 Aug '21

06 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21190 Bug ID: 21190 Summary: GDPR: Log successful/unsuccessful login attempts Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: vfernandes(a)keep.pt QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Under the auspices of the recently issued European legislation regarding data privacy (GDPR), the Portuguese government has issued a series of mandatory requirements, as well as general recommendations, for software applications that are implemented under the umbrella of public bodies (RCM 41/2018). Since Koha is mostly used by municipalities and universities in Portugal, some of these mandatory requirements need to be address by Koha implementers in Portugal. We believe that this requirement is also useful for the community at large. Here’s a description of the requirement. *** Requirement description *** The application MUST log successful and unsuccessful authentication operations. This is useful, for example, to detect that a user account is being hacked. *** Scope *** Applies in all cases. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 117

[Bug 19685] New: Canceling a hold from the Hold Found popup does not alert librarian about next hold
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '21

05 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19685 Bug ID: 19685 Summary: Canceling a hold from the Hold Found popup does not alert librarian about next hold Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: r.delahunty(a)arts.ac.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com While the problem where canceling a hold from the “Holds awaiting pick-up” report did not alert the librarian to additional users in the hold queue has been resolved (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17010) there remains a similar problem where the hold is cancelled from the Hold Found pop-up. The local workflow is that the user decides s/he does not want the item after all, takes it to the issue desk, and the item is scanned in. The item is found as Awaiting Collection. A simple click on Cancel Hold results in the librarian seeing a simple “item returned” dialogue box. The subsequent hold is not fulfilled, and the item is re-shelved or sent back to its home library for shelving there. We have advised staff to cancel holds from the “Holds awaiting pick-up” report until a resolution is found. Ray Delahunty University of the Arts London -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 21286] New: Advanced search for Corporate-name creates Zebra errors
by bugzilla-daemon＠bugs.koha-community.org 11 Jul '21

11 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21286 Bug ID: 21286 Summary: Advanced search for Corporate-name creates Zebra errors Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au If you're in the advanced search in the staff client, and if you're using the QueryWeightFields system preference, and if you're searching with "Corporate-name", you'll generate Zebra errors. There are a few things contributing to this problem. One is that Corporate-name is only indexed into the "word" register and not the "phrase" register. This becomes a problem with QueryWeightFields, because of the last conditional block in C4::Search::_build_weighted_query() which rewrites the search query to include $index,ext,r1, which forces a search of the "phrase" register, which causes Zebra to explode (when it doesn't use the 14=1 special attribute). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 23

[Bug 18112] New: opac-memberentry.pl doesn't contain streettype field
by bugzilla-daemon＠bugs.koha-community.org 10 Jul '21

10 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18112 Bug ID: 18112 Summary: opac-memberentry.pl doesn't contain streettype field Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: corinne.hayet(a)progilone.fr QA Contact: testopia(a)bugs.koha-community.org streettype is missing in opac-memberentry.pl, we cannot have a complete address -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 15969] New: Allow use of Template Toolkit syntax for Phone Notices
by bugzilla-daemon＠bugs.koha-community.org 09 Jul '21

09 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15969 Bug ID: 15969 Summary: Allow use of Template Toolkit syntax for Phone Notices Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org By allowing the use of Template Toolkit for generating the outgoing Talking Tech CSV files, we can give libaries more control over the data they send to Itiva. This enhancement would also make it possible to use the script for other services since the output is no longer fixed to a single format. -- You are receiving this mail because: You are watching all bug changes.

1 75

[Bug 21091] New: Move add item template JavaScript to a separate file
by bugzilla-daemon＠bugs.koha-community.org 08 Jul '21

08 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21091 Bug ID: 21091 Summary: Move add item template JavaScript to a separate file 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 I would like to modify the add item template (additem.tt) to move JavaScript from the <head> to separate files: cataloging_additem.js and cataloging_additem.inc (for defining translatable strings used in the js). -- You are receiving this mail because: You are watching all bug changes.

1 31

[Bug 21325] New: Should we still allow user and password via GET parameters?
by bugzilla-daemon＠bugs.koha-community.org 06 Jul '21

06 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21325 Bug ID: 21325 Summary: Should we still allow user and password via GET parameters? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org In testing bug 13779, I just noticed that an URL like this works: https://[your_domain]/cgi-bin/koha/opac-reserve.pl?biblionumber=[some_bibli… Obviously, we should not expose credentials like that. But it raises the question: should we allow it then? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 32

[Bug 15788] New: Split borrowers permission into create/edit
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '21

02 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15788 Bug ID: 15788 Summary: Split borrowers permission into create/edit Change sponsored?: Seeking cosponsors Product: Koha Version: master Hardware: All URL: http://devs.bywatersolutions.com/projects/patron-edit- permission/ OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Goal : Add ability to control if a staff user can create new patrons vs editing existing patrons Work to be done: 1) Add new borrowers sub-permission ‘modify’ 2) Add new borrowers sub-permission ‘create’ 3) Implement new permissions for patron editor/creator Looking for sponsors here: http://devs.bywatersolutions.com/projects/patron-edit-permission/ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 40

[Bug 16154] New: Replace CGI->param with CGI->multi_param in list context
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '21

25 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16154 Bug ID: 16154 Summary: Replace CGI->param with CGI->multi_param in list context Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: In Discussion Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 15809 Bug 15809 is now pushed, we are able to replace the occurrences of CGI->param with CGI->multi_param when needed (in list context). my @foo = $cgi->param('foo'); must be replaced with my @foo = $cgi->multi_param('foo'); and $template->param( foo => $cgi->param('foo') ); must be replaced with $template->param( foo => scalar $cgi->param('foo') ); Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15809 [Bug 15809] versions of CGI < 4.08 do not have multi_param -- You are receiving this mail because: You are watching all bug changes.

1 55

[Bug 18625] New: update borrower last seen from SIP
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '21

25 Jun '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18625 Bug ID: 18625 Summary: update borrower last seen from SIP Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: colin.campbell(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Bug 16276 added a syspref and field for last seen. In addition to the places there it should also be updated from SIP. The rationale is this in addition to the self check functions handled by sip an increasing number of packages are available which use sip to authenticate users as being valid library patrons to access various resources e.g. computer equipment, ebooks or services via a proxy. Some library patrons may only be using the library to access the internet (validated by sip) and never borrower items or sign in via the opac. The proposal is to update last seen if the borrower is a subject of a 63 (Patron Information request) from sip. We have a number of sites currently maintaining this in a patron attribute. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 36