[Bug 1774] New: New reserves do not go to end of list, but somewhere in middle
http://bugs.koha.org/cgi-bin/bugzilla/show_bug.cgi?id=1774 Summary: New reserves do not go to end of list, but somewhere in middle Product: Koha Version: rel_3_0 Platform: All URL: http://smfpl-beta.dev.kohalibrary.com:8080/cgi- bin/koha/reserve/request.pl?biblionumber=114836 OS/Version: All Status: NEW Severity: major Priority: P3 Component: Circulation AssignedTo: chris.cormack@liblime.com ReportedBy: drdrulm@yahoo.com QAContact: koha-bugs@nongnu.org If I place an item on hold/reserve when the reserve list is large or there are items consigned, the new item is not give the LAST number in the list, it is given something in the middle. For the stow install: http://smfpl-beta.dev.kohalibrary.com:8080/cgi-bin/koha/reserve/request.pl?b... This new James Patterson book has around 100 holds (in our production data), and new holds do not get set to the last number in the queue. I put a hold on for Gloria STAFF/Adams, who is given 106 in the queue, but the last item in the queue is 111. This has meant that our staff manually changes the queues for all the bibs with large queues. Notice that there are 5 items waiting in the queue and instead of 111-106 = 5, coincidence? This seems to be the pattern, that the new item is given the last number in the queue (111) minus the number of items waiting 5 = 106. However, could a MAX function be done on when grouped by BIB to find the largest number and then go one larger than that. This has not worked in Dev Week or on the new Koha 3 version but it is very much needed by staff to avoid confusion. Also some of the patrons at the end, will stay at the end of the queue forever as people take "cuts" in front of them, like a Pink Floyd concert circa 1976. ;) ------- You are receiving this mail because: ------- You are the QA contact for the bug, or are watching the QA contact.
participants (1)
-
bugzilla-daemon@pippin.metavore.com