From the instructions.html, the date file is describe as:
The single night to which this record relates, format is yyyy/mm/dd.
So that being, said, does a typical use case imply that the user attempts to book the record, when booking the record, should the date field update as well as the owner field to reflect the current status is booked with the appropriate time? This sounds like a dumb question...
:roll: I know but I want to be 100% sure!
I don't think you need to update the date field, what would you update it with? The date field of the record identifies which night the room is available, not when the customer booked the room.
If you overwrite the date the room is available with the date time of booking, how would you know which date the room had reserved for?
I think reason the instructions provide the data format is that you will need to convert the string to a date to check the 48 hour rule.
"They take bookings only within 48 hours of the start of room occupancy."
Does this mean that the system should ignore/inform the user of old dates like from 2003~5 since its the year 2007 ? In other words, none of the supplied data that is given should really work because the data is from 2 years ago?
Use case A:
First record from returned search is from 2005 and now its 2007. I read the record, view it, try to book the record. what happens other then the owner field is populated with my 8 digit id if all checks are successful including this one:
Should the system allow the booking to take place? Or should it say, "No way dude, its 2007 and that's like old school. Time warping is in release 2. Bad user. No bone. Read manual"
Since the fact that in my assignment there was no requirement to support this feature, I did not take care of the 48 hours rule.
As far as I have in my mind you can find some topic regarding this issue some have implement that 48 hour rule in different ways and other colleagues just did not supported it.
I agree with Rinke that it's not a MUST requirement, but I would suggest it's a business rule that needs to be implemented. I've personally added business logic to only allow rooms to be booked within 48 hours of the start of room occupancy.
[ June 01, 2007: Message edited by: Jason Moors ]
Originally posted by Jason Moors:
I wouldn't recommend just ignoring the requirement, as a bare minimum I would include justification in my design document for not implementing the requirement.
Sure, of course you'd have to justify it in choices.txt why you ignore the rule. My justification is that operators are presumably smart enough to apply this rule by themselves, and that implementing the rule in the software would create too little flexibility. What if urlybird for example wants to change the rule to 72 hours? Hardcoding the rule doesn't seem a good idea, but making it an option which can be set goes too far beyond the scope of the project, and is not asked for. So, my choice was to just ignore.
Best regards, Rinke
It is true there was 400 point cases without the 48 hours rule, but I also saw
(enough) people falling for this reason (because they omit it - with or without documentation). I think that the best way to solve this problem is to provide a flexible 48 rule, a rule where the record availability can be changed (or switch off) by request.
but I also saw
(enough) people falling for this reason (because they omit it - with or without documentation).
Within the instructions.html it states:
They take bookings only within 48 hours of the start of room occupancy.
The word "only" exists not must.
To me this means that it's probably a good idea but not a 100% requirement. I agree with Jason that it should be documented if its not implemented. I disagree though that someone would FAIL this because they didn't implement it. I will let you homey's know how it goes after I fix my last nasty bug from hell.