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

[Bug 20078] New: Indexes 'arl' (Accelerated reading level) and 'arp' (Accelerated reading point) not usable in search menus.
by bugzilla-daemon＠bugs.koha-community.org 07 Dec '22

07 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20078 Bug ID: 20078 Summary: Indexes 'arl' (Accelerated reading level) and 'arp' (Accelerated reading point) not usable in search menus. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Zebra Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com The indexes 'arl' (Accelerated reading level) and 'arp' (Accelerated reading point) are not listed in C4::Search::getIndexes, and therefore cannot be used in the koha drop down menus. To re-create: Find a bib with 526$c and 526$d populated, e.g. +---------------+--------------+-------------+-------------+ | title | biblionumber | 526$c (arl) | 526$d (arp) | +---------------+--------------+-------------+-------------+ | Star flight / | 1347 | 5.5 | 14 | +---------------+--------------+-------------+-------------+ Entering the following in the search bar works: arl:5.5 as does arp:14 However entering the following in intranetuserjs: $(document).ready(function(){ // Add Accelerated Reading Level to advanced search if (window.location.href.indexOf("catalogue/search.pl") > -1) { $(".advsearch").append('<option value="arl">Accelerated Reading Level</option>'); } // Add Accelerated Reading Point to advanced search if (window.location.href.indexOf("catalogue/search.pl") > -1) { $(".advsearch").append('<option value="arp">Accelerated Reading Point</option>'); } }); Then running an advanced search using the respective values of Accelerated Reading Level and Accelerated Reading Point will fail. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 20

[Bug 18309] New: UNIMARC update from IFLA
by bugzilla-daemon＠bugs.koha-community.org 07 Dec '22

07 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18309 Bug ID: 18309 Summary: UNIMARC update from IFLA Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt(a)gmail.com Reporter: fridolin.somers(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org IFLA Federation published new recommendations for UNIMARC standard. Will impact pré-installed biblio and authorities frameworks. -- You are receiving this mail because: You are watching all bug changes.

1 183

[Bug 19963] New: ethnicity and ethnicity tables and columns survived update
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19963 Bug ID: 19963 Summary: ethnicity and ethnicity tables and columns survived update Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The database update for 3.21.00.033 should have removed the ethnicity table and the ethnicity and ethnotes columns from borrowers, deletedborrowers and borrower_modifications. This didn't work right in all cases. I just noticed that all those survived in our older databases. The reason is that the database update only checked for NULL when counting existing data, but not for "": 11054 $DBversion = "3.21.00.033"; 11055 if ( CheckVersion($DBversion) ) { 11056 11057 my $done = 0; 11058 my $count_ethnicity = $dbh->selectrow_arrayref(q| 11059 SELECT COUNT(*) FROM ethnicity 11060 |); 11061 my $count_borrower_modifications = $dbh->selectrow_arrayref(q| 11062 SELECT COUNT(*) 11063 FROM borrower_modifications 11064 WHERE ethnicity IS NOT NULL 11065 OR ethnotes IS NOT NULL 11066 |); 11067 my $count_borrowers = $dbh->selectrow_arrayref(q| 11068 SELECT COUNT(*) 11069 FROM borrowers 11070 WHERE ethnicity IS NOT NULL 11071 OR ethnotes IS NOT NULL 11072 |); 11073 # We don't care about the ethnicity of the deleted borrowers, right? 11074 if ( $count_ethnicity->[0] == 0 11075 and $count_borrower_modifications->[0] == 0 11076 and $count_borrowers->[0] == 0 11077 ) { 11078 $dbh->do(q| 11079 DROP TABLE ethnicity 11080 |); 11081 $dbh->do(q| 11082 ALTER TABLE borrower_modifications 11083 DROP COLUMN ethnicity, 11084 DROP COLUMN ethnotes 11085 |); 11086 $dbh->do(q| 11087 ALTER TABLE borrowers 11088 DROP COLUMN ethnicity, 11089 DROP COLUMN ethnotes 11090 |); 11091 $dbh->do(q| 11092 ALTER TABLE deletedborrowers 11093 DROP COLUMN ethnicity, 11094 DROP COLUMN ethnotes 11095 |); 11096 $done = 1; 11097 } 11098 if ( $done ) { 11099 print "Upgrade to $DBversion done (Bug 10020: Drop table ethnicity and columns ethnicity and ethnotes)\n"; 11100 } 11101 else { 11102 print "Upgrade to $DBversion done (Bug 10020: This database contains data related to 'ethnicity'. No change will be done on the DB structure but note that the Koha codebase does not use it)\n"; 11103 } 11104 11105 SetVersion ($DBversion); -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 20591] New: DBI->last_insert_id does not work as expected
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20591 Bug ID: 20591 Summary: DBI->last_insert_id does not work as expected Change sponsored?: --- Product: Koha Version: unspecified 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: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Try the following code: use Koha::Database; use Koha::Cities; use Koha::AuthorisedValues; my $schema = Koha::Database->schema; $schema->storage->txn_begin; my $dbh = C4::Context->dbh; my $city = Koha::City->new({ city_name => 'name' })->store; say $city->cityid; say $dbh->last_insert_id( undef, undef, 'cities', undef ); say $dbh->last_insert_id( undef, undef, 'not_exist', undef ); say "==="; my $av = Koha::AuthorisedValue->new({category => 'LOC', authorised_value => 'just_a_test'})->store; say $av->id; say $dbh->last_insert_id( undef, undef, 'authorised_values', undef ); say $dbh->last_insert_id( undef, undef, 'cities', undef ); say $dbh->last_insert_id( undef, undef, 'not_exist', undef ); It will display: 12 12 12 === 401 401 401 401 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 16536] New: Warn about Template Toolkit directives inside HTML tags
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16536 Bug ID: 16536 Summary: Warn about Template Toolkit directives inside HTML tags Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: QA tools Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: oleonard(a)myacpl.org I was testing a patch (on Bug 16525) which contained this markup: <a href="[% IF ( budget_period_id) %]/cgi-bin/koha/admin/aqbudgets.pl?budget_period_id=[% budget_period_id %][% ELSE %]/cgi-bin/koha/admin/aqbudgetperiods.pl[% END %]" class="cancel">Cancel</a> I expected it to trigger a warning by the QA tools. My system is a gitified package install, so it seems possible that this is a problem with my configuration. Running "prove xt" doesn't catch it either. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 21153] New: Add system preference to hide login box on opac-main.pl
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21153 Bug ID: 21153 Summary: Add system preference to hide login box on opac-main.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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org There should be a system preference to hide the login box on opac-main.pl, and that system preference should also make it so that the opacmainuserblock can be 12 if opacuserlogin == 1 but the new system preference == 0. I have a lot of people who hide it with CSS, but it means that a lot of front page real estate is wasted with whitespace. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 19168] New: Non-Debian koha-httpd.conf prevents oai.pl from working
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19168 Bug ID: 19168 Summary: Non-Debian koha-httpd.conf prevents oai.pl from working Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org The following block in koha-httpd.conf prevents oai.pl from working in a web browser: # Secure internal stuff <DirectoryMatch "__OPAC_WWW_DIR__/.*/(modules|xslt|includes)"> Order deny,allow Deny from all </DirectoryMatch> You get a 403 for /opac-tmpl/xslt/OAI.xslt which prevents the HTML from displaying. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 16352] New: Fix spacing for 245$h and 245$c in XSLTs
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16352 Bug ID: 16352 Summary: Fix spacing for 245$h and 245$c in XSLTs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Bug 13381 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13381) apparently changed the spacing for the $h and $c subfields, which causes template text to appear concatenated. It's as easy as adding some <xsl:text> </xsl:text> elements after the spans. It looks like it's for both the intranet and the OPAC. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 18585] New: Connect to RDF triplestore
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18585 Bug ID: 18585 Summary: Connect to RDF triplestore Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In order to store RDF data, we need to be able to connect to a triplestore. This enhancement simply allows us to connect to a separate triplestore. -- You are receiving this mail because: You are watching all bug changes.

1 57

[Bug 17355] New: Allow deletion of authorised value categories
by bugzilla-daemon＠bugs.koha-community.org 06 Dec '22

06 Dec '22

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17355 Bug ID: 17355 Summary: Allow deletion of authorised value categories Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com This will be a follow-up to bug 17216 that adds a separate table for authorised value categories. Now that we store them, we need a way to delete accidentally added categories easily. Jonathan wrote about this: - There is no way to delete a category (TODO). But to do so it would be good to have a authorised_value_categories.is_internal field to mark some categories as "cannot be deleted". -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 66