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

[Bug 24779] New: Shibboleth login url double encodes "=" in query
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24779 Bug ID: 24779 Summary: Shibboleth login url double encodes "=" in query Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: hannah.co(a)northwestu.edu QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org login_shib_url and logout_shib use _get_return to process a url and parameters. I am seeing urls come through with the "=" between the parameter name and the query encoded to "%3D". I think this is because url encoding is done on line 214 to the whole parameter string after assembly. 214 return $uri_base_part . URI::Escape::uri_escape_utf8($uri_params_part); I believe only the query part of the parameter should be uri escaped, on line 209: 209 $uri_params_part .= $uriPiece; My installation with shibboleth login works with lines 209 and 214 changed as follows: 209 $uri_params_part .= URI::Escape::uri_escape_utf8($uriPiece); 214 return $uri_base_part . $uri_params_part; -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 22497] New: '0' width can lead to an infinite loop.
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22497 Bug ID: 22497 Summary: '0' width can lead to an infinite loop. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- > > "Aha... it's the parentheses which are the problem. They're being interpreted as > > regex metacharacters and not literal values!" > > We noticed that there seems to be an infinite loop if the template has some > or all entries with "0" in it (like in default when creating a new > template). Could this be the same cause? Sorry, I just realized that you were referring to the template rather than the layout. Yes, it would be a related problem, but a separate issue. If 'label_width' is 0, then $self->{'width'} will be 0. That means that this condition will be triggered: if (($string_width + $text_attribs->{'llx'}) > $self->{'width'}) And because $self->{'width'} is 0, then the following condition would never feasibly be triggered: if (($string_width + $text_attribs->{'llx'}) < $self->{'width'}) And this condition is the only thing that can stop the infinite loop. Really the line wrapping code looks like it would benefit from a re-write. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 7456] Itemtype codes with hyphens and spaces can cause unexpected search results
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7456 Martin Renvoize <martin.renvoize(a)ptfs-europe.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |martin.renvoize@ptfs-europe | |.com Severity|major |minor -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 21508] New: lost item phrase is repeated on pay fines page, when a patron is charged after an item is changed to lost
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '24

08 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21508 Bug ID: 21508 Summary: lost item phrase is repeated on pay fines page, when a patron is charged after an item is changed to lost Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: koha(a)univ-lyon3.fr QA Contact: testopia(a)bugs.koha-community.org The preference system WhenLostChargeReplacementFee = charge On the tab fines, pay fines (/members/pay.pl), when a patron is charged automatically because an item he has borrowed is changed to lost status, the test repeats "lost iem" twice in the column description : Lost item , Lost Item + Title -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 37042] Schema Upgrade fail at 23.06.00.049 > Bug 31503 - Change patron_consent.type
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '24

08 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37042 --- Comment #4 from Harsha <hbala(a)ou.ac.lk> --- (In reply to Martin Renvoize from comment #2) > It was added all the way back in 18.11.. I'm thinking you've somehow had it > removed.. could you elaborate as to how you've got into this position? My Koha hardware server failed, and I attempted to restore a backup of Koha version 20.11 to Koha version 24.11 on a new Ubuntu server by replacing the database. However, The error occurred during the schema upgrade process. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 21507] New: Decimal separators issues in patrons payments/fines, simplified
by bugzilla-daemon＠bugs.koha-community.org 08 Jun '24

08 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21507 Bug ID: 21507 Summary: Decimal separators issues in patrons payments/fines, simplified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor.grousset(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr This is a reboot of bug 12310 with simpler specs. kidclamp and paul_p discussed about it at the KohaCon and they would push for simpler requirements than the ones that I got at the 2018 march hackfest. And after some discussions on #koha, it seems that it should be acceptable :) == Specs == - allow only one separator, the one from CurrencyFormat - if some libraries really need supporting multiple ones, it should be another patch, don't hesitate to open a bug to talk about this - do not handle thousands separator - block form submission if the format is wrong == resources: some of the latest IRC discussions == http://irc.koha-community.org/koha/2018-10-05#i_2078324 http://irc.koha-community.org/koha/2018-10-05#i_2078377 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 37053] New: OpacHiddenItemsExceptions not taken into account when displaying values in the Advanced Search item search filters
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '24

07 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=37053 Bug ID: 37053 Summary: OpacHiddenItemsExceptions not taken into account when displaying values in the Advanced Search item search filters Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: lucy.vaux-harvey(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org If you hide a particular Item type, Collection code or Shelving Location value using OpacHiddenItems system preference it will usefully also hide that option from the Advanced Search items search filters (the tabbed display controlled by OpacAdvancedSearchTypes). However, if you make use of OpacHiddenItemsExceptions the values hidden by OpacHiddenItems remain hidden in those Advanced Search tabs for logged in patrons with a patron category that have an exception. It would be great if those patrons could see the hidden values in the tickbox filters to help with searching. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 32459] New: Add option to expire patrons who were updated in the update_patrons.pl cron job
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '24

07 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32459 Bug ID: 32459 Summary: Add option to expire patrons who were updated in the update_patrons.pl cron job Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com A common use of the update_patrons.pl is to update a child card to an adult account. It would be really helpful to be able to expire the account when the patron category is changed. The reason behind this specific situation is when patrons become "adults" libraries need to get a new application form signed, so the individual is now responsible for the account. Perhaps there can be a way to set the expiration date to the current date when those accounts are updated? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 25339] Validate biblionumber on opac-basket.pl and opac-review.pl
by bugzilla-daemon＠bugs.koha-community.org 07 Jun '24

07 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25339 David Cook <dcook(a)prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|dcook(a)prosentient.com.au |oleonard(a)myacpl.org Status|Failed QA |In Discussion --- Comment #10 from David Cook <dcook(a)prosentient.com.au> --- Sorry, Owen. I reset the Assignee a little while ago, as it seemed we'd hit a dead-end here and I didn't want folk thinking I was still working on it. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 33177] New: Use include file for subfield constraints in both authority and bibliographic frameworks
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '24

06 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33177 Bug ID: 33177 Summary: Use include file for subfield constraints in both authority and bibliographic frameworks Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: System Administration Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The subfield entry forms for authority types and MARC bibliographic frameworks are almost the same, and with a little bit of conditional logic both could use the same template -- You are receiving this mail because: You are watching all bug changes.

1 10