General consensus regarding booking and re-booking same record

[Bill Robertson]

I am going over some nit picky details and one thing I forgot about is
whether or not a user should be allowed to book a contractor after it has
already been booked by another user. This seems pointless and totally
goes against system integrity but I know Ken did it this way and he scored
very high. I was wondering what others thought.
Example:
contractor x is booked by owner id 345 by client John. Client Mike comes
a long books contractor x with owner id 670 and no notification or anything
is sent to notify John. Client Mike just totally wipes out what John booked
and I would think John expects to see his booking the next time he longs on.
So basically I am leaning towards not letting them book a contractor once it is booked. Instead I will document they should have a managerial process in place to make a change. What does everyone else think?

[Nicholas Cheung]

Hi Bill,

So basically I am leaning towards not letting them book a contractor once it is booked. Instead I will document they should have a managerial process in place to make a change. What does everyone else think?

I also complete the assignment in this way. As the instructions do not mention the unbook function, I feel it is better not to implement it.
In my implementation, assume there are 2 clients on 2 machines, and they are in network mode. When they first load the application, record X is unbooked.
When, say, Client A books it, record X is booked and the database file is updated, however, at this moment, record X shown in Client B is still unbooked (becos the application does not "pull" the records, and the server does not "push" the updates). When Client B later wants to book it, the system checks the database file that record X is already booked, so it throws an Exception, telling Client B that record X is booked, and reflect the changes.
Nick.

[Bill Robertson]

yeah, thats how I have it exactly

[Terry Martinson]

Same with me for URLyBird.
TJ

[Ken Krebs]

I see. So it's more logical that a contractor can never be unbooked or rebooked without an administrator's intervention
BTW, the clients you mention are B & S's employees whose job it is to book contractors for their clients. They should have the option of rebooking. A warning would be more appropriate than blocking this activity completely IMO.
I stand by my contention that this is a business rule that has not been specfied by the customer and that "the simplest thing that could possibly work" is OK until the customer clarifies the rules.

[George Marinkovich]

My thoughts on booking (from least to most controversial):
1. The user should be able to book an unbooked record. I don't think anyone will disagree with this.
2. The empty string is a legitimate customer ID. It indicates that a record is unbooked.
3. The user should be able to be able to unbook a record. That is, assign the empty string as the customer ID for a record to indicate that the record is unbooked. Maybe the customer calls up the CSR and says: "My house burned down, guess I won't need that painting contractor after all." I want the user to be able to unbook the record. Deleting the record is not the right thing to do (the contractor still exists it's just that he's not going to be doing a job for this particular customer).
4. The user should be able to change a booking for a record. For instance, the user books a record for Joe Customer thinking his customer id is 10000000. Shortly after the database has been updated, the user realizes that Joe's customer ID isn't 10000000, it's 50000000. I say let the user fix the mistake.
5. Good user books a record for customer 10000000. Bad user comes along later and books the same record for customer 20000000. In other words, bad user could see that the record was already booked by good user, but doesn't care, and changes the customer ID anyway. Bad user probably doesn't use his turn signals when he drives either. but nothing in the instructions compells me to prevent bad user from behaving badly.
I accept all the above operations as legitimate. My reasons for doing so:
It's easy (least amount of work, least complexity),
Satisfies the requirements in my assignment instructions,
Doesn't contradict any specification in my assignment instructions, and
I'm willing to pay the price of 5 in order to allow the user to perform 3 and 4.
-George

[Bill Robertson]

excellent advice George!