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

[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

[Bug 20848] New: Add the ability to batch renew or easily renew relative checkouts attached to the guarantor
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '20

05 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20848 Bug ID: 20848 Summary: Add the ability to batch renew or easily renew relative checkouts attached to the guarantor Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When a guarantor has multiple guarantees, it is a time consuming process to go into each account and renew the guarantees items in addition the guarantor. It would be great to see the ability to easily access all the checkouts at the one time. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 20950] New: Plugins: Handler.pm doesn't fail gracefully when running plugin
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '20

05 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20950 Bug ID: 20950 Summary: Plugins: Handler.pm doesn't fail gracefully when running plugin 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: andrew.isherwood(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org When running a plugin that fails for some internal reason, the user doesn't always receive a very helpful message. With the Kitchen Sink plugin ( https://github.com/bywatersolutions/koha-plugin-kitchen-sink ) I managed to break it by trying to import C4::Members::GetMember - which doesn't exist any more. Running the plugin in this broken state resulted in: run.pl: Plugin Koha::Plugin::Com::ByWaterSolutions::KitchenSink cannot be loaded at /usr/share/koha/Koha/Plugins/Handler.pm line 72.: /usr/share/koha/plugins/run.pl It turns out that Koha::Plugins::Handler::run calls Module::Load::Conditional::can_load, which was returning false, which caused the message I saw to be output. However, Module::Load::Conditional sets a global variable upon can_load returning false containing the reason. We should display this (assuming we don't consider it to be a security risk). So, in Handler.pm, we'd need to substitute in: if ( can_load( modules => { $plugin_class => undef } ) ) { my $plugin = $plugin_class->new( { cgi => $cgi, enable_plugins => $args->{'enable_plugins'} } ); if ( $plugin->can($plugin_method) ) { return $plugin->$plugin_method( $params ); } else { warn "Plugin does not have method $plugin_method"; } } else { warn "Plugin $plugin_class cannot be loaded: " . $Module::Load::Conditional::ERROR; } -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 20907] New: Improve sorting for suggestions
by bugzilla-daemon＠bugs.koha-community.org 05 Apr '20

05 Apr '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20907 Bug ID: 20907 Summary: Improve sorting for suggestions Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: christian.stelzenmueller(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The suggestions from the suggestion list can currently only be sorted by "by" in the columns "Managed by/on" and "Suggested by/on". It should also be sorted by date ("on"). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1