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

[Bug 14708] The patron set as the anonymous patron should not be deletable
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '20

12 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14708 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |26984 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26984 [Bug 26984] Tests are failing if AnonymousPatron is configured -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 11983] Code to select patrons to purge needs to be centralized (use of filter_by)
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '20

12 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11983 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_20_11_target |rel_21_05_candidate -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14242] Use ISBN-field to fill out purchase suggestions (using an Ajax-request)
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '20

12 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14242 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_20_11_target |rel_21_05_candidate -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 5501] Improve the 'do not notify' option
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '20

12 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=5501 Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords|rel_20_11_target | -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 25897] New: Inventory table call number sort should use cn_sort value
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '20

12 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25897 Bug ID: 25897 Summary: Inventory table call number sort should use cn_sort value Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Given items with barcodes like: B 29 V55 1998 B29 .C55 2008 B29 .L24 1983 B29 .L264 1998 B29 .P666 2004 The correct sort order should be: B29 .C55 2008 B29 .L24 1983 B29 .L264 1998 B29 .P666 2004 B 29 V55 1998 But instead it sorts in the order supplied first -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 12446] Enable an adult to have a guarantor
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '20

12 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12446 --- Comment #142 from Jonathan Druart <jonathan.druart(a)bugs.koha-community.org> --- (In reply to Katrin Fischer from comment #138) > (In reply to David Cook from comment #137) > > (In reply to Jonathan Druart from comment #135) > > > It's coming from the default value in DB, why did you default to 0? I think > > > it should default to 1. > > > > I think defaulting to 1 would be logical, but that would also be a change in > > system behaviour, since previously only patron categories C and P could be > > guaranteed it seems. > > > > Maybe it's a case where the default should be 1, but we set it to 0 for > > non-C and non-P patrons when doing a database update... > > But that's exactly what this patch does: > $dbh->do("UPDATE categories SET canbeguarantee = 1 WHERE category_type = 'P' > OR category_type = 'C'"); > > Jonathan, do you have neither P nor C categories maybe? Maybe we should hide > the option then intead. > > Note: with the normal sample data that should be working. On a new install (reset_all so sample data): /cgi-bin/koha/members/moremember.pl?borrowernumber=5 With the patch: Click "Add guarantee" and get "Cannot add patron There are no patron categories defined. Please add a patron category." Without the patch, on master: Click "Add guarantee" and get the "add patron form" /members/memberentry.pl?op=add&guarantor_id=5&category_type=C -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12446] Enable an adult to have a guarantor
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '20

11 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12446 --- Comment #141 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #140) > Hm ok, other way aorund. But I think the more common case is that you'd want > 0 not 1 (no guarantors as default) - so I am not sure why we should change > the default on the table? Ah that's an interesting perspective. I hadn't thought of that. I was thinking how for new installs we would want to allow guarantors by default. That said, we actually only have 1 out of 100 libraries who have adults guaranteeing other adults. Yeah I withdraw my earlier remarks. I think it's probably fine the way it is now then. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12446] Enable an adult to have a guarantor
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '20

11 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12446 --- Comment #140 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Hm ok, other way aorund. But I think the more common case is that you'd want 0 not 1 (no guarantors as default) - so I am not sure why we should change the default on the table? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 23640] New: L1 cache too long in SIP Server
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '20

11 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23640 Bug ID: 23640 Summary: L1 cache too long in SIP Server Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com Both plack.psgi and rebuild_zebra.pl run Koha::Caches->flush_L1_caches() to periodically flush the L1 cache. The SIP server is another persistent process like those, but it currently has no functionality for flushing the L1 cache. If I understand the code correctly, it'll fetch from the L2 cache (e.g. memcached) once and then keep it there for the life of the master process. I'm not very familiar with the SIP protocol, so I don't know the best place to flush the L1 cache off the top of my head. Perhaps we should run Koha::Caches->flush_L1_caches() at the start of C4::SIP::SIPServer::process_request for every connection, or in C4::SIP::SIPServer::sip_protocol_loop or C4::SIP::SIPServer::read_request. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 53

[Bug 12446] Enable an adult to have a guarantor
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '20

11 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12446 --- Comment #139 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Katrin Fischer from comment #138) > (In reply to David Cook from comment #137) > > (In reply to Jonathan Druart from comment #135) > > > It's coming from the default value in DB, why did you default to 0? I think > > > it should default to 1. > > > > I think defaulting to 1 would be logical, but that would also be a change in > > system behaviour, since previously only patron categories C and P could be > > guaranteed it seems. > > > > Maybe it's a case where the default should be 1, but we set it to 0 for > > non-C and non-P patrons when doing a database update... > > But that's exactly what this patch does: > $dbh->do("UPDATE categories SET canbeguarantee = 1 WHERE category_type = 'P' > OR category_type = 'C'"); > No, that does the opposite of what I describe. I'm saying that the schema default should be 1 but then there should be a update patch to do the following: $dbh->do("UPDATE categories SET canbeguarantee = 0 WHERE category_type NOT IN ('P','C'); It's a subtle but significant difference. -- You are receiving this mail because: You are watching all bug changes.

1 0