Potential issues

Jun 28, 2009 at 10:31 AM

As my company implemented a similar calendar check for several customers watch out if you have multiple calendars(=lists) and recurring events ....

Jun 29, 2009 at 1:31 AM

Hi decatec,

Are you able to elaborate on the multiple lists/calendars? I have tried it with several calendars on the same and different site/site collections and all appears to work fine.



Jun 29, 2009 at 5:17 PM

Multiple calendars are OK, the recurring items have some curious behaviour ...

Feb 18, 2011 at 12:57 AM

This is nice, but it does have an issue with recurring events under certain circumstances. If you create a weekly recurring event then create another one that occurs on a day other than your starting date, the conflict catcher won't find a problem. For example, an event that you enter to occur every Friday but you happen to be inputting it on a Wednesday will default to the current Wednesday date as the start and end time and this code won't see the Friday conflict(s).

I struggled with this in making another conflict catching Sharepoint Calendar I found on CodeProject (http://www.codeproject.com/KB/sharepoint/SharepointReservation.aspx) work. It handled all recurring events very well as long as they didn't have a cutoff date. Recurring forever and recurring a specific count are both easier to deal with than the cutoff date option. Figuring out all the different ways a recurring event is serialized has been challenging. Everytime I think I've got all permutations covered, I'll find some other odd combination during beta testing that will sneak through.

I like how your calendar is using an alert box to show the problem when a conflict is found. The Codeproject calendar uses the sharepoint error message class to deliver the news which is visually not very appealing unless I reformat that page to match the rest of my css. The alert box is a better option and less jarring to the user.