I have just purchased a copy of the cc calendar SE. My first reaction is "Woh". I have never seen such a complicated relationship diagram.
In our implementation, we do not allow booking of the same resource at the same time. I need to implement checking for conflict before commit. Following your instruction in the About, I am suppose to test for a record being present in AppointmentsDailyConflicts...and so on .I was stuck at this point and I could not seem to get this to work.
Appreciate you can show me how?
Thank you very much
Checking for conflict *before* exit
2 posts
• Page 1 of 1
|
|
Posts: 2764
Joined: Thu Nov 20, 2003 11:01 am |
Sure.
Below you'll find an edited version of the "Edit Appointment - Continue" script which checks for conflict before allowing you to leave the Edit Appointment Mini Window. The new content in this script can be found between the comments "Begin Conflict Test" and "End Conflict Test" near the middle of the script. Enter this content into your script in the same place and you'll be all set. You may want to read the description which follows as it describes how to broaden the calendar's definition of a conflict- something I think you may want to do. Here is what this script is doing. First, we look into the AppointmentsDailyConflicts relationship to see if there are any records present. (This "looking" is done in the Not IsEmpty test.) This relationship is only true for records that conflict with the current record being edited. Note that this is one of the relationships you'll want to edit if you'd like to broaden the calendar's definition of a conflict. For instance, you'll see that "ApptUser" is a criteria in this relationship. That means that appointments will only be considered conflicting if they overlap, share a resource AND share a user. You can remove this user criteria to have records flag as conflicting if they simply share a resource and overlap time wise. You'll want to make the same edit to AppointmentsDailyConflictsInclusive. This relationship is almost exactly like AppointmentsDailyConflicts except that it includes the current record. That is, AppointmentsDailyConflicts omits the current record from the conflict (all records conflict with themselves, right) and we us that relationship to test for the conflict. We use AppointmentsDailyConflictsInclusive to go to the conflicting records so that users can resolve the conflict. Hope that helps, John The script...
Going Further. Note that this script does not check to see if newly created repetitions of an appointment (repeating events) conflict with existing records. To to that you'd want to write a new script which loops through the found set. Performing the Not IsEmpty test from our new content above. You'd run this new script within the one above after the Perform Script [ “Create Repetitions” ] step. I'll leave it to you to add that if you need it. John Sindelar
SeedCode |
2 posts
• Page 1 of 1
Who is online
Users browsing this forum: No registered users and 3 guests