|
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.
|
