FrameCal - Revision History

R E V I S I O N H I S T O R Y
Welcome to the revision history page for the FrameCal Perl script. This page will outline the changes made to the script under each revision.

VERSION 2.4.0 - RELEASED 26 APR 1999

This version cleans up some code, and adds new functionality through a new script.

	The script `fc_remind.pl` was added into the framecal directory. This script allows for emailing to notified users based upon a time increment that the administrator sets. Note that this script requires a scheduling utility, such as `cron` to run on a regular basis without intervention.
	Cleaned up the script. It now runs under `mod_perl`. In order to achieve this, `cgi-lib.pl` was removed from the script. The script now uses its own parsing subroutine that works under `use strict`. Note that both `use strict` and `use vars` are commented out in the scripts. As not everyone has access to these modules, they are commented out. They are only needed if you will be using the script under `mod_perl`, and if you have access to this, you have access to those two modules, and can uncomment them to get it running. This also required many other minor changes in the script, such as package name declarations and correct scoping in the all the variables.
	Added in information on user supplied link and category, if supplied, with any event notifications. Note that the format it takes is to include the information only if supplied, so if an email shows up without them, they weren't specified.
	Cleaned up the extra fields used in authorization. For some reason, I had hard coded some things in there to make the emails look better. This made adding new fields a bit of a pain. I went back and modified the code so it still prints out nice emails, but goes back to the ease of adding new fields, i.e., you now only have to add them to the two arrays `@auth_extra_fields` and `@auth_extra_desc` to add them to the registration form and user database.
	Moved the database directories for each calendar under the framecal directory, to keep things more centralized.

VERSION 2.3.0 - RELEASED 07 MAR 1999

This is a minor update to the code.

	The format of the event file names have been changed. Recurring events will now have an intial index number that is consistent, with an underscore and the number of the recurrence for the particular event. This will come in handy later on for deletion/modification of recurring events.
	An image is now included and if defined in the setup file, will display for all recurring events.
	A minor bug fix for those using no authorization was included that prevented events from being modified or deleted once posted.
	Added week view links at the bottom of the month. You can now see the entire week at one time by selecting one of these links.

VERSION 2.2.0 - RELEASED 12 FEB 1999

This update adds several new pieces of functionality to FrameCal, as outlined below.

	Categories have been implemented in this version, as an option. The administrator can specify in the calendar.setup file that categories are not to be used by setting the `@categories` array to `()`. If you specify categories in this array, users will be presented with options to filter the events in the calendar using a certain category, searching only in a specified category, and of course selecting a category for an event to fall under. Multiple categories can be assigned to one event at time of addition, and they will appear when filtering on any of the categories specified. Note that you can also use this feature to basically setup interlaced calendars for rooms, for example, by making the category field mandatory and setting up the categories to look like separate calendar names.
	Complex, or recurring, events are now available. In the Add Event procedures, you now have the option to specify a recurrence for the event. There are many different combinations that can be used. Please note that at this time, the events are added as independent events. Thus, modifying or deleting one event in the series of recurring events does not modify or delete the others in the series. This functionality will be added in a future release. Note that the subroutines necessary to calculate the recurring events are stored in a separate file, fc_recur.pl, which is stored in the framecal directory. There is no need to load the 6 KB of code required to calculate the dates every time the script is run, when only one subroutine in the main file needs it, and then only if a recurring event is specified. Also, a variable was added to the calendar.setup file called `$max_posts`. This value is the maximum number of events that can be posted at one time to the calendar using recurring events. This is a little protection for those public calendars that don't want someone to spam the calendar by posting an event every day for 5 years, or something along those lines.
	Improved error checking for URLs when the option for adding an external link to an event is enabled. The calendar will now recognize http, https, ftp, news, and mailto links, and will turn \ into / for those people who actually think the world revolves around Micro$oft.
	The day name for a date is now displayed when viewing events, so the format of the dates for each day is now of the form Friday, February 12, 1999.
	Modified the `&make_month_array` subroutine so it utilizes different subroutines. This enables this subroutine and the subroutines in fc_recur.pl to use some of the same subroutines for date calculations.
	It has been brought to my attention that pretty much every country in the world, except the United States, has the first day of the week as Monday, not Sunday. In order to facilitate this, I added code into the `&make_month_array` subroutine and the calendar.setup file that enables you to display calendars with Monday first, not Sunday. To switch over, you now only have to uncomment a few lines of code, and you are ready to go.
	The `$greatest_year` variable in calendar.setup has been replaced with `$num_years`. Set this variable to the number of years you would like the year selectors in the program to display. In other words, if the current year is 1999, and you set `$num_years` to 5, then the year selectors will have values of 1999, 2000, 2001, 2002, and 2003.

