Hi All!

I'm trying to build Meeting Scheduler over Calendar package and found many uncompleted and unconfortable things in Calendar.
I plan to add resource conflict resolving and scheduled audience notification for special types of events.

Do somebody maintains the Calendar?
I'm ready to join this group.

I also has a question realted to the cal_item_types.
Why item type is related to the calendar? It seems more reasonable to use same types for different calendars.

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.

Having a calendar item subtyped from event also means you can't extend event to create custom calendar entries, say a bugtracker event which is a release deadline by which time your assigned bugs must be fixed.

See this thread in which Ben summarizes some of the problems with the datamodel and in which someone describes how they poached then modified the datamodel for a Java project they were working on.

I think it would be nice to have the actual calendar content be a content (repository) type so one could register a template to it and control how the calendar event is displayed by the calendar package.

The project I allude to above solved issues by removing content item and adding a mapping table to map a calendar event to one or more calendars.

The existing calendar packages, sick as it is, functions well enough for many needs and while not bug-free is fairly stable. I'm inclined to think in terms of a datamodel rewrite resulting in a "new-calendar" package , i.e. to ignore the writing of scripts to upgrade from the old to new datamodel. I fear that trying to live with that constraint might hinder the design of a new, cleaner datamodel.

What do other folks think? Are some of the folks in this thread willing to work on redesigning the datamodel? I think a lot of the existing code - especially the widget and graphics code - could be poached without much effort once we have a decent datamodel.

Meeting Scheduler

I have a tarball of the old Ars Digita room reservation system if you're interested in looking at it, Denis.

I am really busy right now, but wouldn't mind helping in the design.
Whoever wants contact me and we can coordinate until we get official.

Thank's Lachlan!

As I see from discussions room reservation package should be what I actually need. Don Baccus also mentioned about it in his reply. I will try to port it to 4.6 and see how it possible to join with Calendar package.