A customer wanted a website with some event management that would include:
- A public, general calendar with all of the events
- A per-group calendar for each group of users that would display the group events
- The possibility for group members to create private events, accessible only to the other group members
- A per-user calendar that would display the events created by a specific user
- The possibility for users to create private events, that would be displayed only in their calendar and not viewable by any other user
I believe this set-up can be quite common for any relatively large social website, but I didn’t find any extensive documentation for it.
What NOT to do: the event and OG Calendar module
At first, I thought about installing the Event module, along with the OG Calendar module for the per-group calendars and the Calendar module for the per-user and public calendars. Turns out this is a bad idea, and there are many reasons why:
- The Calendar and Event modules don’t go together: Calendar is based on Views, while Event isn’t. Even when using Event Views, the Calendar module can not display events coming from the Event module (or I missed something, which is possible).
- The Calendar and Event modules have two different ways of displaying their calendar, which would be double work for the designer if you were to use both modules
- The OG Calendar module is no longer being maintained
Here is the list of modules I needed to realize the setup:
- CCK: obviously needed, to create a node of type Event, you should already have it installed
- Views: required by Calendar, you should already have it installed
- Organic groups: this should be part of your installation as well, if you need a per-group calendar
- Private: to allow users to create private events
Understanding Calendar and first steps
The Calendar module is smart: it uses a custom content type that you have to create (you can call it ‘event’) to display events in a calendar display. It basically adds the ‘Calendar’ style to the Views module. So basically, what you have to do is to create a content type to manage your events (which should include a date field, obviously), and then create a view to display the events.
Sean Effel, from Drupaltherapy, shows the detailed steps on how to achieve this in his screencast. Just follow the link and watch the video.
Setting up a per-group calendar
What Sean doesn’t show in his screencast however, is how to set up a per-group and a per-user calendar. If you followed the video, you should now have a public/general calendar showing all of your events.
Creating some test data
In your Drupal installation, create 4 events entitled: ‘Private user event’, ‘Public user event’, ‘Private group event’, ‘Public group event’. The idea is that, at the end of this article, you should have a public calendar displaying the ‘Public user event’ and ‘Public group event’, a group calendar displaying (when you are logged in as a group member) the ‘Public group event’ and ‘Private group event’ and finally a user calendar displaying (when you are logged in as the user who created the ‘Private user event’) the ‘Private user event’ and ‘Public user event’.
Setting up Organic Groups
If you want to have private group events, you simply have to check “Visibility chosen by author/editor …” under “Visibility of posts” in “Organic groups access configuration”. This will allow the event author to create private group events, visible only by group members.
Setting up the per-group calendar view
Go to Site building > Views > List. Select your general calendar view (which should be called calendar) and click on Clone. As View name, use ‘calendar_og’, enter a description such as ‘per-group calendar view’ and click Next.
Now I had a problem which seems to me like a bug: after you cloned the view, if you try to get a Preview of the “Calendar page” display, you will only get the Navigation bars. In order to change this, change the style plugin to “Calendar” in “Defaults”, AS WELL AS in “Year view”, “Month view”, “Day view” and “Week view”.
Then, you will need to change the Path of this new view. Select “Calendar page” > Page settings > Path and change it to ‘node/%/calendar’. Also, if you wish, set the Menu to “Menu tab” and entitle it “Calendar”.
You now need to add an argument to the view in order to tell it from which group it should retrieve the events. Add an argument of the type “Organic groups: Groups”, select “Provide default argument” and “Node ID from URL”. You can also select a “Group nodes” validator if you wish. DON’T FORGET, after you added this argument, to organize it so that the FIRST argument is the “Organic groups: Groups” one, and the second is the date argument, otherwise the view will not work.
If you go to a group page, you should now have a tab saying “Calendar” or, if you didn’t set a Menu tab, you can navigate to http://urlofyoursite/node/%gid%/calendar, and you should see a calendar displaying only the events of the group identified by the id given in the URL.
Edit the ‘Private group event’ you created earlier and make it private, using the “Organic groups” option, and it should not appear in the group calendar, unless you are logged in as a group member.
Setting up a per-user calendar
Almost the same steps can be followed in order to set up a per-user calendar, you simply have to change a few things:
- Change the name of the cloned view to something like ‘calendar_my’ or ‘calendar_user’
- Change the path of the Calendar page to ‘user/%/calendar’
- Change the “Organic groups: Groups” argument to a “User: Uid” argument and in the “Provide default argument” select “User ID from URL”. Don’t forget, once again, to put the argument first in the list
At the end of these steps, you should be able to see a calendar when you navigate to http://urlofyoursite/user/%uid%/calendar, showing only the events created by the user identified by %uid%.
User private events
In order to allow users to create private events (ie accessible by themselves only), I used a very simple module: Private. There might be some other modules that can do the same thing and more, but Private simply does the job. It allows you to let your users say whether they want a specific node to be private or not. Once the module is installed, edit the ‘event’ content type you created and, under ‘Workflow settings’, set the ‘Privacy’ option to ‘Enabled (public by default)’. This will enable a checkbox in the event creation form, allowing your users to define an event as private.
Go back to the ‘Private user event’ you created earlier and make it private. It should now only show in your per-user calendar if you are connected as the author of the event.
Conclusion: views power
Views is a very powerful module and the idea of using it through the Calendar module is great. Given that your event content type is a simple node, you can also easily add it some more things, such as geolocalization using the GMap + Location module.