CiviCRM Community Forums (archive)

Just noticed http://forum.civicrm.org/index.php/topic,11863.0.html regarding Civi -> Outlook (I searched on "Activities", not "Activity" :S)

Still interested if anyone's tried porting the iCal feed system for Events to Activities since it was last discussed.

Will definitely share code

That's fine, we're a very small organisation also the calendar would be purely internal use. I was thinking a larger, more prominent "Share with calendar" tick box similar to Events. This could be unticked by default.

I'm also working on a view for my organisation with an 'Activities' menu, with a list like "Schedule a call", "Schedule a meeting", then "Log a past call", "Log a past meeting", etc, and "Share with calendar" would only apply for future events.

It's healthy for an organisation to have a well-populated calendar

davem - Sadly no - the idea didn't get funded in the end following an aggressive rival bid from an office calendar software merchant. I've got some fairly detailed specification notes kicking around but it didn't get to the point of actual code.

If I remember right, keeping traffic low and predictable was the main challenge, and my plan was to have two scripts:

- a cron-triggered CiviCRM extension that creates and updates a secure folder full of calendars using API searches, keeping two ical files for each member of staff: one complete calendar for reference, one calendar that is their latest update, waiting to be downloaded.
- a simple lean script with no framework overheads, sitting on the URL that the iCal client will use to sync from, that takes username and a non-sensitive passkey as $_GET parameters from the URL, validates these, and choses and returns the appropriate ical file

That way network traffic, bandwidth and server strain would be minimised while still giving ACL level content checks for each user.

It seemed like a good shared calendar option so long as people didn't mind not being able to update the shared calendar from their ical client. For us this seemed like a benefit as it kept everything within CiviCRM and it avoids the problem with remote-server based calendars with 2-way syncing of unpredictable high levels of traffic periodically jamming a network.

There's one tricky issue with the idea of using CiviCRM as the interface for a complete office calendar product: generic busy time. People will need a way to mark inane but relevant busy time like "Jo (staff) is out of the office all Thursday afternoon" or "Don't call (contact) - fishing holiday". It needs to be easy to input and to see, but it's not the kind of thing that should jam up a CRM contact's activities record. One kludgey solution I considered was having an event type, 'Busy', that is filtered from displays. There will be better solutions, but the project got canned before I could think of one.