June 2015 - Koha-bugs - lists.koha-community.org

[Bug 13924] New: LocalHoldsPriority needs dateaccessioned limits.
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '15

01 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13924 Bug ID: 13924 Summary: LocalHoldsPriority needs dateaccessioned limits. Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com LocalHoldsPriority needs to have another parameter to limit by number of days since dateaccessioned date. We have several libraries that need the LocalHoldsPriority on, but in doing so, have found that very popular items, such as video games or video streaming devices never leave our library because we always have someone from our library with a hold on them. It would be great to have this new parameter, so new items (which is what we tend to want the LocalHoldsPriority for) would be priority at their home branch, but maybe 6 weeks or 2 months later they don't have to be. Christopher -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 14362] New: PEGI 15 Circulation/AgeRestrictionMarkers test fails
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '15

01 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14362 Bug ID: 14362 Summary: PEGI 15 Circulation/AgeRestrictionMarkers test fails Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: mtompset(a)hotmail.com QA Contact: gmcharlt(a)gmail.com In C4/Circulation.pm there is a function call to Date_to_Days(Today). This includes/excludes (not sure which) the timezone, which causes a calculation error when trying to run prove t/Circulation/AgeRestrictionMarkers.t -- You are receiving this mail because: You are watching all bug changes.

1 26

[Bug 8994] New: Make FindDuplicateAuthority behaviour customizable
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '15

01 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=8994 Priority: P5 - low Change sponsored?: --- Bug ID: 8994 CC: m.de.rooy(a)rijksmuseum.nl Assignee: julian.maurice(a)biblibre.com Summary: Make FindDuplicateAuthority behaviour customizable Severity: enhancement Classification: Unclassified OS: All Reporter: julian.maurice(a)biblibre.com Hardware: All Status: ASSIGNED Version: master Component: Cataloging Product: Koha Make FindDuplicateAuthority behaviour customizable by adding 2 system preferences. -- You are receiving this mail because: You are watching all bug changes.

1 15

[Bug 13927] New: Add API route to check hold capabilities
by bugzilla-daemon＠bugs.koha-community.org 01 Sep '15

01 Sep '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13927 Bug ID: 13927 Summary: Add API route to check hold capabilities Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Web services Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 13903 Often when a 3rd-party application want to deal with reserves in Koha, it must know in advance if the reserve is allowed (for example to hide the "place hold" link if hold is not allowed) This new route does just that, telling if a given hold is allowed for a given patron. Moreover, it also returns a list of available pickup locations (restricting to only the borrower's branch if IndependentBranches is set). Depends on bug 13903. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 11584] New: Add wysiwyg editor to system preferences dealing with HTML
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '15

31 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11584 Bug ID: 11584 Summary: Add wysiwyg editor to system preferences dealing with HTML 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org Currently, library staff have to hand-code system preferences that include HTML in them (e.g. OpacNAV, OpacHeader, etc.). This enhancement will add a wysiwyg editor for system preferences that are marked as "Htmlarea". Built-in system preferences (like those mentioned above) will need to have their .pref files changed (and I suppose the database even though the Type recorded there doesn't appear to be used by Koha itself). While a new type of "Htmlarea" will be available for Local System Preferences. People using Koha as a CMS (http://wiki.koha-community.org/wiki/Koha_as_a_CMS) might find this useful. Or anyone that has added local system preferences for injecting HTML into their templates. -- You are receiving this mail because: You are watching all bug changes.

1 39

[Bug 13568] New: OAI Server doesn't handle properly resumption token
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '15

31 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13568 Bug ID: 13568 Summary: OAI Server doesn't handle properly resumption token Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: frederic(a)tamil.fr QA Contact: testopia(a)bugs.koha-community.org When responding to ListRecords and ListIdentifiers verbs, OAI server doesn't return proper resumption token. At the end of a result set, OAI server generates a resumption token even if there isn't anymore records. Consequently, OAI harverster will send a new request, based on this invalid resumption, token. OAI Server responds with an empty resultset, which is considered as an invalid response by most of the harvesters. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 14398] New: Duplicate inventory results when an item is in the wrong place (ie using branch/location filter)
by bugzilla-daemon＠bugs.koha-community.org 31 Aug '15

31 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14398 Bug ID: 14398 Summary: Duplicate inventory results when an item is in the wrong place (ie using branch/location filter) 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, if an item is in the "wrong place" during an inventory, it will show up with a "problem" of "Item should not have been scanned", which makes sense. However, a duplicate row will also turn up saying "Change item status". This is a row that comes up due to a bug in the processing of not for loan values http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12913. In other words... an item might have multiple problems, but instead of listing multiple problems, an entire extra row gets added to the inventory results. I suppose this could be by design, but it seems like a bug to me, especially if you're feeding your inventory results into "Batch Item Modify" later... -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 14337] New: AllowRenewalIfOtherItemsAvailable counts holdable not for loan items when checking renewability
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '15

28 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14337 Bug ID: 14337 Summary: AllowRenewalIfOtherItemsAvailable counts holdable not for loan items when checking renewability Change sponsored?: --- Product: Koha Version: 3.18 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com AllowRenewalIfOtherItemsAvailable checks C4::Reserves::IsAvailableForItemLevelRequest to see if the item is holdable, which catches not for loan values less than 0 ( i.e. holdable, but not circ-able ). However, since this feature is about actually checking out items to patrons, we should not count *any* not for loan items when deciding if the available items will satisfy all current holds. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 33

[Bug 13142] New: Change "mobile phone" label back to "other phone"
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '15

28 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13142 Bug ID: 13142 Summary: Change "mobile phone" label back to "other phone" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: nengard(a)gmail.com Bug 12407 changed the "other phone" label to "mobile phone." However I think this conflicts with the changes made by Bug 5252 which changed the labels to the more generic "primary," "secondary," and "other" with the intention of letting the patron choose a primary contact number regardless of what kind of phone it is. If the OPAC didn't reflect this change then that was a bug which should have been fixed as a follow-up to 5252. As for the fact that the database column name says "mobile," I don't think that should dictate what kind of data we are storing. At this point we've created a lot of confusion about how patron contact information is stored. Before August 2011 phone data may have been entered according to the specific "home," "work," and "cell" labels. After that date we can assume that new phone data was added according to the priority defined by the new labels. Now with Bug 12407 we have a mix: Two phone fields in which the patron can prioritize contact numbers, and then "mobile," which is very specific. I don't think this makes sense. In my opinion the correct action at this point is to revert the label change made by Bug 12407 and make the corresponding change to the OPAC. If we feel that it's necessary to be able to identify what *kind* of phone number each one is, perhaps the solution is to add new columns to borrowers which can contain authorized values defining phone types: Primary phone: _________ [ Home | Work | Mobile | Etc ] -- You are receiving this mail because: You are watching all bug changes.

1 28

[Bug 13663] New: offline circ permission issue
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '15

28 Aug '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13663 Bug ID: 13663 Summary: offline circ permission issue Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: normal Priority: P5 - low Component: Circulation Assignee: jonathan.druart(a)biblibre.com Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com circ/offline.pl needs the perm circulate_remaining_permissions but tools/upload-file.pl needs tools => * That means a librarian cannot upload the .koc files generated offline -- You are receiving this mail because: You are watching all bug changes.

1 28