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

[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 23900] New: Label maker cannot concatenate database fields
by bugzilla-daemon＠bugs.koha-community.org 19 Apr '20

19 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23900 Bug ID: 23900 Summary: Label maker cannot concatenate database fields Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Label/patron card printing Assignee: cnighswonger(a)foundations.edu Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The manual explains that one can use double quotes when listing fields for one's label layout to make two or more values concatenate onto a single line in one's label. >From https://koha-community.org/manual//18.11/en/html/tools.html#layouts: "You can also enclose a whitespace-separated list of fields to concatenate on one line in double quotes, for example “099a 099b” or “itemcallnumber barcode”. Testing this on both 18.11 and 19.05, this works for MARC fields but not for database fields. To test: - define a label layout with this field list: "100a 245s","enumchron copynumber" - find or create a record with values for all of those fields - generate a label for that record - the 100a and 245s successfully display on one line - the enumchron and copynumber do not display at all -- You are receiving this mail because: You are watching all bug changes.

1 23

[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 24138] New: suspension miscalculated when Suspension charging interval bigger than 1 and Max. suspension duration is defined
by bugzilla-daemon＠bugs.koha-community.org 18 Apr '20

18 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24138 Bug ID: 24138 Summary: suspension miscalculated when Suspension charging interval bigger than 1 and Max. suspension duration is defined Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When a circulation rule have a suspension charging interval bigger than one and also has defined a max suspension day, the fine is miscalculated. The issue is that the max suspension day is affected by "suspension Charging interval" for example if we have a suspension interval of 15 and max suspension days of 365 , koha will only apply of 24 suspension day, it seems there a direct inversion relation between both variables. reproduce plan. set up a rule of 7 days suspension every 15 days with max suspension of 365 days check out a book with due date 28/10/2018, and check in, you will see that the suspension is just 24 days If you increase the max suspension day to 730, you will have a suspension of 48 days (aprox) If you increase the max suspension day to (15x365) you will have the year suspension. If you define 1 suspension day every day with max of 365 and you check out andcheck in the same dates, you will have the suspension of 365 days -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 34

[Bug 22999] New: Switch two-column templates to Bootstrap grid: Circulation
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '20

17 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22999 Bug ID: 22999 Summary: Switch two-column templates to Bootstrap grid: Circulation 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: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: testopia(a)bugs.koha-community.org Blocks: 20654 Target Milestone: --- The circulation (check out) template should be updated to use the Bootstrap grid. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20654 [Bug 20654] Omnibus: Update two-column templates to use Bootstrap grid -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 23236] New: Remove 'its items may still be processed' in action if no match is found
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '20

17 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23236 Bug ID: 23236 Summary: Remove 'its items may still be processed' in action if no match is found Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org I think this is only a string bug, but I'd like a developer to make sure nothing happens behind the scenes. When importing records and looking for duplicate records using record matching rules, there is an option if NO match is found to "ignore incoming record (its items may still be processed)". This doesn't make any sense. Where would the items go if there is no match? To reproduce : 1) Go to tools > Stage MARC for import 2) Browse and choose a file and click on Upload file 3) Go to the Look for existing records in catalog? section 4) Open the drop down for Action if no match is found 5) Note that one option says Ignore incoming record (its items may still be processed) This option should only say Ignore incoming record. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 21708] New: Editing a record moves field 999 to first in the marcxml
by bugzilla-daemon＠bugs.koha-community.org 17 Apr '20

17 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21708 Bug ID: 21708 Summary: Editing a record moves field 999 to first in the marcxml Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl 1) Import or create a new record. 2) Examine the marcxml of that record in the database - the fields are in the correct numerical order. 3) Edit the record - no need to change any data, just save it. 4) Examine the marcxml in the database - the 999 field is now right after leader and before 001. This is due to TransformHtmlToMarc in C4/Biblio.pm, specifically the $param eq 'biblionumber' case, which pushes the param in the array first, and then the sub uses $record->append_field() Perhaps the array should be sorted by field tag before appending the fields? AFAIK, this doesn't really show up anywhere in Koha, but if you ever edit the records via a script using MARC::Record, new fields cannot be easily inserted into correct position. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38