iCalScheduler v0.61

Help for iCalScheduler version 0.61

This is the Help section of iCalScheduler v0.61. Hopefully this will provide a good idea of whether this application is suitable or not for your needs.

Room Scheduler Help
    Getting Started - Calendar Views
        Daily View
        Weekly View
        Monthly View
        Yearly View
    Side Blocks
        Date Block
        Location and Filter Block
        Navigation Calendars Block
        Room Legend Block
    Security and Logins
    Departments and Roles
    Room Scheduling
        Adding an Event
        Deleting an Event
        Modifying an Event
    Using Filters
    Using the Wizard
        Repeating Event, Specific Datetime
        Repeating Event, Date Range
        Single Event, Specific Datetime
        Single Event, Date Range
    Performing a Search
    Creating Reports
        User Administration
        Room and Location Administration
    Technical Background
        The Database
        Security, Groups & Depts
        How Schedules are Updated
    Current Limitations
    Changes from 0.5 to 0.61
    Changes Needed for 0.61 to 0.7
The Database Implementation

This has only been tested with MySQL v4.1, so you will have to deal with problems with any other databases on your own at this time.

The database has 14 tables.

  • ics_date_range - This holds different date ranges, for example for the beginning and end of semesters. It was designed to make it so that all routines could query this table to get beginning and end dates. However, this is not consistent across files, as some files (perhaps all?) have these ranges hard coded instead. This is something that should be fixed in any future version.
  • ics_department - This is a list of the departments that a user can be part of, and has a mgr_uid that determines who is the primary contact for a given department.
  • ics_entry - This table holds all of the calendar entries that are displayed in the main calendar page.
  • ics_filter - This holds the parameters for what constitutes a filter.
  • ics_group - the permissions group that a user can be a part of. These are by default the
    • Systems Administrator - given full admin rights over all aspects of the system
    • Office Administrator - technically they are by default assigned privileges to add, modify or delete rooms, buildings/locations and filters. In practice, they are often assigned to be department administrators also. However, this is an independent setting, so that technically if they are not assigned to be department admins (i.e., their user ID is not in the ics_user2dept table) then they will have to request event reservations through email like all other non-department admins.
    • General User - given basic rights to add or edit an event (if a department admin) or to request an event (if not a department admin) and to change their password
    • Anonymous User - given no specific rights
    However, this setup can be altered to suit different circumstances by populating the tables correctly that deal with Security, Groups and Depts.
  • ics_group2permission - This table correlates the ics_group table to the ics_permission table, giving certain privileges to certain groups.
  • ics_location - This contains the fields that describe the different locations, which in many cases will be different buildings. A location or building is the container of one or more rooms.
  • ics_permission - This is a list of the possible permissions, such as the being able to add, edit or delete rooms, add, edit or delete schedules and so forth.
  • ics_pictures - This is set up for being able to have pictures of rooms. There is rudimentary correlation from the Rooms menu item for showing pictures related to a room. However, there is no interface to match pictures to a room, so it all has to be done by entering values manually into the database.
  • ics_repeat - This holds information about repeating events. The calendar does not use this directly. The calendar only reads events from the ics_entry table. The iCS software is responsible for taking the information from the ics_repeat table and loading the ics_entry table correctly.
  • ics_room - This holds all of the data for each room. An important field as far as security is concerned is the dept_id. Again, this should be called the dept_id, because it is the id from ics_department table that has managerial rights to this room. In other words, it is the id of the department that owns this room. Most of the other fields are just room attributes for this room.
  • ics_user - This holds the name, password and email addresses for all of the users of the system that can log in, as well as an anonymous login, called "user_not_logged_in".
  • ics_user2dept - This matches the user to a given department.
  • ics_user2group - This matches the user to a given group, thus giving that user a group of privileges.