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

[Bug 28199] New: MARC framework CSV and ODS import incomplete or corrupted - part 2
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28199 Bug ID: 28199 Summary: MARC framework CSV and ODS import incomplete or corrupted - part 2 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: victor(a)tuxayo.net QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Test plan 1 1. Export default MARC framework in CSV 2. Open the .csv with LibreOffice and save it 3. Create a new framework 4. import the CSV 5. See MARC structure of the new framework 6. Tags are missing the trailing zeros (10 instead of 010) 7. View subfields of tag 10/010 8. Compare with default framework 9. Subfields are missing note, why does on the default framework, these two URLs don't yield the same result? /koha/admin/marc_subfields_structure.pl?tagfield=010&frameworkcode= /koha/admin/marc_subfields_structure.pl?tagfield=10&frameworkcode=3 It would also make sense that 10 doesn't yield anything. 10. Same with 031/31 default framework still has different output for 31 and 031 Test plan 2 1. Export default MARC framework in .ods 2. Open the .ods with LibreOffice 3. Save it 4. Create a new framework 5. import the .ods 6. See MARC structure of the new framework 7. View subfield of tag 010 8. Compare with default framework 9. See Also: 4, and Link:4 have appeared (the code of my new framework code is 4) Testing notes: Tags with a lot or diverse subfields: 010 100 240 995 031 110 600 700 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 22462] New: Crash in patron card printing
by bugzilla-daemon＠bugs.koha-community.org 10 Jun '24

10 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22462 Bug ID: 22462 Summary: Crash in patron card printing Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: christian.stelzenmueller(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Patron card printing: Layout: the entered text in a text field is longer then the possible page height, page width, card height and card width in the template. Result: when running a batch, the created pdf can't be opened, and Koha doesn't respond. It also seems to end in an infinite loop. It also happens if all values in the template are saved with the default values "0". Template: page height: 50 mm page width: 20 mm card heigh: 50 mmm card width: 20 mm Layout: Textfield Text: Libraries are great -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[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 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 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 20819] New: GDPR: Add a consent field for processing personal data
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '24

06 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20819 Bug ID: 20819 Summary: GDPR: Add a consent field for processing personal data Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com See 18081 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 106

[Bug 29621] New: Add link for Lists on opac-detail.pl
by bugzilla-daemon＠bugs.koha-community.org 06 Jun '24

06 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29621 Bug ID: 29621 Summary: Add link for Lists on opac-detail.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org When logged into the OPAC and viewing a results list of titles on opac-search.pl it is possible to see if a title is contained in a List. The link allows the user to click on it to get to the contents of the List. It would be helpful if the link for the List was also displayed on opac-detail.pl so the user could get to the results of the List from that page as well. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 26299] New: Help text for OPAC SMS number should be less North American-centric
by bugzilla-daemon＠bugs.koha-community.org 04 Jun '24

04 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26299 Bug ID: 26299 Summary: Help text for OPAC SMS number should be less North American-centric Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, the help text on opac-messaging.pl is "Please enter numbers only. (123) 456-7890 would be entered as 1234567890." The first style is a North American style, which looks strange to people from other countries like Australia where we frequently format non-mobile phone numbers like 02 5555 5555 or mobile numbers like 0455 555 555. We should use a more generic style like we do on memberentry.pl when we say "SMS number should be in the format 1234567890 or +11234567890" -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 26130] New: opacbookbag 'Cart' confuses patrons - add optional name alternatives?
by bugzilla-daemon＠bugs.koha-community.org 03 Jun '24

03 Jun '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26130 Bug ID: 26130 Summary: opacbookbag 'Cart' confuses patrons - add optional name alternatives? Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: eb(a)efdss.org QA Contact: testopia(a)bugs.koha-community.org This is in reference to the 'Cart' - short term list making facility in the OPAC. It is useful for making lists, to download a bibliography or to print out, or e-mail. But especially now that our building is closed, patrons are thinking that it's a way to order materials (similar to holds, which we don't use). 'Cart' has transactional implications - people are used to seeing it in online shopping sites. If you put something into a cart and finish the ordering process, you expect to receive it. While 'Cart' may work in some libraries, it doesn't work everywhere. It's also ambiguous with cart used elsewhere in Koha. Would it be possible to either have a short pull down menu of names for this feature in the opacbookbag setting, or the ability in System Preferences to name it ourselves, or, change the name to something more logical. Some ideas: 'My List' 'Temporary List' 'My Shelf' and whatever happened to 'Book Bag'? -- You are receiving this mail because: You are watching all bug changes.

1 19