englanddg
One Little Spark...
Friends and Family also left out any sort of detailed permissions hierarchy over various objects (such as tickets / ADRs / Band associations / FP+ ressies, which would have been a useful feature (considering it's a ground up rebuild) and one that could not only be applied to familes, but would be extremely useful for large groups or even TAs to use to plan trips on behalf of their clients.If they are using 1-Day tickets as 'working' files it probably explains the limitations of 1 Park for FP+ AND why AP's and Premier Passports have so many issues with the system. As the system is architected around the 1-Day ticket all the features flow from that.
Since the other media has features the default 1-Day ticket does not have there is no support for the data structures needed to support the various other features, hopping etc, non-expiry, multiple locations (DL and WDW).
This even more strongly supports the theory that design was done by TWDC executives instead of professionals.
A professional would have designed an abstract $ADMISSION_MEDIA which could inherit properties like hopping etc as each would just be a case of the $ADMISSION_MEDIA which would contain pointers to the necessary properties and only ownership/biometrics/validity permanently associated with its record type and would inherit the properties it needed to build arbitrary admission media. Of course this would facilitate upgrade/downgrade of media simply by adding and deleting properties.
It could be argued even biometrics should be a property as some media especially hard ticket parties would not require biometric validation.
That being said, Things like this show the amateurish design and design done by someone ignorant of formal design data structures, I can see the need for the 'scratch memory' but scratch memory should never affect customer records which means conversion processes are directiy manipulating customer records, Of course they need to as the last step but ONLY as the last step.
Things like this have the potential for large scale data loss with rollback only possible from tape or virtual tape so all databases are consistent at a fixed point in time.
For example...lets say a large group of 20 is going on a school trip. A simple "user assignment" of permissions (which is currently limited only to Memory Maker) would be a neat addition.
To allow the lead teacher in charge to be the "super admin" (for lack of a better term) over the other accounts, then be able to assigned detailed permissions with blackout windows, etc...so students could say...plan their FP+, but not be allowed to reserve during the blackout windows for group activities, and not be allowed to reserve ADRs (as an example).
I wouldn't expect that in v1.0 (if that's what you want to call the current system)...and the concept of the system holds promise for something like this, but that would require that the DB was designed in such a way to allow for future expansions along these lines.
As you pointed out, if the tickets are that limited, it shows not much time and effort was put into planning future expansions to the system (outside of glossy "in the future we could" sort of discussions)...which over time will end to ad hoc changes over time that hold the extreme potential to break other things...
When I saw the single tickets on my account, I knew they were a glitch of some sort. But, I'm also educated about the system and know exactly what I purchased (for the future and in the past) from Disney.
What if I wasn't like that? And I didn't question their presence on my account? And then started to make plans around those tickets only to be told at the gate when I show up they are not valid?
That's Disney setting up Guest Services to handle some very bad situations...
It's not fair to the Guests, and it's not fair to the front of the line CMs who have to catch all the flack.