VTCalendar
Home Demo Documentation Download FAQ Credits

Documentation

The software is offered under GNU LGPL. It has been tailored for the Virginia Tech community. Therefore you may have to do a number of changes to adapt it to your needs. Because of our limited resources we cannot give any support for the installation of required middleware or the calendar software itself. However, you could try the discussion forum or if you find bugs or have recommendations for improvements please use our bug reporting tool or feature tracker.

Installation Instructions

Upgrade Instructions

From 2.0.2 to 2.0.3:

Just copy the files over the existing ones (after making a backup of course). You do not need to walk through the installation process again. However, make sure you keep your config.inc.php. Last but not least you need to add the following line to the end of your config.inc.php:
define("TIMEZONE_OFFSET","5");
The number denotes the number of hours you are ahead or behind GMT. For example Blacksburg/Virginia (USA) is 5 hours behind GMT. Berlin (Germany) is 1 hour ahead of GMT. In this case you would set it to "-1".

From 2.0.3 to 2.0.4:

Just copy the files over the existing ones (after making a backup of course). You do not need to walk through the installation process again. However, make sure you keep your config.inc.php. In your calendar database run the following SQL command: "ALTER TABLE vtcal_user DROP calendarid;"

From 2.0.4 to 2.1.0:

Just copy the files over the existing ones (after making a backup of course). You do not need to walk through the installation process again. The database structure has not changed. However, make sure you keep your config.inc.php.

From 2.1.0 to 2.2.0:

  1. Backup all files of your previous installation
  2. Unpack the files of version 2.2.0 (perhaps first in a separate directory so that you minimize downtime in your production environment)
  3. Copy install/config.inc.template.php to config.inc.php
  4. Edit the config.inc.php file and adjust it to your needs (copy&paste parameters from your backup of the previous version's config.inc.php)
  5. Remove the install/ directory
  6. Run the following statements in your database:

    ALTER TABLE vtcal_calendar ADD gridcolor TEXT AFTER todaycolor;
    ALTER TABLE vtcal_calendar ADD linkcolor TEXT AFTER todaycolor;
    ALTER TABLE vtcal_calendar ADD textcolor TEXT AFTER todaycolor;
    ALTER TABLE vtcal_calendar ADD futurecolor TEXT AFTER todaycolor;
    ALTER TABLE vtcal_calendar ADD pastcolor TEXT AFTER todaycolor;

    UPDATE vtcal_calendar SET pastcolor='#eeeeee', futurecolor='#ffffff', textcolor='#000000', linkcolor='#3333cc', gridcolor='#cccccc' WHERE pastcolor IS NULL;
  7. Replace the existing files with the new ones of version 2.2.0
  8. Customize the colors using the calendar's "Update" interface

Model and Workflow

The software was designed to fulfill two distinct purposes:

  1. Serve as the main event calendar for an organization (and implement an event submission/approval mechanism)
  2. Offer calendar hosting for departments and sub-organizations (and allow event forwarding to the main event calendar)

Users, Sponsors, Calendar Administrators, Main Administrators

In order to fulfill the purpose as the main event calendar the software employs the concept of event Sponsors and one or more Calendar administrators. A Sponsor (e.g. SCUBA club) can submit events and the calendar administrator(s) approve or reject these submissions. Furthermore, a particular person can be member of more than just one sponsor (e.g. "jdoe" may be a member of the SCUBA club and the Theatre Club).

Note: All events entered by a Sponsor must be approved by a Calendar administrator. Calendar administrators may publish events without approval.

The Calendar administrator assigns persons (ie. users) to sponsors via the "Manage sponsors" menu. If user information is stored in the internal calendar database (as opposed to LDAP), the calendar administrator also needs to create a user ("Manage users") before this user can be added to a sponsor.

Users are authenticated via the internal user database or external database (LDAP). These two methods of authentication can also be combined so as to allow users within the organization to be authenticated by the LDAP and external users (e.g. civic community groups) authenticated via the internal database.

The figure below shows the typical roles of the different stakeholders.

 

The next figure shows the typical calendar workflow.


Calendar Hosting

The second purpose of the software is hosting organizational calendars. Every calendar has a unique ID. To go to a particular calendar the user would open a web address that includes a references to the calendar, for example: http://www.mysite.edu/calendar/index.php?calendar=engineering. If no ID is referenced in the URL the "default" calendar is assumed. The default calendar is the main event calendar of the organization. Calendars are completely independent from each other with only one exception. All calendars can forward events to the "default" calendar. To do so the sponsor just has to mark a check box while adding or editing an event. Each forwarded event needs approval from the administrator of the "default" calendar. Each calendar has one or more administrators and a number of sponsors.

Finally, there is the role of the main administrator. The main administrator(s) can create and delete new calendars as well as determine the administrators for a particular calendar.

Change Log

Version 2.2.0 (released April 7, 2005)
Version 2.1.0 (released October 1, 2004)
Version 2.0.4 (released April 2, 2004)
Version 2.0.3 (released Oct 17, 2003)



http://vtcalendar.sourceforge.net/
Last modified: June 20, 2005

web hosting kindly provided by SourceForge.net Logo