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

[Bug 18245] New: debian/templates/koha-conf-site.xml.in missing tls
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18245 Bug ID: 18245 Summary: debian/templates/koha-conf-site.xml.in missing tls Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: mtompset(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org As noted by Marcel in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15427#c17 -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 18142] New: Staff client search results do not show correct item availability
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18142 Bug ID: 18142 Summary: Staff client search results do not show correct item availability Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: snicker1(a)maine.rr.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In both 3.22.02.00 and 16.05.09.000 the "summary" search results do not show item availability correctly, with ALL items showing as "<x> items, x<> available", even if the item is currently checked out. Clicking on the item title brings you to the details, where it shows correctly as checked out, and the OPAC search results also show the item properly as checked out in both the summary search results list and in the individual item details, it is only in the Staff client summary search results that it is improperly displayed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 21521] New: Payment types do not sort alphabetically
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21521 Bug ID: 21521 Summary: Payment types do not sort alphabetically Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: rbit(a)rbit.cz QA Contact: testopia(a)bugs.koha-community.org When adding new payment in patron's page, all the names of payments should be sorted alphabetically. It's especially useful if the list of payment types is long. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 20297] New: Unused code in update-child template
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20297 Bug ID: 20297 Summary: Unused code in update-child template 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: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In members/update-child.tt, there is a javascript block guarded by "IF (CONFIRM)", but CONFIRM is not defined anywhere: $ rgrep -E '\bCONFIRM\b' * blib/INTRANET_TMPL_DIR/prog/en/modules/members/update-child.tt: [% IF ( CONFIRM ) %] koha-tmpl/intranet-tmpl/prog/en/modules/members/update-child.tt: [% IF ( CONFIRM ) %] -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 20106] New: Hea - Add notes to system preferences (administration page, example for geolocation)
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20106 Bug ID: 20106 Summary: Hea - Add notes to system preferences (administration page, example for geolocation) Change sponsored?: --- Product: Koha Version: master 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 At the moment we have a nice administration page for Hea, but also have system preferences where you can set those values up for a single library. We should: - Add a note above the preferences to tell people about the administration page - Add an example for UsageStatsGeolocation to make the way to use it more clear. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 18023] New: Add "New from Z39.50" button on search results in Authorities module
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18023 Bug ID: 18023 Summary: Add "New from Z39.50" button on search results in Authorities module Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: alexandre.breton(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org Hi, Someone suggest this little enhancement here for Authorities module. 1) Go to Authorities module 2) Make a research on any subject 3) Observe that a results list appears 4) Clic on "details" to see any one authority 5) Observe now the button "New from Z39.50" (with a magnifying glass) which will replace the selected authority It could be easier and faster if we have the button "New from Z39.50" directly on the results list (step 3) this could permit to skip the steps 4 and 5. Thanks again, Alexandre from CCSR -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 18049] New: record export fails on callnumber limit
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18049 Bug ID: 18049 Summary: record export fails on callnumber limit Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: verolencinas(a)yahoo.com.ar QA Contact: testopia(a)bugs.koha-community.org If you export marc records and select callnumber limits you get this error: DBIx::Class::ResultSet::next(): Unknown column 'callnumber' in 'where clause' at /usr/share/koha/lib/Koha/Objects.pm line 150 Very similar to Bug 17420. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 17875] New: Linking to series authority records fails when a space precedes the semicolon
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17875 Bug ID: 17875 Summary: Linking to series authority records fails when a space precedes the semicolon Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: lucy.vaux-harvey(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl A customer has reported that the automatic linking of series authority records to series fields in the bib record (440 and 830) fails due to the space added before the semicolon when series numbering is present. Prescribed punctuation for series fields requires a space before the semicolon so this space should be ignored. Example: 830 Series Added Entry – Uniform title Alcuin Club collections links to authority record Alcuin club collections ; does not link to authority record Background: ISBD punctuation, which is used in the most recent cataloguing standard (RDA) and in the preceding standard (AACR2), requires a space semicolon at the end of a series statement if it is followed by series numbering (cf. http://www.ifla.org/files/assets/cataloguing/isbd/isbd-cons_2007-en.pdf , RDA 0.3.3 and AACR2 1.6 A1). -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 17721] New: Do we need utf8_bin collation on tagsubfield?
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17721 Bug ID: 17721 Summary: Do we need utf8_bin collation on tagsubfield? Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Comes from report 17676. This discussion should be on a new report. === Comment11 > Indeed we want to keep tagsubfield a utf8_bin (to allow lowercase and uppercase of the same letter for subfields). Could you provide an example where we want to do that? Is that MARC conform? And if so(!), why would you need utf8_bin to do so? You can still insert them, only finding the right a or A would be harder. It seems to me that we should remove this strange exception, and make sure that all tagsubfields are saved lowercase. Should not be too hard. Can MARC::Record handle subfields a and A btw? But this discussion should be on a new report. > if ( $table[1] !~ /COLLATE=utf8_unicode_ci/ and $table[1] !~ /COLLATE=utf8mb4_unicode_ci/ ) { #catches utf8mb4 collated tables This is only 99,9% safe (as you are probably aware of). If you find one column in unicode_ci, the table might still be something else (theoretically). Perhaps someone added a custom column with collation? Since you only change the default here, why not always do it? Replacing X with X will not be a problem.. Comment12&13 (Katrin) It's not strictly MARC conform, but we use this a lot and I have talked to others using it as well. Take the 952 field as the example - all subfield codes are taken. Using upper case letters works fantastically now and allows you to store and index data that we got no other sensible spot for. We got it all working perfectly, why break this feature without need? Ah, and I think I have encountered upper case in German MARC - just can't find a documentation right now. === Even if we do not change it at all, it would be worth writing somewhere why we do not. (And where we can still find it later.) -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 20722] New: Searching only for an ITEMTYPECAT itemtype is impossible
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20722 Bug ID: 20722 Summary: Searching only for an ITEMTYPECAT itemtype is impossible Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Searching for only the itemtype usually works, but not for itemtypes that are actually ITEMTYPECAT categories grouping several itemtypes together. In this case you will need to add a second search criteria for the search to work. Only searching for the group will return you to the advanced search page. To test: - Create an entry for the ITEMTYPECAT authorised value category. Make sure to fill in the OPAC description. - Go to administration > itemtypes and add the new category to 2 item types. - Go to the OPAC and check that the advanced search shows your new itemtype group instead of the individual itemtypes. - Check the checkbox and Search. - You will be returned to the advanced search page without error. - Search for another ungrouped itemtype, it will return correct search results. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13