48 hours rule

[Tai Hu]

I am working on URLyBird(1.1.1) which indicates that CSR only take reservation within 48 hours of start of room occupancy. I am a little confused about this. All the date value in my db file is at least 2 years ago. So if I implemented my logic based on date available field, no room will be available in my GUI. Should I just ignore this date available field and just assume customer could only book the room within 48 hours starting from today? That means I will provide a date selector in my booking GUI. If user select any date, out of the 48 hours range, I will report an error to user. Can I implement it this way? I am open for any suggestions. Thanks!

[Dalton Filho]

I think the question may not be what you can(not) do, but what you should (not) do. You should not go beyond the scope of your assignment, for your own sake. On my assignment this rule is not one of the "musts".

I was wondering if should implement the 48h rule, but I have seen people here (with 100% score) who did not implement it (which is ok as long as you justify it on your choices.txt). I'm on the final revision of my assignment and I don't plan to implement it.

[Mark Smyth]

Originally posted by Tai Hu:
I am working on URLyBird(1.1.1) which indicates that CSR only take reservation within 48 hours of start of room occupancy. I am a little confused about this. All the date value in my db file is at least 2 years ago. So if I implemented my logic based on date available field, no room will be available in my GUI. Should I just ignore this date available field and just assume customer could only book the room within 48 hours starting from today? That means I will provide a date selector in my booking GUI. If user select any date, out of the 48 hours range, I will report an error to user. Can I implement it this way? I am open for any suggestions. Thanks!

Best bet is to implement the 48 hour rule, keep a safe copy of the orignal data file and write a small program to change the dates in the file now. I did not show any record that had expired in the GUI (no point showing a room for yesterday and cluttering the display, I assumed there would be some other unspecified program to do the cleanup), but I did show rooms that were available more than 48 hours into the future, however if the user tried to book these rooms they would get an error message.

[Ken Boyd]

I think best one will be show everything when your application start. After that when use search show them records which match search values. If user select any record in UI and they are not following 48 rules just show them error message. Also make note in choice.txt that in future when CSR can add or delete record current functionality will work with little modification in UI like enabling ADD or DELETE button (in my assignment I have Add or Delete button but disable when submit it but document that in choice.txt)

I think it is good enough for 48 hours rules. If they want to book any records tester has to change dates it is not our problem. Even I have tested by changing dates on my computer (other threads also suggested the same).

Hope this helps.

[Tai Hu]

Thanks so much for your answers. I think I will just display everything initially. Then when user do a search, I will filter out the invalid ones.

[rinke hoekstra]

Tai,

first of all, the database is an example database - as Sun says. So it is quite logical that the dates are "out of date".

Then, about the rule: I choose to ignore it. Indeed, I've seen people pass with 100% score ignoring it. As long as you motivate it in choices.txt.

My motivation is that this is typically a business rule which is likely to be subject to changes in future. EarlyBird might for example decided to make it 72 hours. So it should be flexible, for a usefull aplication, and not hard coded. Then we have too choices: or make it an updatable setting, or ignore it.
As the assignments is not saying anything about application settings which can be changed by the endusers or system administrators, the best thing is to ignore it. Presumably, the operators using the application are wise enough to apply this rule without much effort, if it is not implemented in the software.

The only thing which you could do extra, if you don't feel safe about this, is to just generate a warning dialog if the user books earlier, but for the rest do nothing with the warning, and just allow the booking if the enduser wants to continue.

[Brian Kelly]

As Rinke says.

There is no requirement for this (no "must").

I didn't implement it and I passed...

[Dalton Filho]

I think it's more consistent to implement both 48h rule and date check prior to booking or neither. If no program can write to the database (assumption) and no recent records are available, would it make sense to do any kind of date checking?