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

[Bug 20674] New: One off report
by bugzilla-daemon＠bugs.koha-community.org 06 Apr '20

06 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20674 Bug ID: 20674 Summary: One off report Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: tlamannajr(a)chplnj.org QA Contact: testopia(a)bugs.koha-community.org Right now the only way to create and run a report is to save it to a list, but there are plenty of times I just need a one-off report and it's a bit of a pain to have to create and name a report then delete in when I'm done. This clutters up the reports list a lot. Not a massive problem, but I'm hoping we can streamline one off reports. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 24505] New: Print overdue notice with html gives message: "The following terms were not matched and replaced"
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '20

05 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24505 Bug ID: 24505 Summary: Print overdue notice with html gives message: "The following terms were not matched and replaced" Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: somesecretemail(a)mailinator.com QA Contact: testopia(a)bugs.koha-community.org In overdue notice for the option "print" we use a template containing html. After running the overdue_notices cron job: > sudo perl /usr/share/koha/bin/cronjobs/overdue_notices.pl -t -v -html /tmp a message is presented by the system "The following terms were not matched and replaced: html, div, etc...". It seems like the system confuses the "<< >>" enclosed text with the html components. Nothing from the template is added to the generated html file. This bug is exactly the same as this bug fixed in 2013: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10720 You can also find it well documented in the commit here: https://gitlab.deichman.no/digibib/Koha/commit/394be84dcd65a4569d0467bc12b9… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 24504] New: branchtransfers.pl - Entering checked out item cause Internal Server Error
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '20

05 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24504 Bug ID: 24504 Summary: branchtransfers.pl - Entering checked out item cause Internal Server Error Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: fraktik(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Interestingly enough this is happening only first time (item get checked in and then this "Internal Server Error" blank page appears). If I get back to /cgi-bin/koha/circ/branchtransfers.pl and put the same barcode second time, the transfer is processed without any further error. Possible relation to the Bug 3536 - Checked In item requiring transfer does not consistently trigger transfer prompt (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3536) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 21269] New: add unique id to issuingrules, include that id in issues table
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '20

05 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21269 Bug ID: 21269 Summary: add unique id to issuingrules, include that id in issues table Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Perhaps an overly-large ask, but would be a huge boon for troubleshooting circulation behavior. If issuingrules contained a column for issuingrule_id, that value could be included in the issues table, allowing easy identification of which issuing rule applied to a given checkout. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 21253] New: Clarify calendar used by book drop mode
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '20

05 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21253 Bug ID: 21253 Summary: Clarify calendar used by book drop mode Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When using book drop mode in returns.pl, the checkin date is set to the last date the library was open. However, this gets confusing when multiple branches within the same system have different calendars. Book drop mode selects a date based on the calendar of the library whose circ rules governed the checkout (the library indicated by the CircControl and HomeOrHolding sysprefs). It does not consult the calendar of the library at which the checkin is taking place. This is not a particularly transparent behavior and is not explained in the manual. I'd like to see an explanation added to https://koha-community.org/manual/17.11/html/05_circulation.html#check-in-r…. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 21197] New: Search index list doesn't show other-control-number
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '20

05 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21197 Bug ID: 21197 Summary: Search index list doesn't show other-control-number Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The search index list at https://koha-community.org/manual/17.11/html/13_searching.html#koha-search-… doesn't mention the indexing of the 035 as other-control-number established in Bug 6499 (https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6499) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 21147] New: When suspension ends today, the datepicker shows tomorrow's date
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '20

05 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21147 Bug ID: 21147 Summary: When suspension ends today, the datepicker shows tomorrow's date Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When a suspension ends on today's date, the datepicker in the holds table will show tomorrow's date, as today can't be picked. That might hide a problem with the cronjob not running and it would be nice, if the actual date could be displayed instead. Marking as minor as with correctly running cronjobs you might not encounter this ever. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 21140] New: Mechanism added to import functionality & cataloging re: MARC21 fields 035 & 001, frameworks
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '20

05 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21140 Bug ID: 21140 Summary: Mechanism added to import functionality & cataloging re: MARC21 fields 035 & 001, frameworks Change sponsored?: --- Product: Koha Version: 17.11 Hardware: PC OS: Windows Status: NEW Severity: new feature Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: emjhet(a)pa.net QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Would like to see the following enhancements to import functionality: 1. When importing a bibliographic record into Koha, the imported 001 would automatically move to the 035$a. Would like to see the following enhancements to cataloging: 1. Have the option to have the 999$c copied into the 001 when the bibliographic record is initially saved. 2. The ability to select which framework we wish to have as the default framework. This would permit us to better follow the cataloging rules and practices governed by AACR2r, RDA, LC, and local practice. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 21120] New: item-level types and advanced searches
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '20

05 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21120 Bug ID: 21120 Summary: item-level types and advanced searches Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: emjhet(a)pa.net QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com In Koha -- Administration -- System Preferences -- Cataloging -- Item Record -- under "item-level-itypes" we have selected "use the item type of the {specific item} as the authoritative item type (for determining circulation and fine rules, for displaying an item type icon on either opac detail or results page, etc)." however, when you do an advanced search for an item type, the search results pull from both the item record AND the bibliographic record. I have a few problems with this. 1) How was I suppose to know that, when doing an advanced search, after selecting what I wanted as my authoritative item type, that advanced searches were not covered in the "etc" of the description? When I run reports requesting these item types they could not be found, because the reports were looking for item records with the specified item types, not bibliographic records with a specific field in the 942$c. It almost seems as though this is a Koha to MARC mapping issue, except only one MARC field can be mapped to any one Koha field and in this case, two fields are being mapped to the same field. When the item record item type and the bibliographic 942$c were the same, it did not result in twice the number of results -- so??? 2) I have read the Koha manual. I have never found a place where terms are defined. Is there somewhere that this information is found -- where it states "when you search for item type in the opac field A, B, and C is searched." That does not seem to be what the Koha to MARC mapping indicates. And that language does not seem to match the Koha Search Indexes. Is there no way to use the same language to indicate the same things? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 21057] New: Patrons visiting the library (Patrons visits records)
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '20

05 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21057 Bug ID: 21057 Summary: Patrons visiting the library (Patrons visits records) Change sponsored?: --- Product: Koha Version: 18.05 Hardware: PC OS: Linux Status: NEW Severity: new feature Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: abdullrahman.hegazy4(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 76804 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=76804&action=ed… This is an image of actual working example in the library. This module stores the cardnumber of the patrons who visits the library building. * Its not a bug. * The module is already creadted and working, but i think it needs alot of enhancemnts. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5