From what I can gather, here are the desired outcomes of having a community google calendar for the intranet
- Quick access to entire calendar via LiSN home page (already exists)
- Ability to place single event instances in the weekly update with ability for staff to easily add a single event to their personal calendar
(2) is currently the pain point, as the steps involved are very tedious. I wonder if this should be thought of differently, either way we need to leverage the google calendar more imo.
A starting point for this might be to look into using the Google Calendar API as follows (via a Confluence macro):
- List events given a required time period. Let user choose via confluence macro data entry form and map to
timeMin
andtimeMax
filters - The macro then iterates over the list of events, grabs their eventID's and required metadata to show users, and then generates a list of HTML entries with actionable links
- A staff person responsible for create a new "Weekly Update" post simply adds an instance of the macro, provides the necessary date range information (and whatever else ends up needed) and the Upcoming Events section is drawn automatically
This might offer the following options for those actionable links:
Idea 1: Rather than go through the process of generating the .ics file, provide a link for people to add themselves as an attendee of the event. This "should" generate an email to them with an attached ics file. (obviously need to test and confirm). This could probably be facilitated by a direct link to event URL. Unless there's a fancier way via the API.
Idea 2: Explore whether there is a dynamic ics URL that google provides if one supplies the necessary information (calendar id, event id)
Idea 3: Create an ics file on the fly (see template file). The template actually isn't that bad. Not first choice, but really there are only a few bits in this that actually change.
Similar thoughts to above, but may be able to get ics files directly this way
https://developers.google.com/google-apps/calendar/caldav/v2/guide
- There may be access control/authorization concerns we'd need to deal with here.
- server side code may need to be involved here. how best to integrate that kinda thing into Confluence, while still being able to use JavaScript for the main API interaction (which Google seems to support)