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

[Bug 17687] New: Rename column subscriptionhistory.recievedlist to receivedlist
by bugzilla-daemon＠bugs.koha-community.org 20 Apr '20

20 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17687 Bug ID: 17687 Summary: Rename column subscriptionhistory.recievedlist to receivedlist Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 2

[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 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

[Bug 16503] New: Label creator: grouping fields with quotes does not work in layout creator
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16503 Bug ID: 16503 Summary: Label creator: grouping fields with quotes does not work in layout creator Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The description for "Data field" under label-edit-layout.pl shows "Enter a comma separated list of fields to print. You may include any Koha field or MARC subfield. See online help for advanced options ex: barcode, itemcallnumber, title, "050a 050b", 300a Fields homebranch_description, holdingbranch_description, ccode_description, location_description and permanent_location_description show description instead of code." This seems to indicate that grouping fields using quotes, non-comma separated, *should* work: Given an item with the following data: title: Juggling for the complete klutz / author: Cassidy, John. itemcallnumber: JNF 793.8 Cas Using the data fields "title author", itemcallnumber Should yield a CSV export this: "Juggling for the complete klutz / Cassidy, John.","JNF 793.8 Cas" Instead I get this: ,"JNF 793.8 Cas" To replicate: 1/ Create a record using the title, author and itemcallnumber above. 2/ Go to tools > label creator 3/ Add a batch containing the created item 4/ Add a new layout. Click the list fields radio button, and add the fields title, author, itemcallnumber 5/ Export the batch as CSV using the new layout. The resulting file will look like this: "Juggling for the complete klutz /","Cassidy, John.","JNF 793.8 Cas" 6/ Edit the layout, change the field list to "title author", itemcallnumber 7/ Export the batch again, the new CSV file will read ,"JNF 793.8 Cas" The bug was replicated under version 3.23. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 17143] New: Popup Notification for decreaseloanhighholds preference
by bugzilla-daemon＠bugs.koha-community.org 16 Apr '20

16 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17143 Bug ID: 17143 Summary: Popup Notification for decreaseloanhighholds preference Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If you have an item that meets the holds requirement by the decreaseloanhighholds preference, but doesn’t get a decrease in the actual checkout period; you still get a popup notification that the high demand feature is being used and the loan period will be decreased. The notification shouldn't populate if the decreased loan period matches or is higher than the original loan period. The current behavior in the system looks at the the number of holds and doesn't take the loan periods with an equal value into consideration when enforcing the preference. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5