Closed (fixed)
Project:
MERCI (Manage Equipment Reservations, Checkout and Inventory)
Version:
6.x-2.x-dev
Component:
Code
Priority:
Normal
Category:
Bug report
Assigned:
Issue tags:
Reporter:
Created:
23 Mar 2011 at 21:33 UTC
Updated:
3 Jan 2014 at 02:58 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
darrick commentedDo any of the existing reservations have a bucket item assigned? Can you write in words what each existing reservation is or send us a screenshot of the reservation table for that day.
Comment #2
kreynen commentedI was able to reproduce this with 2 DV Cameras when one reservation had an assigned item and the other didn't. Even when I assigned both to camera #1, there was still a conflict. Unselecting the specific camera from both reservations allowed me to make the reservation, but these seems like an error since camera #2 is actually available.
Doesn't this happen when using auto-assign buckets?
Comment #3
thepulsingeye commentedI think that's the exact problem.
In my example, only the reservations that are "Checked Out" have assigned bucket items. The reservations that are "unconfirmed" or "Confirmed" don't have an assigned item yet. I was able to somewhat fix the problem by assigning all of the future reservations bucket items #1,#3,#4,#5 which then opened up camera #2. I was then able to confirm a reservation for one of the cameras as intended, then I went back and unassigned items to the future reservations. The strange thing there was after they were unassigned the items in the reservation grid moved back to #1, #2,#3,#4 leaving #5 "available".
I'll see if auto-assign will make it work, but I would prefer not to use it. It's often hard to rely on students bringing things back on time, despite policy and late fees.
Comment #4
darrick commentedI doubt auto-assign will help. I'll look into this later today.
Comment #5
darrick commentedThis should be fixed in this commit: http://drupalcode.org/project/merci.git/commit/ae1b9be
What was happening was this:
Two buckets items with nid of 101 and 102.
Create two different reservations at different times for the bucket type.
Assign a bucket item with the higher nid to one of the reservations. This is key as the conflict will not happen if you assign the item with the lower nid.
Try to create a third reservation overlapping the above two and you will get a conflict.
Comment #6
darrick commentedComment #7
thepulsingeye commentedI applied the patch and it did compress the open areas, but there's still something not quite working.
For example I tried to make a reservation from 11a to 2:30p it the conflict grid popped up (pic#1). At first I thought that maybe it was trying to place that reservation in position #2 rather than realizing position #5 was available, so I filled up positions #2,#3,#4 with other reservations, but it still wouldn't allow the reservation to occur in position #5 (pic#2) even though the time slot was open.
Since then I downloaded the Mar24 dev build and I'll keep you posted on wether that solves the problem.
Comment #8
darrick commentedOkay. Thanks for checking it out. I'll look into it further.
BTW: you also found a bug with this drupal issue queue. The pound sign in your uploaded pics isn't translated to unicode. The links to your pics should be:
http://drupal.org/files/issues/pic%231.png
http://drupal.org/files/issues/pic%232.png
I posted that issue here: http://drupal.org/node/1105502
Comment #9
darrick commented@thepulsingeye I'm unable to reproduce this. What items do you have assigned to the reservations? Which reservations do not have assigned items. What are the nids of the assigned items.
Can you join the #drupal-openmedia IRC channel to help me solve this?
Comment #10
thepulsingeye commentedThe cameras are nids 401-405
In the above examples the current time was 12p let's say. Everything from earlier had items assigned items. In pic 1 the 7am-11am time was nid 404. Everything that came after had no bucket item assigned.
I updated to the current dev build and have not been able to replicate it since. I'll run in debug for a while and if it happens again post the logs.
Comment #11
darrick commented