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

[Bug 25968] New: Make logs sort by date descending as a default
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '22

02 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25968 Bug ID: 25968 Summary: Make logs sort by date descending as a default Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org It would be helpful to have the logs sort by date descending so that you can view the newest items at the top of the page rather than having to scroll to the bottom. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 18

[Bug 27809] New: Make entries from 'modification log' tab in patron record sort by date descending as a default
by bugzilla-daemon＠bugs.koha-community.org 02 Jul '22

02 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27809 Bug ID: 27809 Summary: Make entries from 'modification log' tab in patron record sort by date descending as a default Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be helpful to have the entries displayed from the 'modification log' tab in the patron record sort by date descending as the default so that staff can view the newest changes at the top of the page rather than having to scroll to the bottom. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 31091] New: Format grouping in record details
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '22

01 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31091 Bug ID: 31091 Summary: Format grouping in record details Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be great if details.pl had the option to organize holdings into tabs of similar formats. Why? Wouldn't it be nice if you could combine your formats into one record, and get a single result on a title rather than multiple results? How would that help? A patron could see all the formats available on the details page. Then what? Then perhaps we could develop the hold requests to limit the hold to some or all of the available formats within that record. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 31088] New: Primary contact method enhancements
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '22

01 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31088 Bug ID: 31088 Summary: Primary contact method enhancements Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I am loving the new primary contact method setting in the patron record. I have a couple enhancement requests for this: 1) Have the patronbriefinfo panel on the left just show the primary contact info (the actual info, not the choice). The other info would still be available in the patron details. 2) Instead of showing the setting choice on the patron details, highlight the preferred info. No need to take up more screen real estate. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 30438] New: Add select all/clear buttons to invoices.tt open and closed tables
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '22

01 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30438 Bug ID: 30438 Summary: Add select all/clear buttons to invoices.tt open and closed tables Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some librarians would find it handy to have "Select all" and "Clear all" buttons on the on invoices.tt which selected, or cleared, each of the checkboxes for open or closed invoices. This would include sepearate select all/clear all buttons for the open and closed invoice tables -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 12758] Failure when loading or parsing XSLT stylesheets over HTTPS
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '22

01 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12758 --- Comment #19 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- So let me stick to the original partial approach and only fix the https ref at the file level -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 12758] Failure when loading or parsing XSLT stylesheets over HTTPS
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '22

01 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12758 --- Comment #18 from Marcel de Rooy <m.de.rooy(a)rijksmuseum.nl> --- My plan was somehting like this (unfinished on itself): Still had to set the flag when I found a https ref. And check for commented refs. But this is just way too much imo. sub _convert_https { my ( $self, $code, $key, $params ) = @_; my $level = $params->{level} // 0; # to limit recursion level if( $level > $self->max_recursion_level ) { die; #FIXME Exception } # Find refs and resolve recursively my ( $href, $tmp_name, $new_code, $flag, @replaces, $changed ); while( $code =~ /<(?:xsl):(?:import|include)\s*href\s*=\s*['"]([^'"]+)['"]/gcs ) { $href = $1; if( $include_cache->{$href} ) { $new_code = $include_cache->{$href}; $changed = 1; } else { $new_code = $self->_get_code( $href ); ( $new_code, $flag ) = $self->_convert_https( $new_code, $href, { level => $level + 1 } ); $changed = 1 if $flag; } next unless $changed; $tmpname = MIME::Base64::encode_base64url( $href, q{} ); if( !$self->{_tempdir} || !-e $self->{_tempdir}. '/'. $tmpname ) { $self->{_tempdir} //= File::Temp->newdir; write_file( $self->{_tempdir}. '/'. $tmpname, { binmode => ':utf8' }, Encode::encode_utf8($new_code) ); } push @replaces, { href => $href, file => $self->{_tempdir}. '/'. $tmpname }; } # Replace refs foreach my $h ( @replaces ) { $code =~ s/(?=<(?:xsl):(?:import|include)\s*href\s*=\s*)(['"])${h->{href}}['"]/$1${h->{file}}$1/; } # Finalize $include_cache->{$key} = $code if !$self->disable_caching && $changed && $key; return ( $code, $changed // 0 ); } -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 29919] New: Elasticsearch missing alias pl for place-of-publication
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '22

01 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29919 Bug ID: 29919 Summary: Elasticsearch missing alias pl for place-of-publication Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: fridolin.somers(a)biblibre.com Elasticsearch is missing alias "pl" for "place-of-publication". Advanced search uses directly this alias. Currently only working with Zebra. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 31075] New: Script overdue_notices.pl should use GetPreparedLetter
by bugzilla-daemon＠bugs.koha-community.org 01 Jul '22

01 Jul '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31075 Bug ID: 31075 Summary: Script overdue_notices.pl should use GetPreparedLetter Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org The overdue_notices.pl script contains a lot of code for letter/notice handling that really should not be there. Some regular notice constructs do not work since it is doing its own thing. Look at this example: my $letter = parse_overdues_letter( { letter_code => $overdue_rules->{"letter$i"}, borrowernumber => $borrowernumber, branchcode => $branchcode, items => \@items, substitute => { # this appears to be a hack to overcome incomplete features in this code. bib => $library->branchname, # maybe 'bib' is a typo for 'lib<rary>'? 'items.content' => $titles, 'count' => $itemcount, }, # If there is no template defined for the requested letter # Fallback on the original type message_transport_type => $letter_exists ? $effective_mtt : $mtt, } ); The comment talks about a hack to overcome incomplete features. I did mark this as major, and not enhancement for refactoring. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6