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

[Bug 9322] New: If multiple transfers exist (from circ/branchtransfers.pl), completing one completes them all
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '14

09 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9322 Bug ID: 9322 Summary: If multiple transfers exist (from circ/branchtransfers.pl), completing one completes them all Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: liz(a)catalyst.net.nz CC: gmcharlt(a)gmail.com To replicate: * get an item's barcode * go to circulation -> transfers * select a branch to transfer to * put in your barcode * submit the transfer * select a different branch to transfer to * (I don't know why you would do this, but) put your same barcode in again * submit the transfer * select a third branch to transfer to * (again, I don't know why you would do this, but) put your same barcode in again * submit the transfer A query against the database will show 3 transfers: select * from branchtransfers; +------------+---------------------+------------+---------------------+----------+---------------+ | itemnumber | datesent | frombranch | datearrived | tobranch | comments | +------------+---------------------+------------+---------------------+----------+---------------+ | 989 | 2012-12-27 14:31:14 | CPL | | FFL | NULL | | 989 | 2012-12-27 14:31:20 | FFL | | FRL | NULL | | 989 | 2012-12-27 14:34:22 | FRL | | CPL | NULL | You can see it's done something kind of smart, by putting the 2nd transfer to go from the destination of the first transfer. Makes good sense. What doesn't make such good sense is that when you complete the first transfer, the following happens: select * from branchtransfers; +------------+---------------------+------------+---------------------+----------+---------------+ | itemnumber | datesent | frombranch | datearrived | tobranch | comments | +------------+---------------------+------------+---------------------+----------+---------------+ | 989 | 2012-12-27 14:31:14 | CPL | 2012-12-27 14:34:36 | FFL | NULL | | 989 | 2012-12-27 14:31:20 | FFL | 2012-12-27 14:34:36 | FRL | NULL | | 989 | 2012-12-27 14:34:22 | FRL | 2012-12-27 14:34:36 | CPL | NULL | +------------+---------------------+------------+---------------------+----------+---------------+ All three transfers are received when the first one is. The other two don't trigger. It's like they never existed. I think this also happens when you have a reserve triggered transit in addition to a circ/branchtransfers.pl transit. This is the cause of the occasional "Item on hold for <patron>, item is already waiting" messages when you would normally be expecting a "Confirm hold for <patron>" message. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 22

[Bug 10655] New: Include list of holds on circ slip or offer separate printing option
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '14

09 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=10655 Bug ID: 10655 Summary: Include list of holds on circ slip or offer separate printing option 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com One of our libraries asked for an option to print a list of open holds for the patron. As far as I can tell it's currently not possible to include a list of holds on the available circulation slips and there is no separate option. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 9723] New: Hourly loans don't show time due in OPAC
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '14

09 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9723 Bug ID: 9723 Summary: Hourly loans don't show time due in OPAC Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com The time an item is due does not display on the patron's record in the OPAC. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 13054] New: Allow server-side sorting by title to ignore custom sets of articles to ignore
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '14

09 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13054 Bug ID: 13054 Summary: Allow server-side sorting by title to ignore custom sets of articles to ignore 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: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When sorting clent-side DataTables-enhanced tables by title, it's possible to use a custom sorting algorithm to ignore articles, based on this configuration in datatables-strings.inc: var CONFIG_EXCLUDE_ARTICLES_FROM_SORT = _("a an the"); ...and the "anti-the" sorting code in js/datatables.js. This doesn't work with server-side DataTables implementations, which means that sorting by title on the circulation and patron detail pages no longer works as well as it did before those pages were redone with AJAX datatables. I would like to see some kind of implementation which continued to enable the user to define articles to exclude from sorting and would work at the database level so that AJAX datatables could be correctly sorted. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 13057] New: Empty library dropdown in funds header search on some budgets and funds pages
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '14

