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

[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 24682] New: Clarify UsageStatsGeolocation syspref description and behaviour
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24682 Bug ID: 24682 Summary: Clarify UsageStatsGeolocation syspref description and behaviour 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: pasi.kallinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The syspref UsageStatsGeolocation needs to be improved, in couple ways: Perform value format checking (eg. there should be no spaces, no letters) OR Make the value read-only. AND Change the syspref description to mention this is edited in <intranet>/cgi-bin/koha/admin/usage_statistics.pl (with a link to there, of course) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[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 15436] Use semicolon between series name and volume information
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15436 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=17875 -- You are receiving this mail because: You are watching all bug changes.

1 0

[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