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

[Bug 22801] New: Advance search yr uses copydate instead of date-of-publication
by bugzilla-daemon＠bugs.koha-community.org 16 Aug '21

16 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22801 Bug ID: 22801 Summary: Advance search yr uses copydate instead of date-of-publication Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com Target Milestone: --- In advanced search with Elasticsearch the limit on years range is actually using copydate : Koha/SearchEngine/Elasticsearch/QueryBuilder.pm in _fix_limit_special_cases() : if ( $l =~ /^yr,st-numeric,ge=/ ) { my ( $start, $end ) = ( $l =~ /^yr,st-numeric,ge=(.*) and yr,st-numeric,le=(.*)$/ ); next unless defined($start) && defined($end); push @new_lim, "copydate:[$start TO $end]"; } With Zebra it uses date-of-publication and also in Koha/SearchEngine/Elasticsearch/QueryBuilder.pm : our %index_field_convert = ( (...) 'yr' => 'date-of-publication', -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 37

[Bug 17335] New: waitingreserves.pl cancel button needs simplification
by bugzilla-daemon＠bugs.koha-community.org 11 Aug '21

11 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17335 Bug ID: 17335 Summary: waitingreserves.pl cancel button needs simplification Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I would suggest that the Cancel Hold button is overly complicated and should be simplified. At the very least, this should be an option. Currently (3.22.8) it doesn't seem to matter if there is another hold or if the item is a local item or going somewhere. Its behavior doesn't differ from one button to the next. Aside from that, if this function were to be fixed, say, bug 17010, it really doesn't matter (at least to some libraries) what happens next. The behavior following the press of the button should be self evident. One could also assume that getting information as to what happens next to each hold and customizing the button is using processing time to build the page. Time which is a waste. I think that the buttons next to all the holds should just simply read "Cancel hold". If it is an issue, this should be a preference, that would eliminate any background processes building the buttons, and give a simple Cancel hold label. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 22399] New: Improve responsive behavior of the basic marc editor
by bugzilla-daemon＠bugs.koha-community.org 10 Aug '21

10 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22399 Bug ID: 22399 Summary: Improve responsive behavior of the basic marc editor Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl, testopia(a)bugs.koha-community.org Depends on: 22045 Target Milestone: --- Created attachment 85569 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=85569&action=ed… Animated gif showing the proposed style update I propose to make some markup and style changes to the MARC editor to improve its handling of smaller browser widths. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22045 [Bug 22045] Cataloging UX enhancement - Improve access to tabs -- You are receiving this mail because: You are watching all bug changes.

1 69

[Bug 23777] New: Text converted to html entity codes in cataloguing edit form
by bugzilla-daemon＠bugs.koha-community.org 07 Aug '21

07 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23777 Bug ID: 23777 Summary: Text converted to html entity codes in cataloguing edit form Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: Linux Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: bernard.scaife(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl 1. Create corporate authority record which has double-quotes: eg Fundación "La Caixa" (Madrid, Spain) 2. Edit catalogue record where 710 field under authority control. 3. Click gadget in pipe a and searcg for authority 4. Click Choose 5. Observe the catalogue record 710 field now says Fundación "La Caixa" (Madrid, Spain) The entity codes persist when record is saved and viewed elsewhere in the system. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 51

[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 23815] New: Cancel hold confirmation should display specific information
by bugzilla-daemon＠bugs.koha-community.org 05 Aug '21

05 Aug '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23815 Bug ID: 23815 Summary: Cancel hold confirmation should display specific information Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Any cancellation or deletion confirmations should display the information that is being cancelled or deleted when confirmed. request.pl uses and alert type confirmation that does not display any specific information. With items so close to each other, it would be easy enough to click on the wrong X to cancel a hold and cancel the wrong hold. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 23891] New: opac-memberentry.pl showing fields that should be supressed by PatronSelfModificationBorrowerUnwantedField
by bugzilla-daemon＠bugs.koha-community.org 22 Jul '21

22 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23891 Bug ID: 23891 Summary: opac-memberentry.pl showing fields that should be supressed by PatronSelfModificationBorrowerUnwantedField 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It seems that PatronSelfModificationBorrowerUnwantedField and PatronSelfRegistrationBorrowerMandatoryField are in conflict. There are certain pieces of information you may want when registering that you don't want a patron to modify online. For example, you will ask for the patron name when registering, but don't necessarily want them changing their names freely. Our library requires that they show an ID when they pick up their card after registration. If they legally change their name, they need to come in with an ID again to verify the change. I would suggest allowing the PatronSelfModificationBorrowerUnwantedField to have priority over the PatronSelfRegistrationBorrowerMandatoryField settings. So, if a field is listed in PatronSelfModificationBorrowerUnwantedField, it should negate the same field listed in PatronSelfRegistrationBorrowerMandatoryField. If not that, then there should be a separate field for mandatory modification fields called PatronSelfModificationBorrowerMandatoryField. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 23571] New: fines.pl may block server
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '21

16 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23571 Bug ID: 23571 Summary: fines.pl may block server Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Under certain circunstances fines.pl may block a server. 1. if syspref calculate on return 2. If koha site has a big number of overdue items 3. there are puntual high number of checkin under this circunstances koha launches several fines.pl,each for every koha checkin, that overload cpu and make koha unresponsive This actions should be desiderable 1. fines.pl on return just calculate the user account, not all users Another option is possible, block fines.pl if there is another process running.. but perhaps option 1 is faster? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 56

[Bug 22663] New: Improve usability of 'display location' pull down in news editor
by bugzilla-daemon＠bugs.koha-community.org 12 Jul '21

12 Jul '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22663 Bug ID: 22663 Summary: Improve usability of 'display location' pull down in news editor 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- At the moment with every language installed, there are new entries added to the display location pull down in the news editor: OPAC (en), OPAC (de-DE). With the possible addition of bug 22318 this list will grow quite long and might get harder to work with. I think this could be improved in different ways: 1) Only have the location in the pull down and then tabs for the different languages like we have for notices. That would also allow a quickly copy and paste between different versions to help with translating. 2) Break up the pull down into 2 pull downs: display location and language. 3) Group by content area first and then language below, so all entries of the same type are listed together. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4