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

[Bug 16780] New: Specify due date always sets time as AM when using 12 hour time format
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '20

20 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16780 Bug ID: 16780 Summary: Specify due date always sets time as AM when using 12 hour time format Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To recreate: 1 - On the checkout screen for a patron specify a due date and a PM time 2 - Checkout an item 3 - Note the due date for the item and the time in the box have switched to AM -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 19

[Bug 17256] New: Don't display 246 if 1st indicator is "3"
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17256 Bug ID: 17256 Summary: Don't display 246 if 1st indicator is "3" Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: felix.hemme(a)thulb.uni-jena.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If you want to create further search entries in MARC field 246 you can set 1st indicator to 3 "no note, added entry". The content of field 246 should not be displayed in the staff client and online catalog. It should only display if indicator 1 is "0" or "1". -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 18006] New: MARC21: Don't show 246 when 1st indicator = 3
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18006 Bug ID: 18006 Summary: MARC21: Don't show 246 when 1st indicator = 3 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org http://www.loc.gov/marc/bibliographic/bd246.html It is our understanding, that the entry should be searchable but not display in the detail view, when the first indicator of 246 is 3. For example: 245 10 $a Apples & bears (displayed) 246 33 $a Apples and bears (not displayed) See also discussion on IRC: http://irc.koha-community.org/koha/2017-01-27#i_1900430 -- You are receiving this mail because: You are watching all bug changes.

1 1

[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 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 17531] New: Search categories for itemtypes broken
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17531 Bug ID: 17531 Summary: Search categories for itemtypes broken Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The feature introduced with bug 10937 appears to be broken on current master. You can add a search category and the display on the advanced search page is correct, but the search won't return any results. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 17362] New: Patron import overwrite adds debarments
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17362 Bug ID: 17362 Summary: Patron import overwrite adds debarments Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: mirko(a)abunchofthings.net QA Contact: testopia(a)bugs.koha-community.org When importing patrons via tools, if overwrite is chosen and there is a debarred column with 1, the debarments add up with every import. Might be related to bug 15010. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 17000] New: Patron Modification log access permission
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17000 Bug ID: 17000 Summary: Patron Modification log access permission Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: ed.veal(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com You can only see patron modification log when viewing a patron record if you have one or both of the “parameters Manage Koha system settings (Administration panel)” permissions. This is good information for the circulation staff to be able to access. Ed -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 16970] New: In OPAC Search results, <Limit to current available items > hides a record if some of its items are available and others unavailable
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16970 Bug ID: 16970 Summary: In OPAC Search results, <Limit to current available items> hides a record if some of its items are available and others unavailable Change sponsored?: --- Product: Koha Version: 3.22 Hardware: PC OS: Windows Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: thysia(a)live.com QA Contact: testopia(a)bugs.koha-community.org This is a misleading bug for users on OPAC, as they can think that a book is not currently available when it has still available items. If we cannot solve this bug, it would be better not to give this feature. -- You are receiving this mail because: You are watching all bug changes.

1 5