VERSION 2.1.1 - RELEASED 12 DEC 1998

This is a minor update to add the following.

The &modify_event_sub subroutine was getting a bit too complicated to handle via an array, so changed it completely to use variables. This also increases the robustness of the code in regards to modifications, and taking care of special circumstances such as adding additional people to notify and switching from an all day event to a timed event and vice versa.

VERSION 2.1.0 - RELEASED 06 DEC 1998

This is a minor update to add the following.

	Now, when a duration value of 0 is entered for minutes and hours, the event is treated as an informational only event, applicable to the whole day, and will be sorted and displayed at the top of each day's view.
	Each event will now display the last time it was updated in its information. The time displayed will be the server's time, with the option to put in an offset if your server is in a different time zone than your office, via the `$time_offset` variable in calendar.setup.
	The search results page no longer links with the subject for viewing the details of an event. It was brought to my attention that some people were using the subject of the event as a link to further information regarding the event, and these two links were conflicting.

VERSION 2.0.2 - RELEASED 01 DEC 1998

This is a minor update to add the following.

	The display of the details for an event was in the script in three different places, so it was converted to a separate subroutine (`&print_event`). Thus, if you need to modify your format, you need only modify it in one place.
	The display of the time for an event is now displayed as one date range, rather than two separate values, start and end.
	For printing out the javascript in the header, was using `qq##;` to delimit the printed text. Converted back to using `qq!!;`, and escaped the ! in the comment.
	Changed "AM" and "PM" to "am" and "pm" in calendar.setup.

VERSION 2.0.1 - RELEASED 30 NOV 1998

This is a minor bug fix after the release of 2.0.0. The following bugs were fixed.

	When modifying a file, the wrong id number was being passed.
	For notifications on deletion of an event, the information on the event wasn't called if there were no users to notify but the administrator wanted the notification.

VERSION 2.0.0 - RELEASED 28 NOV 1998

This is a major revision of the script, virtually a complete rewrite. Many new features were added. See below for details.

	The number of "require" files has been reduced. Since only two functions were being used in date.pl, they were moved into the main script. Also, one of the auth scripts, that contained only one function, was moved into the auth file that called it.
	Cookies have been implemented for guest logins, as an option via the `$use_cookies` variable in auth.setup. If turned on by the administrator, users will be prompted if they would like to save their login information. If they choose to, the values will be stored in a cookie, and read in automatically when they return, bypassing the login screen. To facilitate this, the cookie library from Matt's Script Archive was utilized.
	The current day is now hilited with a different color using the `$tdycol` variable.
	The user help script was modified to provide better customization. The help .txt files were also modified, and help topics were added for the new features.
	The calendar.events file is now gone. In its place, an events file will be automatically generated by the script for each year/month combination, when events are added. The file will take the format of yyyymm.events.
	The .events files now contain only base information, namely, that used to generate the month view. All other information about an event is stored in a separate text file named after the id number of the event. These files are read to display the event information.
	Old events are now trimmed automatically by setting a value in the initial query string (`&first_pass=on`) and setting a variable (`$old_events` in calendar.setup) for the number of past months to keep. See installation documentation for details.
	Multiple events can now be deleted at one time.
	Option (`$allow_links` in calendar.setup) to allow users to include a link to another web site for information on an event. These links are formatted to open a new browser automatically, to avoid frame hijacking.
	Option (`$strip_html` in calendar.setup) to strip HTML out of event posts.
	Option (`$allow_notify` in calendar.setup) to notify registered users of changes to the calendar, i.e., addition, deletion, or modification of events.
	Addition of a mini-search engine to allow users to search for events that meet user defined criteria.
	Addition of admin features to prevent users from gaining direct access to the calendar upon registration. Users can be placed in an alternate user file while awaiting approval. The administrator can then upgrade to full user status or delete them from within the script.
	Removal of admin features from main script, and creation of an admin script, since the majority of the interactions with the calendar should not involve the administrator.
	Fixes for all known bugs in the program.
	Numerous code optimizations to improve script performance.
	Increased modularization of the code, with many actions off-loaded to subroutines.
	Display of end time for an event as a time, rather than just a duration in hours.
	Option (`$use_time_zones` in calendar.setup) to use or not use time zones in the calendar.
	The authorization script variables are now in their own file, auth.setup.
	Modifications to allow Taint Checking for increased security.
	During registration, if emailing is not allowed, and generation of passwords is set, the user will now get their password via display on the screen.