09 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13057 Bug ID: 13057 Summary: Empty library dropdown in funds header search on some budgets and funds pages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org The funds header search include is used by the Budgets, Funds, and Planning (admin/aqplan.pl) pages. It has an option for limiting by library, but the library data it requires seems to only be provided by the Funds (aqbudgets.pl) summary page. In addition, if the dropdown is populated by any library data it appears to only show the branch the current user is logged in as, even if you submit a search with "show my funds only" unchecked. I don't see how that limitation is useful. Should the full list of libraries be shown at all times, or perhaps just libraries for which funds are defined? If the latter, should this data be added to all pages which include this filter? Or should the library selection dropdown be hidden when there is no library data to populate it? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 13034] New: Print summary does not print items checked out
by bugzilla-daemon＠bugs.koha-community.org 09 Oct '14

09 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13034 Bug ID: 13034 Summary: Print summary does not print items checked out Change sponsored?: --- Product: Koha Version: 3.16 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: eugenegf(a)yahoo.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Created attachment 32031 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=32031&action=edit Koha 3.12.5 In newer version of Koha ILS 3.16.3, 3.16.4 and when 'Print Summary' button is clicked, the checked out items does not show in the Account Summary. First attachment is Koha 3.12.5. While second attachment is 3.16.4. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 13047] New: SQL Last Run
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '14

08 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13047 Bug ID: 13047 Summary: SQL Last Run Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It would be helpful if we could see the last run dates on the saved sql reports so we can easily see what isn't being used. Christopher -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 13045] New: not for loan items show hold option
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '14

08 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13045 Bug ID: 13045 Summary: not for loan items show hold option Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 32072 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=32072&action=edit no hold link See attached. An item that is marked as not for loan is showing the hold link on the search results, but not on the detail page. The detail page is right, the results page is not. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 7712] New: a single holds report
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '14

08 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7712 Priority: P5 - low Change sponsored?: --- Bug ID: 7712 CC: gmcharlt(a)gmail.com Assignee: koha.sekjal(a)gmail.com Summary: a single holds report QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: melia(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha Koha currently has two holds reports: Holds to Pull and Holds Queue. The difference between them is often unclear and confusing. The system shall provide a single report page to detail which materials should be pulled from a branches shelves, and where these items should be sent. -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 7711] New: clear holds statuses and workflow
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '14

08 Oct '14

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7711 Priority: P5 - low Change sponsored?: --- Bug ID: 7711 CC: gmcharlt(a)gmail.com Assignee: koha.sekjal(a)gmail.com Summary: clear holds statuses and workflow QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: melia(a)bywatersolutions.com Hardware: All Status: NEW Version: master Component: Hold requests Product: Koha Created attachment 8197 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=8197&action=edit Status Workflow Mapping Clear statuses For each hold in the system, there should be a clear, single status to describe it's current state. These statuses should include: Waiting (in holds queue) Ready to pull Pulled and awaiting pickup Filled Expired Long waiting In transit Suspended Canceled Since these statuses have concrete system states attached to them, they must be hard coded into the system. The use of an Authorized Value list would not be sufficient. Status Workflow Not every status should be reachable from every other status. Attached is a mapping of which statuses a hold shall be able change between. O with a green background indicates possible, while X with a red background indicates impossible. Grey cells are for self-references. [Please see attachment.] Holds shall be considered 'waiting in queue' until they reach the top position of the queue, at which time they change to 'ready to pull'. While in the queue, they can expire, be suspended, or be canceled. Once the hold is ready to pull, the next natural next step for the hold to transition to the “Pulled” state, where it awaits being picked up by the patron. Since this status just means the hold is at the top of the queue, if the queue is rearranged, the status of the hold could go back to 'Waiting in queue'. The hold can also expire, be suspended or be canceled. After the hold is pulled, it should either be picked up by the patron and marked as 'filled', or put 'in transit' to the pick up location. It can also still expire or be canceled. If the hold waits to be picked up for more than appropriate MaxReservePickupDelay circ rule, it will be marked as 'long waiting'. If a hold needs to be transferred to another branch, the status shall go from 'Ready to Pull' to 'In Transit'. Once the item arrives at it's destination and is received, it shall be marked as 'Pulled and ready for pickup' Expired, Suspended and Canceled holds can be brought back into the queue. “Filled” is a terminal status; the hold record can now be archived. -- You are receiving this mail because: You are watching all bug changes.

1 7