Conflict Checking Problems

- The conflict grid show 10 conflicts. Are there 11 reservations (including the one you are editing) during that time?

There were 12 Reservations total (No Spare/Reserve items for that bucket)

- Of those reservations what are their statuses? Confirmed, Checked out, etc. Also which ones have items assigned? Listing each reservation like ...

10 were checked out. 2 were confirmed. the 10 checked-out had items assigned to it, the 2 confirmed did not.

- At the time you ran across the bug were any tripods overdue? If so did checking that reservation in fix things?

At the time of the bug none were overdue.

I was able to get things sorted out in a giant, strange work around, which may shed some light. I deleted tripod 11 completely then added another item to the bucket called Tripod 13. I was able to assign Tripod 13 to the reservation. After it was assigned, I went in, edited the name of tripod 13, renaming it to tripod 11 and the reservation for tripod 13 was appropriately, automatically, updated to Tripod 11.

(before that I deleted Tripod 11, and re-added one called Tripod 11, but I was still unable to assign it with the same name.)

Hope this helps.
Thanks again.

I applied the patch and did some preliminary testing, and all signs point to success. I'll know more once the system is pressurized again tomorrow.
There's still a slight glitch where if there's a conflict at all, the date and time (both from and to) are cleared out. But that's minor.

I'll keep you posted.

Did some more testing. There is a minor problem, but better than before.
If there are two of the same bucket items reserved, when specific items are assigned for example Basic Tripod #10 and Basic Tripod #11, the Conflict box pops up with the error

"The dates and times for Basic Tripod #11 conflict with one or more existing reservations"

this is all it says, there is no grid.

I am able to make 2 separate reservations with the same user, and assign Basic Tripod #10 to one and Basic Tripod #11 to the other.
just not 10 and 11 to the same reservation.

This may be a separate issue that went undetected before, so if this needs to go to another ticket I can move it, let me know.

Thanks.

No such luck. And there seems to be even more problems now.
When I try to assign any item to an unconfirmed reservation I get

"warning: Invalid argument supplied for foreach() in /mysiteroot/profiles/openmedia/modules/merci/theme/theme.inc on line 63."

also seeing this message though maybe unrelated...
"warning: implode(): Invalid arguments passed in /mysiteroot/includes/form.inc on line 838."

and again the date field is cleared out and the reservation status is left unchanged.

We had a system meltdown yesterday and I tried to move over to our D7 install, but we saw similar problems on that too.
Much of this may be happening because we're getting hit hard and all items are going out at once,
Basically reservations are not saving once specific items are assigned and Checked Out Selected. At all.
The strange new occurrence is that no error warnings are given, and it looks like it worked until you go back to the Upcomming tab.

I could make a screen cast if you think it would be helpful.

UPDATE:

I have found the conditions that allow me to replicate the problem. If any reservation of a certain content type passes the Return by time, no more reservations with that same content type can have any items assigned (regardless to their inventory status). Once the overdue reservation is changed to "Checked-in". The previously unchangeable reservation can finally be saved. It exists in both D6 and D7.

For example:
Tripods are buckets
There are 20 items in the Tripod bucket
Reservation 1 is for a Tripod, on Wednesday, from 1pm-2pm, and the status is unconfirmed
Reservation 2 is for a Tripod, on Wednesday from 3pm-5pm, and the status is unconfirmed

Reservation 1 is assigned Tripod #11, and changed from Unconfirmed to Checked-out. This person Fails to return it on time.

At 3pm when the person w/ Reservation 2 comes, the reservation is selected, Tripod #8 is assigned, and the status is changed to Checked-Out. But when save is clicked, nothing is actually saved. What's tricky is that it looks as though it has been, but there is no green box confirming that changes have been made, and if you go to the Unconfirmed tab, the reservation is still there and when it's re-opened, none of the changes have gotten applied.

However the moment the status of reservation 1 is changed to Checked-In, Reservation 2 can be saved.
Also if the status of Reservation 1 is set to Denied, Reservation 2 can be made.

I can reproduce this over and over again. Which gives me great relief.

It works!
I gave it a pretty thoroug run through and all conflict checking is working. Also saving when items are overdue is now possible.
I will keep testing and let you know of any developments.

I also used the v6 patches on the v7 code and it seems to work fine.
it will, however, return the error message

Warning: array_key_exists() expects parameter 2 to be array, null given in merci_validate_merci_selected_items() (line 111 of sites/all/modules/merci/includes/api.inc)

Thanks again.

That'll do!