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

[Bug 31268] New: Clearly indicate reason for failed item creation when receiving expired subscription
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '26

03 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31268 Bug ID: 31268 Summary: Clearly indicate reason for failed item creation when receiving expired subscription Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org Bug 29188 points out that while the manual says one cannot receive issues in an expired subscription, Koha is currently allowing one to do so. However, Koha *is* refusing to create an item when receiving an issue on an expired subscription. To recreate: 1 - create a subscription set to *not* create items, subscription end date in the past 2 - save subscription, confirm it shows as expired, confirm you can receive an issue anyway 3 - create a subscription set *to* create items, subscription end date in the past 4- save subscription, confirm it shows as expired, confirm you can get to the receiving page but setting the dropdown for the expected issue to "Arrived" does not cause an item edit box to appear 5- create a subscription set *to* create items, subscription end date in the future, number of issues set to 1 6- save subscription, receive 1 issue, confirm it works as intended 7- confirm subscription now shows a confusing "Subscription will expire on [subscription end date]" message even though the date isn't the problem 8- Attempt to receive another issue, confirm that now the item edit box won't pop up, as in step 4 In steps 4 and 8, the item edit box will appear if one attempts to receive a supplemental issue, but the item will refuse to save, giving an erroneous "missing required field" message. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 12141] On Display Module
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '26

03 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12141 Gretchen Maxeiner <maxeinergl(a)gcc.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maxeinergl(a)gcc.edu -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14964] Email notices will be queued for patrons with no email address and generate warnings
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '26

03 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14964 Lari Taskula <lari.taskula(a)hypernova.fi> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |lari.taskula(a)hypernova.fi --- Comment #8 from Lari Taskula <lari.taskula(a)hypernova.fi> --- (In reply to Katrin Fischer from comment #4) > Wondering... should we queue a message of the type 'print' if there is no > e-mail address? I think this might be what we do for overdues > ... but probably should be configurable - for some notices you might not > want to have a printed one Definitely should be configurable. The volume of print messages could become massive if it was a mandatory fallback, and most of the patrons, though having no email address, would have enabled email notifications. It would happen when a library, that has enabled some default messaging preferences from the patron category, doesn't systemically collect patron email addresses. If we absolutely must fallback to some type of messaging, I'd rather display them in OPAC notifications from Bug 36006. I also remember developing code for messaging preferences where one could not check email messaging preferences before providing the email address, but it seems that functionality has not yet made it into Koha. (probably Bug 18595 patch (follow-up) Disable transports if missing contact information) -- 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 03 Feb '26

03 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522 Michaela Sieber <michaela.sieber(a)kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=41439 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 15522] New interface for revamped circulation rules
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '26

03 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15522 Michaela Sieber <michaela.sieber(a)kit.edu> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |michaela.sieber(a)kit.edu --- Comment #170 from Michaela Sieber <michaela.sieber(a)kit.edu> --- Please see also Bug 41439 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 8179] Receiving multiple order lines at once
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '26

03 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8179 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |34879 Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34879 [Bug 34879] ./catalogue/getitem-ajax.pl appears to be unused -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 31612] New: koha-z3950-responder breaks if it's run in a Koha that was created before bug 28364 was applied
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '26

03 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31612 Bug ID: 31612 Summary: koha-z3950-responder breaks if it's run in a Koha that was created before bug 28364 was applied Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl The problem is the same as Bug 28364 but that it affects upgraded Koha instances rather than new Koha instances. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 41662] CSRF-vulnerability in opac-patron-consent.pl.
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '26

03 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41662 --- Comment #17 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Andreas Jonsson from comment #15) > # FIXME This is only needed for scripts not using plack > my $op = $query->param('op'); > if ( defined $op && $op =~ m{^cud-} ) { > die "Cannot use GET for this request" > if $request_method eq 'GET'; > } There's only a couple of scripts that aren't handled by Plack at this point. And if anyone is running Koha without Plack in general, they should stop, because I'm pretty sure we only recommend and support Plack-enabled Koha in the community. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41662] CSRF-vulnerability in opac-patron-consent.pl.
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '26

03 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41662 --- Comment #16 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Andreas Jonsson from comment #15) > Sorry for not paying attention to this issue, but only look att the op > parameter as this requires that this validation is made in checkauth: > > # FIXME This is only needed for scripts not using plack > my $op = $query->param('op'); > if ( defined $op && $op =~ m{^cud-} ) { > die "Cannot use GET for this request" > if $request_method eq 'GET'; > } Since this script would be served by Plack, the Plack middleware would've already caught it. This is irrelevant. > The comment suggest that this check may be removed at some point. Wouldn't > it be safer to validate the method directly? > > - if ( $op && $op eq 'cud-save' ) { > > + if ( uc $query->request_method eq 'POST' ) { Yes, but that's not the pattern that the rest of Koha uses. It's better to be consistent than "correct". Koha::Middleware::Plack catches the GET op=cud-save issue. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 41754] New: Barcode generator should be in tools
by bugzilla-daemon＠bugs.koha-community.org 03 Feb '26

03 Feb '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=41754 Bug ID: 41754 Summary: Barcode generator should be in tools Initiative type: --- Sponsorship --- status: Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Wondering if the Barcode generator should be also available in tools, and not just cataloging. I imagine many people could use the barcode generator (especially for QR codes) and not be a cataloger. Wondering if there could be a second access point via tools that doesn't require a cataloger permission? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2