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

[Bug 11889] Disown a list
by bugzilla-daemon＠bugs.koha-community.org 14 May '20

14 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11889 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #39 from David Cook <dcook(a)prosentient.com.au> --- (In reply to kholt from comment #4) > It would be great to be able to keep public lists. We had this problem when > the staff person who maintained our Newbery Awards list retired and her > staff account was deleted. A system administrator should be able to > transfer ownership of a list so that it can continue to be added to. I 100% agree. We've had someone retire and we need to change the owner of the list. As a vendor, usually I would just do a backend database update to do this, but I don't have remote access to this Koha, so that's a problem. I've opened an issue specifically about this topic: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25498 I'm not planning on working on this right now, but maybe someone else will. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 10337] Add a script to insert all sample data automatically
by bugzilla-daemon＠bugs.koha-community.org 14 May '20

14 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10337 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook(a)prosentient.com.au --- Comment #16 from David Cook <dcook(a)prosentient.com.au> --- Should this script be removed now that we use misc4dev? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25053] New: PatronSelfRegistrationExpireTemporaryAccountsDelay system preference is unclear
by bugzilla-daemon＠bugs.koha-community.org 14 May '20

14 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25053 Bug ID: 25053 Summary: PatronSelfRegistrationExpireTemporaryAccountsDelay system preference is unclear Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We've got two methods for automatically deleting self-reg patrons. The first deletes any patron who is still in the self-reg category more than X days past account creation. The second deletes any self-reg patron who has not verified their account via email with X days of account creation. The syspref PatronSelfRegistrationExpireTemporaryAccountsDelay deals with that first deletion method. It gets used in C4::Members::DeleteExpiredOpacRegistrations if the --del-exp-selfreg flag is set in cleanup_database.pl. This sub does not check whether or not the patron has verified via the verification email. As such, it's confusing that the syspref text says "Delete patrons registered via the OPAC, but not yet verified after X days." I suggest changing this wording to "Delete patrons still in the category indicated by PatronSelfRegistrationDefaultCategory X days after account creation." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 20370] Misleading comment for bcrypt - #encrypt it; Instead it should be #hash it
by bugzilla-daemon＠bugs.koha-community.org 14 May '20

14 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20370 Lucas Gass <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Pushed to stable |Pushed to oldstable CC| |lucas(a)bywatersolutions.com --- Comment #6 from Lucas Gass <lucas(a)bywatersolutions.com> --- backported to 19.05.x for 19.05.11 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 25008] New: Koha::RecordProcessor->options doesn't refresh the filters
by bugzilla-daemon＠bugs.koha-community.org 14 May '20

14 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25008 Bug ID: 25008 Summary: Koha::RecordProcessor->options doesn't refresh the filters Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org On testing something in opac-showmarc.pl I noticed it wasn't applying the ViewPolicy filter! And it seems the way the record processor is used is to blame. I plan to submit a fix for opac-showmarc.pl but thought it was worth filing a bug against Koha::RecordProcessor. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 34

[Bug 25038] New: OPAC reading history checkouts and on-site tabs not working
by bugzilla-daemon＠bugs.koha-community.org 13 May '20

13 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25038 Bug ID: 25038 Summary: OPAC reading history checkouts and on-site tabs not working Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lari.taskula(a)hypernova.fi QA Contact: testopia(a)bugs.koha-community.org OPAC reading history table has three tabs for different checkout types: All, Checkouts, On-site checkouts. However, all of your checkouts are visible every tab regardless of checkout type. To reproduce: 1. Enable OnSiteCheckouts system preference 2. Perform two checkouts: one normal checkout, one on-site checkout 3. Go to OPAC /cgi-bin/koha/opac-readingrecord.pl 4. Observe your checkouts all are visible in every tab (All, Checkouts, On-site checkouts) -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 24966] New: Fix calls to maybe_add where method call does not return a value
by bugzilla-daemon＠bugs.koha-community.org 13 May '20

13 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24966 Bug ID: 24966 Summary: Fix calls to maybe_add where method call does not return a value Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com For reasons unknown to me, a call like: -- $resp .= maybe_add( FID_CALL_NUMBER, $item->call_number, $server ); -- will not work as expected if the item has no callnumber. One would expect the parameters to the subroutine to be: 'CY', under, and a SIPServer object. What is actually received is: 'CY', and a SIPServer object. We ingest the parameters like so: -- sub maybe_add { my ($fid, $value, $server) = @_; -- So, what happens is $value is populated with the server object! This can cause bad output like this: -- OUTPUT MSG: '101YNN20200324 063701AOBPL|AB32503201584185|AQBPL|AJCat /|CK001|CRn|CSJ 636.8 CLU|CYC4::SIP::SIPServer=HASH(0x1ea0e58)|DAC4::SIP::SIPServer=HASH(0x1ea0e58)|'--- I do not know why this is happening, but there are a couple solutions: 1) Move the $server parameter to be the first parameter of the subroutine call 2) Check the value of $value and swap $value and $server if it is the server object. I will write a patch implementing the latter solution, as it is a two line change, versus a many line change for the former. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 33

[Bug 25050] New: Elasticsearch - authority indexing depends on mapping order
by bugzilla-daemon＠bugs.koha-community.org 13 May '20

13 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25050 Bug ID: 25050 Summary: Elasticsearch - authority indexing depends on mapping order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com There is an assumption in the ES code that match-heading mappings will appear in a specified portion of the mappings array. Certain mappings setups will not meet this assumption. We need to move our searching up one level -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 24266] New: Noisy error in reconcile_balances.pl
by bugzilla-daemon＠bugs.koha-community.org 13 May '20

13 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24266 Bug ID: 24266 Summary: Noisy error in reconcile_balances.pl Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Cron <instance-koha@kohaMain> $KOHA_CRON_PATH/reconcile_balances.pl --verbose Gives this message when run: SQL::Abstract::puke(): [SQL::Abstract::__ANON__] Fatal: SQL::Abstract before v1.75 used to generate incorrect SQL when the -IN operator was given an undef-containing list: !!!AUDIT YOUR CODE AND DATA!!! (the upcoming Data::Query-based version of SQL::Abstract will emit the logically correct SQL instead of raising this exception) at /usr/share/koha/lib/Koha/Objects.pm line 209 It would be nice if this wouldn't happen, so that cron doesn't send mails about this error. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 25095] New: Remove warn left in FeePayment.pm
by bugzilla-daemon＠bugs.koha-community.org 13 May '20

13 May '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25095 Bug ID: 25095 Summary: Remove warn left in FeePayment.pm 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 It appears that a debugging statement was accidentally left in FeePayment.pm by bug 5605. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14