VERSION 1.1.1 - RELEASED 14 JUL 1998

This is a minor update to modify how the month view is generated, to quicken response time, and to also provide better, clearer information on the events for the month.

	An index is now made for the events of a given month. Thus, the events database file only needs to be read once through, and a running total of the events for each day is kept.
	The number of events for a day are displayed in each cell of the calendar that has events.
	The variable `$evntcol` was added to the setup file, which will be used as the color to use as the background color for cells that have events, to make them stand out better on the page.

VERSION 1.1.0 - RELEASED 27 JUN 1998

This is a minor update to add a little functionality and clean up the script a little bit.

	Converted printing out of the help link on each page to a subroutine (`&help_link`).
	Changed sort routine to sort by year, then month, then day, then time, which also eliminates the need for the `$field_num_time` variable, and so removed it from the setup file. Also, since the sort routine is called twice in the calendar, I made it into a subroutine (`&sort_events`).
	Standardized on using the CgiDie subroutine. There were a couple of instances where the open_error subroutine was used instead.
	Went through the script and added in close commands for files that were not closed after just a read in the script. This is probably not a big concern, since Perl should take care of this, but wanted to make sure if running on a Windows system, since it is a little tempermental.
	Added a View Month link to the calendar view. This link will display all of the events, in chronological order, for the currently viewed month. This was a user request a while back, before I setup the site, and I finally got around to incorporating it. The limiting factor was sorting the events database properly, which was also accomplished in this version.

VERSION 1.0.0 - RELEASED 19 JUN 1998

This is the first release, containing the modifications from the script by Selena Sol. The following changes were made:

	Creation of a setup file for each calendar, allowing user to run several different calendars, all off of the main script, with each having a different appearance.
	Addition of Next and Previous month links on top of calendar for easy navigation.
	With the use of frames, eliminated the subject listing in the cells of the calendar, instead making only those days with events posted links in the main calendar view.
	Since only days with events are links, added the "Add Event" button to below the month view calendar, for addition on any day.
	Since events are added without a day specified after selecting the "Add Event" button, an error checking routine was added to make sure users could not post an event on, say February 30.
	Different buttons are shown in the month frame dependent upon user access level. Also, text is added to personalize a greeting to the user, display the access level to the user, and provide contact links to the calendar administrator.
	Added fields for more information on an event, including time zone, location, and duration of the event.
	Added regular expressions to eliminate any possible image tags being inserted in an event, and to remove any server side includes.
	Added variables to notify the calendar administrator of events being added to the calendar.
	Added administrative routine for calendar administrator to view all registered users on the calendar, change their access level, or delete them from the calendar. Each operation can be done for multiple users at one time.
	Added "public access" button to the login screen, so people can access the calendar without logging in on a read only basis.
	Of course, setup everything to run from a frame based page, with month view and administrative functions accessed from one frame, and event viewing an all interaction forms in another.
	Added numerous variables to customize the look of the calendar, with background and all body tag information, and special colors for heading, events, etc.
	Modified delete and modify event views so the event fits on one screen. Eliminated unnecessary fields in the table, concatenated the date and time into one field, and generally just made them more aesthetically pleasing.