Let me paraphrase Tom,
Calendar is in extremely bad shape.
Among its problems are the fact that a cal_item is subtyped from an event and is a primary key. Thus insuring that you can't easily share events with multiple calendars.
The granularity is at the calendar level not the item level. This is plain wrong, and I am working on a fix for it.
Here is a scenario, suppose you want to use the calendar to do some scheduling of maintenance at offices. You don't have employees to do the work, but you hire contractors. So every contractor has their private calendar and the project has a calendar and each office needs their calendar. So you set up a project that is, for example, replace all alarm keypads at all the offices in the Southern Florida region.
Now, you have scheduled each office with a contractor to do this job. Since more than one contractor is working on the project we want the contractors to only see their jobs on their calendars. This rules out making the project calendar public. Also, we don't necessarily want the offices seeing other offices information.
So the options are:
- Create some seperate mapping tables and insert the cal_item_id (acs_event_id) into these tables as well as the cal_item. This allows us to at least use some of calendar, but not the calendar UI as it won't find the cal_item on that calender and it isn't public (group calendars won't work either, remember privacy).
- Insert the event into each parties calendar, thereby making sure that your data integrity will get hosed.
Both options are not good.
One easy (though probably not ideal) solution is to add a new surrogate primary key to cal_events and take the primary key constraint off of cal_item_id. This would allow multiple calendars to map to the same event.
I haven't looked through all the code to see what ramifications that would have, but it is the simplest that I could think of to fix the existing calendar. A complete rewrite could probably find better solutions.
