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

[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

[Bug 15278] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '20

11 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 --- Comment #6 from Martin Renvoize <martin.renvoize(a)ptfs-europe.com> --- I'm certainly onboard with this.. as discussed a few times. Would be great to share the load as there's lots of notices to work through and corrections to the underlying code to go with them I've found. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15522] New interface for revamped circulation rules
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '20

11 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522 --- Comment #163 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I think there are different use cases for what you check the editor for: 1) Editing a single rule 2) Editing multiple rules: It's common that libraries have a lot (like over a 100) of rows in the current table. And if you have to change a lot of them to extend renewals because of COVID, you want something comfortable. And once you are done: 3) Checking your entries are for a set of rules (show me rules x y z for a certain category, all for a certain library... all for a certain itemtype) correct. For this use case, you will want to see "more" 4) Look up all rules applying to a certain case (like a checked out item where you wonder about how the fines are set) I think Agustin's works well for 1) and 4). But I think the editable table styl works better for 2) and 3). It's quicker and more comfortable. I think usually you will go in to edit more than one rule. I think maybe we could refine the suggested grouping of rules a bit more: - checkout/loan period related - renewal related - fine related - holds related - article requests related And reduce the need to scroll horizontally this way. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 15278] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '20

11 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 --- Comment #5 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- And if there are more people interested, it might be good to have a quick meeting mapping out the steps that need to be done before getting started. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15278] Port default slips and notices from bespoke syntax to Template Toolkit
by bugzilla-daemon＠bugs.koha-community.org 11 Nov '20

11 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15278 --- Comment #4 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- On one condition: we should accompany porting by writing up Documentation and improving the editor! -- You are receiving this mail because: You are watching all bug changes.

1 0