April 2014 - Koha-bugs - lists.koha-community.org

[Bug 10700] New: Remove misc/cronjobs/rss
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '14

21 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10700 Bug ID: 10700 Summary: Remove misc/cronjobs/rss Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org The RSS cron script hasn't been touched for years, and the associated template files predate our switch to Template Toolkit. Since we now have the ability to make the results of saved SQL reports public, I think we should consider this RSS system dead and remove it. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 6918] New: can't place holds on 'on order' items with AllowOnShelfHolds off
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6918 Bug #: 6918 Summary: can't place holds on 'on order' items with AllowOnShelfHolds off Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: major Priority: P5 Component: Circulation AssignedTo: kyle.m.hall(a)gmail.com ReportedBy: nengard(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org CC: gmcharlt(a)gmail.com I don't think this was always the case (but I might be wrong). If AllowOnShelfHolds is set to 'don't allow' then patrons cannot place holds on items that are marked 'on order' (not for loan=-1). Technically items on order are not on the shelf and should be allowed to be placed on hold. This may require a preference for people to say whether they want to allow holds on 'on order' items and/or what the not for loan value is for 'on order' since there is nothing stopping the user from changing the value from -1 to something else. The easy fix is just to make the system allow holds on items with -1 for notforloan like I think it was before. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 29

[Bug 11899] New: Force staff to choose option for filling a hold
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11899 Bug ID: 11899 Summary: Force staff to choose option for filling a hold Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Hold requests 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 If a staff member checks in an item on hold, then checks in another item without confirming the hold, the hold will not be filled. There needs to be a block before another transaction. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 11897] New: Stock Rotation for Koha
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11897 Bug ID: 11897 Summary: Stock Rotation for Koha 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We intend on writing a stock rotation module for Koha. We aim to add a batch process to automate rotation with a staff client page under tools to manage rotas/schedules. Once a rota is configured, and your staff user has the right permissions to allocate items, then an additional tab will appear on biblio records allowing the management of of which rota, if any, individual items belong to. This is different to the rotating collections work as it is designed around rotating individual items upon an automated schedule, however some of the code in that area may be re-factored to allow sharing between the two features. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 11851] New: holdings table should have action links consolidated into one column
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11851 Bug ID: 11851 Summary: holdings table should have action links consolidated into one column Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: gmcharlt(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com With the push of the patches for bug 11746, depending on the user's permissions and syspref settings, there can be the following separate columns for initiating actions on a given item: - spine label - edit These should be consolidated into a single action column, that if present is non-sortable. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 11746] New: Add edit item links to record details page
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11746 Bug ID: 11746 Summary: Add edit item links to record details page Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In order to edit a specific item right now, one must select the edit pulldown, then choose edit items, the click the edit link for the particular item the librarian wishes to edit. It would be much more convenient to have an edit link for each specific item in the items table on the record details page. -- You are receiving this mail because: You are watching all bug changes.

1 30

[Bug 10790] New: adding/editing item types screen mis aligned if noItemTypeImages not showing
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10790 Bug ID: 10790 Summary: adding/editing item types screen mis aligned if noItemTypeImages not showing 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: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 20661 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=20661&action=edit add item type See attached. When you have noItemTypeImages set to "Don't show" everything goes wonky on the add item type screen. -- You are receiving this mail because: You are watching all bug changes.

1 10

[Bug 12094] New: jQueryUI upgrade broke default tab selection
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12094 Bug ID: 12094 Summary: jQueryUI upgrade broke default tab selection Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED 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 Another unforeseen consequence of the jQueryUI upgrade: default tab select is broken. This is most visible on the search results page where the "search the catalog" tab should be selected by default but isn't. -- You are receiving this mail because: You are watching all bug changes.

1 9

[Bug 11570] New: Upgrade jQueryUI to latest version
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11570 Bug ID: 11570 Summary: Upgrade jQueryUI to latest version Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED 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 Koha master currently uses jQueryUI version 1.8.23. We should upgrade to the latest version, currently 1.10.3. This upgrade would not conflict with our version of jQuery. At the very least the upgrade would help with Bug 11042 because of improvements to the default jQueryUI CSS. -- You are receiving this mail because: You are watching all bug changes.

1 21

[Bug 11850] New: Bulkmarcimport does not append in logfile
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '14

19 Jun '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11850 Bug ID: 11850 Summary: Bulkmarcimport does not append in logfile Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org Bulkmarcimport has the -l option, which allows to write to a logfile. It does work, however, its behavior is not what we expect from a logfile. Indeed, bulkmarcimport erases the logfile each time it is executed. The expected behavior imho is to append the logs to the given file. Test plan: 1) use bulkmarcimport several times with the same logfile given with -l. 2) the logfile is erased every time. -> KO Apply the patch, then: 1) use bulkmarcimport several times with the same logfile given with -l. 2) the logs are correctly appended to the logfile. -> OK -- You are receiving this mail because: You are watching all bug changes.

1 19