Cafeen
DIS Veteran
- Joined
- Jul 24, 2009
- Messages
- 4,852
Warning: Nerd Alert (and book alert) in the following reply!Seems like some majorly sloppy programming. I'm really surprised they would launch the new system with such a major flaw (esp. the inability to even check for a fake/invalid reservation #!) I know video games (and most software nowadays) are beta tested by the public. If that is what WDW did in this case it was lazy and it's not really fair to punish those who found the flaw in their system for them (by cancelling their reservations).
I'm curious though how they could possibly go back and flag all of the reservations that were made before their 180 mark. Wouldn't WDW have to confirm reservation #'s, calculate 180 days from arrival and then cross reference with when ADR's were made ... for everyone that that has made a reservation under the new system. Wouldn't that be more complex than the proper code that should have been written into the system in the first place? Sounds like a big bloody mess & it makes me nervous if WDW started trying to weed out illegitimate reservations - my 180 is tomorrow! I really don't want them trying to go through and start cancelling anyone's stuff (just saying, their IT is reknowned for it's incompetence ...)
It is very sloppy programming. I'd be in serious trouble if I let something like that slip through. (I do QA and some development for a software company). The system is in public beta, so it's understandable that there are some issues, but something as simple and important as reservation validation should have been caught in pre-beta.
First off, yes, it would be more complex to retroactively find the "invalid" ADRs. It's not horribly complex, but that's because the initial validation process is pretty simple. For the initial validation, it would be a simple check that the resort confirmation number exists and the check-in date is valid. Ex:
SELECT TOP 1 ReservationID FROM dbo.ResortReservations WHERE ReservationNumber like '12345678' AND CheckInDate = 'xx/xx/xxxx'
Of course, that's not real code (well, it's real code, just not real to the Disney Resort system database), as I don't know the structure of the Disney Resort system database, but it's an idea. If the record is found, then the reservation exists and it can process forward using that ReservationID. If no records are found, the reservation does not exist and the web page should kick out an error to the user. It's a pretty simple step really.
To find the "invalid" ADRs, the system would have to compare the ADR creation date (if they don't store this, they are worse than I thought... and I don't think highly of them at all) with the Check-In date from the reservation. It's not that difficult really and the hardest bit is getting the math right (with dates it gets tricky). If it were just about any other company, I'd definitely think they'd get it right. I don't have the same confidence in the Disney development team though.
As far as it being "punishment" or not, I don't see it that way. Punishment would be not allowing those that exploited the error to make any further ADRs, removing ADRs made in error would just be fixing a problem. We don't know the ramifications of those early ADRs or even their validity in the system. Of course, as I mentioned above, were this any software team buy Disney's, I might be a bit more inclined that they'd get this part right.
For sure they could, but it's much easier to catch at the entry point than somewhere down the line. A lot depends on how the ADRs are stored in the system and whether or not they are directly tied to the resort confirmation. Up until now, they were not tied directly at all, only the ability to a) book with the +10 and b) pay with attached dining plans was stored. The actual reservation was not stored with the ADRs at all. This is proven by the fact that users could make ADRs under a resort reservation, then cancel that resort reservation without affecting their ADRs one bit.frankly I'm not certain that the 190 IS an error. I think it is more fair and an easier to understand system. Only time will tell.
We'll abide with whatever the rules turn out to be - I've seen posts of people adding fake days to the beginning of a stay to make reservations early (under the old 180 + 10). We don't do that sort of thing.
There are clearly glitches right now, so who knows WHAT the final outcome will be. If Disney doesn't honor what we did at 190 days, then we'll start over again.
Still, I think 190 is much better than 180, and easier to understand. If you are onsite, you get 10 extra days in which to make reservations.
oh, and Cafeen, I do tend to think that Disney could catch the fake reservation #s longer term. they wouldn't be a match on name, etc. They clearly released the updates too soon. My firm would be in a heck of a lot of trouble if we pulled something like that for a client, lol.
I would doubt that a large-scale back-end change was made for the V2 site as that could cause much more damage than the front-end changes we see. It would also be detrimental to the fact that people's plans change and with the competitive nature of ADRs, they shouldn't be forced to lose them all if they decide to stay somewhere else.
As to the intention, for me it's pretty clear through testing and through messaging on the website that 190 days is not intended. This is supported by the poster's experience with the phone CM stating it was a bug (of course, we all know about the level of knowledge those phone CMs actually have, so that's not taken as full confirmation or anything). I also think a change of this nature would have been announced, much like the changes from 180 to 90 to 180 were. (Maybe not quite as early or "in your face" as those were, but some sort of messaging as it's not a minor change in policy).
We'd be in a lot of hot water for releasing something with this large of a hole in it as well. We'd be in hotter water for not reverting it back as soon as the exploit was found as well. Sometimes, these things really want to make me work for their development team

I doubt it's widespread, yet. If it persists, it will be though.I really can't see Disney "punishing" those of us who made reservations early for *their* flawed system. So much easier to just fix the issue, then let all the reservations stand. I really can't imagine that the system has been flooded with those of us checking in around Thanksgiving, snapping up reservations -- after all, I never would have known to try if I hadn't checked in here.
But, maybe I feel this way just because I benefited (only by 2 days early). I'll be checking tomorrow morning for sure to make sure my ADRs are still there!
Also, like I mentioned above (way above in this book I'm writing ><), I don't see it as punishment persay. It may just be semantics though, but I just know what I would do when faced with the same situation (granted, I would have reverted back to v1 as soon as the problem became apparent). I do hope that the ADRs that were made early stick, but just be sure that you continue checking them both after the 180day mark as well as beyond that in case they do retroactively do something.
I'm sure we'll see some sort of fix or announcement soon enough. (Though, I may be holding out too much hope with their dev teams on that one). I too have sent the results of my testing over to guest services in hopes that it helps them either fix, or give confirmation on what the intended behavior should be.
ETA:
I'm right along there with youHmm, if their IT is so notoriously bad, I wonder if they would be hiring any Software QA Engineers, with about 10 years of experience....
Oh well, a disney fan can dream I suppose...
But if anyone knows where to submit resumes....

Of course, the pay may be an issue as well. Disney is not known for being a decent paying employer
