]po[ Training & Event Mgmt

This "events" and training management package allows to plan and execute training events and provides advanced functionality for inviting customers, room reservation and billing.

Warning: This package is outdated and is currently not actively maintained.

(part of the ArsDigita Community System, originally by Philip Greenspun and Bryan Che)


The Big Idea

Organizations often present events, such as a lecture series or a social gathering. This software module gives organizations a way to register people for events online.

The Medium-sized Idea

Organizations often have a number of set events which they like to repeat. For example, a company may have a certain presentation which it makes over and over. A photoraphy club may hold monthly outings. A marathon race could occur annually. Therefore, we organize events in the following way:

Each organization has a series of activities that it holds. An event is a particular instance of an activity--it is the actual occurance of an activity. Each event has an organizer and takes place in a physical location and during a certain time. For example, a software company might hold a series of talks as activities:

Company Talks
  • Why you should think our software is the best
  • Why you should do things our way
  • Why the Government should leave us alone and let us innovate

That software company could then present these talks as lecture events:

Talk (Activity) Lecture Speaker (Event organizer) Lecture Date
Why you should think our software is the best billy 05-07-2000
Why you should think our software is the best stevie 08-29-2000
Why the Government should leave us alone and let us innovate billy 09-10-2000

Organizations that organize their events using this convention may then fully administer and register those events online using this module.

The Fine-details

Activities

An organization is not necessarily an entire company--it can be a company department or office or project or any other group of people. Therefore, activities are owned by ACS user groups. Each user group represents an organization of people. An activity also has a creator, a name, a description, and a flag indicating if it is available. Finally, an activity can link to a url for more information:

create table events_activities (
	activity_id	integer primary key,
	-- activities are owned by user groups
	group_id	integer references user_groups,
        creator_id      integer not null references users,
	short_name	varchar(100) not null,
	default_price   number default 0 not null,
	currency	char(3) default 'USD',
	description	clob,
        -- Is this activity occurring? If not, we can't assign
        -- any new events to it.
        available_p	char(1) default 't' check (available_p in ('t', 'f')),
        deleted_p	char(1) default 'f' check (deleted_p in ('t', 'f')),
        detail_url 	varchar(256) -- URL for more details,
	default_contact_user_id integer references users
);

Events

For each event, we need to track its organizers, its location, and its time. We define the organizers' roles and their responsibilities. We also store extra information that might pertain to that specific event, such as refreshemnts or audio/visual information. In addition, we store of which activity this event is an instance.

create table events_events (
        event_id              integer not null primary key,
        activity_id	      integer not null references events_activities,
	venue_id	      integer not null references events_venues,
	-- the user group that is created for this event's registrants
	group_id	      integer not null references user_groups,
	creator_id	      integer not null references users,
        -- HTML to be displayed after a successful order.
        display_after         varchar(4000),
        -- Date and time.
        start_time            date not null,
        end_time              date not null,
	reg_deadline	      date not null,
        -- An event may have been cancelled.
        available_p	      char(1) default 't' check (available_p in ('t', 'f')),	
        deleted_p	      char(1) default 'f' check (deleted_p in ('t', 'f')),
        max_people	      integer,
	-- can someone cancel his registration?		
	reg_cancellable_p     char(1) default 't' check (reg_cancellable_p in ('t', 'f')),
	-- does a registration need approval to become finalized?
	reg_needs_approval_p  char(1) default 'f' check (reg_needs_approval_p in ('t', 'f')),
	-- notes for doing av setup
	av_note		      clob,
	-- notes for catering
	refreshments_note     clob,
	-- extra info about this event
	additional_note	      clob,
	-- besides the web, is there another way to register?
	alternative_reg	      clob,
        check (start_time < end_time),
	check (reg_deadline <= start_time)
);


-- where the events occur
create table events_venues (
       venue_id		  integer primary key,
       venue_name	  varchar(200) not null,
       address1		  varchar(100),
       address2		  varchar(100),
       city		  varchar(100) not null,
       usps_abbrev	  char(2),
       postal_code	  varchar(20),
       iso		  char(2) default 'us' references country_codes,
       time_zone	  varchar(50),
       -- some contact info for this venue
       fax_number	  varchar(30),
       phone_number	  varchar(30),
       email		  varchar(100),
       needs_reserve_p	  char(1) default 'f' check (needs_reserve_p in ('t', 'f')),
       max_people	  integer,	
       description	  clob
);

This data model also contains extensions for selling admission to events, althought the tcl pages do not currently implement this feature. These extensions can tie in with the ecommerce module.

create table events_prices (
    price_id            integer primary key,
    event_id            integer not null references events_events,
    -- e.g., "Developer", "Student"
    description         varchar(100) not null,
    -- we also store the price here too in case someone doesn't want
    -- to use the ecommerce module but still wants to have prices
    price		number not null,
    -- This is for hooking up to ecommerce.	
    -- Each product is a different price for this event.  For example,
    -- student price and normal price products for an event.
--  product_id          integer references ec_products,
    -- prices may be different for early, normal, late, on-site
    -- admission,
    -- depending on the date
    expire_date	      date not null,
    available_date    date not null
);

Organizers

Each event should have at least one organizer role. An organizer role is an official position for that event. For example, a lecture might have the organizer role of "speaker." Organizers are people who fill an organizer role position.
create table events_event_organizer_roles (
       role_id			integer
				constraint evnt_ev_org_roles_role_id_pk
				primary key,
       event_id			integer
				constraint evnt_ev_org_roles_event_id_fk
				references events_events
				constraint evnt_ev_org_roles_event_id_nn
				not null,
       role			varchar(200)
				constraint evnt_ev_org_roles_role_nn
				not null,
       responsibilities		clob,
       -- is this a role that we want event registrants to see?
       public_role_p		char(1) default 'f'
				constraint evnt_ev_roles_public_role_p
				check (public_role_p in ('t', 'f'))
);

create table events_organizers_map (
       user_id			   constraint evnt_org_map_user_id_nn
				   not null
				   constraint evnt_org_map_user_id_fk
				   references users,
       role_id			   integer
				   constraint evnt_org_map_role_id_nn
				   not null
				   constraint evnt_org_map_role_id_fk
				   references events_event_organizer_roles,
       constraint events_org_map_pk primary key (user_id, role_id)
);

Registrations

For each person who registers for an event, we record a bunch of information. This helps the organizations understand who is coming to their events and why. It also helps the organization accomodate its attendees' needs and group them together.

We organize registrations in the following way: a registration represents a person who has expressed interest in attending the event. There is one registration for each person who wants to attend. Registrations can have different states. For example, a registration may be wait-listed because there are already too many registrations for a particular event. Or, a registration may be canceled.

An order is a set of registrations. Typically, when a person registers himself for an event, he will create one order containing his single registration. But, there may be an individual who wishes to register multiple people at once. In that case, the individual would make one order containing multiple registrations. Thus, this data model allows people to make multiple registrations. The tcl pages do not yet implement this feature, though.

create table events_orders (
       order_id		integer not null primary key,
--       ec_order_id	integer references ec_orders,
       -- the person who made the order
       user_id		integer not null references users,
       paid_p		char(1) default null check (paid_p in ('t', 'f', null)),
	payment_method	varchar(50),
	confirmed_date	date,
	price_charged	number,
	-- the date this registration was refunded, if it was refunded
	refunded_date	date,
	price_refunded	number,	
       	ip_address	varchar(50) not null
);

create table events_registrations(
        -- Goes into table at confirmation time:
	reg_id		integer not null primary key,
	order_id	integer not null references events_orders,
	price_id	integer not null references events_prices,
	-- the person registered for this reg_id (may not be the person
	-- who made the order)
	user_id		integer not null references users,
	-- reg_states: pending, shipped, canceled, waiting
	--pending: waiting for approval
	--shipped: registration all set
	--canceled: registration canceled
	--waiting: registration is wait-listed
	reg_state	varchar(50) not null check (reg_state in ('pending', 'shipped', 'canceled',  'waiting')),
	-- when the registration was made
	reg_date	date,
	-- when the registration was shipped
	shipped_date	date,
	org		varchar(4000),
	title_at_org	varchar(4000),
	attending_reason  clob,
	where_heard	varchar(4000),
	-- does this person need a hotel?
        need_hotel_p	char(1) default 'f' check (need_hotel_p in ('t', 'f')),
	-- does this person need a rental car?
        need_car_p	char(1) default 'f' check (need_car_p in ('t', 'f')),
	-- does this person need airfare?
	need_plane_p	char(1) default 'f' check (need_plane_p in ('t', 'f')),
	comments	clob
);

Using Events

With the events module, organizations can create, edit, and remove activities. They can do the same to events and organizers. Thus, organizations can fully describe and advertise any activity event online.

Organizations can also obtain information about who is coming to their events and spam those attendees. They can review order histories to see how many people registered for a given event and why they came. In addition, they can view order statistics by activity, month, date, and order state. Finally, they can spam their own organizers to remind them about their upcoming events.

People coming to register online at a site using this module will be able to find upcoming activity events and sign up for them.

 

 

ArsDigita Systems Journal: Web-Based Event Planning and Registration

by Bryan Che

Online registration harnesses much of the Internet's power. It saves time, enhances productivity, and simplifies operations. It lowers costs. It facilitates community. It provides flexibility. Surprisingly, though, online registration provides these benefits more to event administrators than to the people who register for events.

Web-based registration does provide some measure of ease for event attendees. In addition to eliminating paper forms, Web-based registration can facilitate collaboration among registrants. It can also provide immediate feedback to people when they register. For event planners, though, online registration offers the ability to:

  • Make it easy to offer repeated events
  • Make it easy to collect, aggregate, and view registrations
  • Provide convenient means for communicating with registrants
  • Provide means for coordinating registrants
These four advantages can save event administrators a tremendous amount of work and time. Thus, even though event participants may gain from Web-based event registration, event administrators are the ones who truly profit from it.

Events Module Goals Overview

The events module has four main goals. In accordance with the fact that online events handling benefits event planners the most, these goals focus on helping event administrators. The events module aims to:
  • Simplify offering repeat events
  • Simplify handling registrations
  • Simplify communicating with registrants
  • Simplify coordinating registrants

Repeated Events

Organizations often offer the same basic event on a repeated basis. For example, ArsDigita runs a series of bootcamps each month. These bootcamps are essentially the same -- they teach the same material, last the same amount of time, and provide similar experiences. The only things that really vary are where and when these bootcamps occur. Therefore, data within the events module divides into activities and events.

An activity is a kind of event; it is the type of thing for which people register. Activities might be bootcamps or lectures or conferences. An event is an instance of an activity. An event might be a three-week bootcamp starting on June 28, 2000 in Cambridge, MA or an Oracle conference in Amsterdam from July 23-25, 2001.

By making this distinction between activities and events, the events module can help event planners avoid repeated work. For example, people who want to manage ArsDigita bootcamps need only perform all of their major planning once. They can plan what their bootcamp activity will cover, what type of information registrants need to provide, and so on the first time they plan a bootcamp. From then on, whenever they want to create an online registration form for a new bootcamp, they do not need to repeat entering information that is the same across all bootcamps. Instead, they may simply edit items specific to a particular bootcamp event -- where and when that bootcamp takes place, for example. The events module will then generate an appropriate registration form for users based upon the bootcamp's activity information and its specific event information. This process makes it quite convenient to offer events on a repeated basis.

[screenshot of order histories for different events of a particular activity]

Handling Registrations

Filling out a registration form by hand may not be terribly inconvenient. But, processing thousands of hand-written registration forms is. Therefore, offering online, electronic registration forms can save event administrators significant time. Online registration forms means that as soon as a registrant submits his application, event administrators may review the registration online without much hassle. Furthermore, they can easily view aggregate information, such as how many people have registered for a particular event. And, they may approve, deny, or mark registrations using simple point-and-click interfaces. Managing registrations online can save event planners a significant amount of work.

[screenshot of admin page for wait-listing a registration]

Communicating with Registrants

Another benefit of online registration is that it can facilitate easy communication between event planners and registrants. The events module collects e-mail addresses from each person who registers for a certain event. Thus, it can provide an interface for helping event planners do things like "e-mail all the people who attended these three conferences" or "e-mail this particular registrant to request more information about his work history." Because all registration, event, and communication information is provided through the same user interface (the Web), communicating with various event registrants is a simple task. Thus, online registration can greatly help event designers to communicate with registrants.

[screenshot of page for e-mailing registrants]

Coordinating Registrants

Because registrants have entered some personal information online when registering for an event, the events module can help event administrators organize these registrants into user groups. These groups of users can then interact with bulletin boards, calendars, and other features which the event administrator sees fit to add. In this way, event administrators can easily provide a variety of community-fostering features for people who register online. If these people had not registered online and were not entered into a database, then they would not be able to socialize, communicate, and work together over the Internet as members of the same event.

[screenshot of entrance to ACS chat rooms]

Events Module Implementation

The Data Model

The events module's data model consists of four main sections:
  • tables for managing the events
  • tables for collecting custom fields
  • tables for managing events organizers
  • tables for managing events registrants
Managing Events
Activities An organization is not necessarily an entire company -- it can be a company department or office or project or any other group of people. Therefore, activities are owned by ACS user groups. Each user group represents an organization of people. An activity also has a creator, a name, a description, and a flag indicating if it is available. Finally, an activity can link to a url for more information:
create table events_activities (
	activity_id	integer primary key,
	-- activities are owned by user groups
	group_id	integer references user_groups,
        creator_id      integer not null references users,
	short_name	varchar(100) not null,
	default_price   number default 0 not null,
	currency	char(3) default 'USD',
	description	clob,
        -- Is this activity occurring? If not, we can't assign
        -- any new events to it.
        available_p	char(1) default 't' check (available_p in ('t', 'f')),
        deleted_p	char(1) default 'f' check (deleted_p in ('t', 'f')),
        detail_url 	varchar(256), -- URL for more details
	default_contact_user_id integer references users
);
Events Information about the events are stored in the tables events_events, events_prices, and events_venues. events_events tracks data such as an event's start and end times, where it occurs, and how many people may register for it.
create table events_events (
        event_id              integer not null primary key,
        activity_id	      integer not null references events_activities,
	venue_id	      integer not null references events_venues,
	-- the user group that is created for this event's registrants
	group_id	      integer not null references user_groups,
	creator_id	      integer not null references users,
        -- HTML to be displayed after a successful order.
        display_after         varchar(4000),
        -- Date and time.
        start_time            date not null,
        end_time              date not null,
	reg_deadline	      date not null,
        -- An event may have been cancelled.
        available_p	      char(1) default 't' check (available_p in ('t', 'f')),	
        deleted_p	      char(1) default 'f' check (deleted_p in ('t', 'f')),
        max_people	      integer,
	-- can someone cancel his registration?		
	reg_cancellable_p     char(1) default 't' check (reg_cancellable_p in ('t', 'f')),
	-- does a registration need approval to become finalized?
	reg_needs_approval_p  char(1) default 'f' check (reg_needs_approval_p in ('t', 'f')),
	-- notes for doing av setup
	av_note		      clob,
	-- notes for catering
	refreshments_note     clob,
	-- extra info about this event
	additional_note	      clob,
	-- besides the web, is there another way to register?
	alternative_reg	      clob,
        check (start_time < end_time),
	check (reg_deadline <= start_time)
);

This data model contains, through events_prices, extensions for selling admission to events. The presentation pages, however, do not currently implement this feature. These extensions can tie in with the ecommerce module.

create table events_prices (
    price_id            integer primary key,
    event_id            integer not null references events_events,
    -- e.g., "Developer", "Student"
    description         varchar(100) not null,
    -- we also store the price here too in case someone doesn't want
    -- to use the ecommerce module but still wants to have prices
    price		number not null,
    -- This is for hooking up to ecommerce.	
    -- Each product is a different price for this event.  For example,
    -- student price and normal price products for an event.
--  product_id          integer references ec_products,
    -- prices may be different for early, normal, late, on-site
    -- admission,
    -- depending on the date
    expire_date	      date not null,
    available_date    date not null
);

The table events_venues retains knowledge about all the different locations in which an event might take place.

Collecting Custom Fields
One of the hallmark features of the events module is its ability to let event administrators collect customized information from events registrants. Organizations are usually interested in obtaining more than just a name and e-mail address. For example, a company might request registrants to provide their resumes. The company could do this in the events module by creating a custom field for its event called resume.
create table events_event_fields (
	event_id	not null references events_events,
	column_name	varchar(30) not null,
	pretty_name	varchar(50) not null,
	-- something generic and suitable for handing to AOLserver,
	-- e.g., boolean or text
	column_type	varchar(50) not null,
	-- something nitty gritty and Oracle-specific, e.g.,
	-- char(1) instead of boolean
	-- things like "not null"
	column_actual_type	varchar(100) not null,
	column_extra	varchar(100),
	-- Sort key for display of columns.
	sort_key	integer not null
);
Managing Organizers
Each event should have at least one organizer role. An organizer role is an official position for that event. For example, a lecture might have the organizer role of "speaker." Organizers are people who fill an organizer role position.
create table events_event_organizer_roles (
       role_id			integer
				constraint evnt_ev_org_roles_role_id_pk
				primary key,
       event_id			integer
				constraint evnt_ev_org_roles_event_id_fk
				references events_events
				constraint evnt_ev_org_roles_event_id_nn
				not null,
       role			varchar(200)
				constraint evnt_ev_org_roles_role_nn
				not null,
       responsibilities		clob,
       -- is this a role that we want event registrants to see?
       public_role_p		char(1) default 'f'
				constraint evnt_ev_roles_public_role_p
				check (public_role_p in ('t', 'f'))
);

create table events_organizers_map (
       user_id			   constraint evnt_org_map_user_id_nn
				   not null
				   constraint evnt_org_map_user_id_fk
				   references users,
       role_id			   integer
				   constraint evnt_org_map_role_id_nn
				   not null
				   constraint evnt_org_map_role_id_fk
				   references events_event_organizer_roles,
       constraint events_org_map_pk primary key (user_id, role_id)
);
Managing Registrations
For each person who registers for an event, the software helps organizations understand who is coming to their events and why. It also helps an organization accommodate its attendees' needs and group them together.

The events module organizes registrations in the following way: a registration represents a person who has expressed interest in attending the event. There is one registration for each person who wants to attend. Registrations can have different states. For example, a registration may be wait-listed because there are already too many registrations for a particular event. Or, a registration may be canceled.

An order is a set of registrations. Typically, when a person registers himself for an event, he will create one order containing his single registration. But, there may be an individual who wishes to register multiple people at once. In that case, the individual would make one order containing multiple registrations. Thus, this data model allows people to make multiple registrations. The Web pages do not yet implement this feature, though.

create table events_orders (
       order_id		integer not null primary key,
--       ec_order_id	integer references ec_orders,
       -- the person who made the order
       user_id		integer not null references users,
       paid_p		char(1) default null check (paid_p in ('t', 'f', null)),
	payment_method	varchar(50),
	confirmed_date	date,
	price_charged	number,
	-- the date this registration was refunded, if it was refunded
	refunded_date	date,
	price_refunded	number,	
       	ip_address	varchar(50) not null
);

create table events_registrations(
        -- Goes into table at confirmation time:
	reg_id		integer not null primary key,
	order_id	integer not null references events_orders,
	price_id	integer not null references events_prices,
	-- the person registered for this reg_id (may not be the person
	-- who made the order)
	user_id		integer not null references users,
	-- reg_states: pending, shipped, canceled, waiting
	--pending: waiting for approval
	--shipped: registration all set
	--canceled: registration canceled
	--waiting: registration is wait-listed
	reg_state	varchar(50) not null check (reg_state in ('pending', 'shipped', 'canceled',  'waiting')),
	-- when the registration was made
	reg_date	date,
	-- when the registration was shipped
	shipped_date	date,
	org		varchar(4000),
	title_at_org	varchar(4000),
	attending_reason  clob,
	where_heard	varchar(4000),
	-- does this person need a hotel?
        need_hotel_p	char(1) default 'f' check (need_hotel_p in ('t', 'f')),
	-- does this person need a rental car?
        need_car_p	char(1) default 'f' check (need_car_p in ('t', 'f')),
	-- does this person need airfare?
	need_plane_p	char(1) default 'f' check (need_plane_p in ('t', 'f')),
	comments	clob
);

The Presentation Pages

The vast majority of the events module's Web interface is located in its admin directory. From these pages, an event administrator can manage his events and event registrants.
The Main Admin Page
The main administration page provides a summary of current event registrations and links to the key functions he can perform:
  • Managing activities
  • Managing venues
  • Viewing order histories
  • Spamming (e-mailing) registrants

[screenshot of main admin page]

Managing Activities and Events
As previously stated, one of the goals of the events module was to facilitate repeating events through the use of activities and events. Separate admin pages for managing activities and events accomplish this goal. Furthermore, the event admin page links to pages which fulfill other goals for the events module: The event admin page links to pages displaying order-histories, helping administrators handle registrations. It also links to pages for e-mailing registrants, providing for easy communication to registrants. Finally, it links to the event's user group, letting the administrator coordinate registrants.

[screenshot of activity admin page]

[screenshot of event admin page]

One of the links from the main administration page is for managing venues. Venues are locations where events occur. Since an organization or person's events will usually take place within a certain set of venues, the events module provides a means of creating and managing these locations. Then, when an event administrator creates an event, he can easily select an existing venue for his event -- and save himself the work of typing in all the relevant information for that venue again.

[screenshot of venues admin page]

Managing Registrations
The Order History pages provide most of the functionality for managing registrations. From these pages, event administrators can view aggregated registration information and answer questions such as, "how many people registered for that event," or "how many people placed registrations on this date?"

[screenshot of order history index page]

Event administrators can also view a single registration and perform actions upon it, like approving it.

[screenshot of single registration order history]

E-mailing Registrants
When a person places a registration in the events module, he has to provide his e-mail address. This means that event administrators can e-mail groups of registrants and individual registrants from the admin pages -- perhaps, for example, to advertise an upcoming, similar event.

[screenshot of page for e-mailing registrants]

Coordinating Registrants
Because the events module is part of the ArsDigita Community System (ACS), it has access to all of the community-building features within the ACS. Each event, as explained earlier, has a corresponding ACS user group. All registrants for a particular event are automatically placed into their respective event's user group. This means that event administrators can easily provide, using other ACS modules, the ability for an event's registrants to communicate and collaborate together in a variety of ways. For example, the event administrator could add a bboard to an event's user group. Then, the individuals within that user group could post messages for each other. The link to managing the event's user group comes from the event admin page.

[screenshot of an ACS bulletin board]

User Registration
Although the power and convenience of online registration benefits events administrators the most, registrants should still find it simple to register for an event. Thus, the user interface for placing a registration is fairly straightforward. The events module tries to fill in as much personal information as possible for the registrant if he is already an ACS user of the registration Web site. Then, the user must simply provide the rest of the registration material in which the even planners are interested.

[screenshot of registration page]

Events Module Comparison

Key3Media

Because the events module focuses on enabling event administrators rather than event registrants, it offers significant advantages against most online registration offerings, which traditionally view Web-based registration as simply another way to collect registration information. Registration sites which do not offer special capabilities for event planners lose out on much of the power and efficiency that comes from offering events online. For example, Key3Media is a large company which handles online registration for a number of events, including Comdex, JavaOne, and Linux Business Expo. But, Key3Media treats online registration as nothing more than another means to collect information as part of a complicated setup for registering people.

Key3Media collects registration information for events through both paper and Web applications. Web applications go directly into a database; paper applications are entered into the database by Key3Media employees. Once Key3Media processes an application, it sends a confirmation message to the application's registrant. Online registrants receive an online confirmation, and paper applicants receive a paper confirmation.

Upon completing signups for an event, Key3Media exports all of its registration information into a file -- typically a Microsoft Excel spreadsheet -- and gives the file to another company. This company serves as a "holding tank" for the registration data and eventually passes the records to a third company. This third company may be the Key3Media client running the event or perhaps a company building a Web site for the client's event, and it uses the registration data as it wishes.

Key3Media's solution for handling event registration seems to work fine for collecting information. But, its solution does little to help event planners communicate with registrants, coordinate registrants, and aggregate information about registrants. Key3Media cannot inform a client for what other of the client's events a person has registered. Key3Media cannot help registrants collaborate and communicate. Key3Media cannot offer a centralized, unified, and integrated interface to event management. The events module, by focusing on event planners, does offer all these features in addition to facilitating easy online event-registration.

Evite.com

Although most Web sites that offer online registration do not support much functionality for event planners, there are a number of sites springing up which offer users some basic abilities to plan and organize personal functions. Evite.com (http://www.evite.com) is one such popular site.

Evite.com focuses on helping users to plan events for which they would like to invite guests. It does this by offering a simple interface for individuals to:

  • plan a series of events
  • invite people to those events
  • RSVP to events to which they are invited
  • see who is coming to their events
  • remind themselves about events
In many ways, Evite.com and other, similar sites (http://socialeventplanner.com, http://invites.yahoo.com, http://www.pleasersvp.com, and so on) understand that their sites are useful because they enable people to plan and organize events. Evite even supports, to some extent, the four goals outlined for the events module.

Evite supports repeating events as well as the distinction between activities and events. For example, a user can create invitations for a "Birthday" event and have this Birthday event repeat every year. Birthdays, then, are like activities in the events module, and the annual Birthday parties are like events within the events module. Evite.com, though, does not support creating arbitrary activities like the events module.

Evite helps users handle registrations by allowing users to setup lists of guests to invite to their events. Once a user has setup a guest list for an event, Evite sends e-mail to each person on the user's guest list, notifying him that he has been invited to an event. Evite also allows these invitees to RSVP so that users may see who is coming to their events. Evite lacks, however, a number of the aggregation and advanced registration-handling functions of the events module. Evite also does not let users create events for which arbitrary users can register -- event registrants must first be invited.

Communicating with invitees through Evite takes place through Evite's address book features. Users may store email contacts and create groups of contacts within their address book. Then, they can send e-mail to individual e-mail addresses or to groups of e-mail addresses. This functionality seems fairly limited as it does not provide much support for communicating within the context of an event. For example, users cannot ask to e-mail "all the people who attended these three events" -- as they could within the events module.

If Evite offers limited communications capabilities, it supports even fewer community-building options. Unlike the events module, which supports a host of community capabilities through other ACS modules, Evite merely lets invitees see who else is coming to a particular event.

Evite.com and other event planning sites on the Internet are optimized to help individuals plan social events like a Memorial Day barbeque. The events module was designed to handle enterprise event planning and registration -- and is consequently much more powerful than a site like Evite.com. People may still use the events module, though, to implement something like Evite.com; its data model and Web pages intrinsically support virtually all of the functionality of Evite.

Events Module Future Features

ArsDigita has been using the events module for several months now on its own Web site (http://www.arsdigita.com/events). This module has handled thousands of registrations for lectures, bootcamps, and other activities. So far, the events module has performed well and provided event administrators with a great deal of time-saving and convenience. The module more than adequately achieves the four goals I outlined in the beginning of this article. Still, there are several key areas in which ArsDigita plans to improve this module.

First of all, the data model for the events module supports tasks which the Web pages do not yet implement. These main features are support for various event prices, support for online payment for events, and support for multiple registrations per order. Adding these features will enable organizations to charge registrants for their events, charge different types of registrants different amounts of money, and allow one person to place multiple registrations on behalf of other people.

ArsDigita also plans to expand its support of event registrations for sub-communities. The events module already allows ACS user groups to own event activities. Consequently, user groups may administrate their own events and also restrict others from administering those same events. But, this is the extent of the event module's sub-community features. ArsDigita intends to further aid sub-communities by making it possible for them to maintain their own "instances" of the events module. Thus, sub-sites will be able to offer their own, distinct registration pages and URL's as well as administration pages. An ArsDigita Boot Camp sub-community could, for example, offer its own events at www.arsdigita.com/bootcamp/events/ instead of listing its boot camps along with all the other events at www.arsdigita.com/events/.

Finally, there are some areas in the data model ArsDigita plans to re-write because they are not elegant. Foremost of these areas is how the module handles event custom fields. Currently, the data model is styled after the user group module and creates a new event_n_info table for each event. Ideally, the module would store custom information within the user_group_member_fields/user_group_member_field_map tables. But, these tables do not support enough data types for the events module yet. There are plans, though, to update these user group tables in the near future so that the events module may store information within them for registrants.

Submitted by Bryan Che

 

 

Package Documentation 

Procedure Files

tcl/activities-procs.tcl       Activity Library 
tcl/email-procs.tcl       Email library 
tcl/events-procs.tcl       Events Library 
tcl/organizers-procs.tcl       Organizer Role Library 
tcl/registrations-procs.tcl       Registrations Library 
tcl/security-procs.tcl       Events Security Library each security type has two associated procs, the can_*****_p returns a zero or one if the party requesting permission has permission in that area. 
tcl/time-procs.tcl        
tcl/venues-procs.tcl       Venue Library 

Procedures

events::activity::delete       delete an activity 
events::activity::edit       edit an activity 
events::activity::get       <code>get</code> stuffs the following into <code><em>array</em></code>: <ul> <li>name</li> <li>description</li> <li>available_p</li> <li>detail_url</li> <li>default_contact_user_id</li> <li>default_contact_email</li> <li>default_contact_name</li> </ul> 
events::activity::get_creator       get creator name and email 
events::activity::get_stats       <code>get</code> stuffs the following into <code><em>array</em></code>: <ul> <li>approved</li> <li>pending</li> <li>waiting</li> <li>canceled</li> </ul> 
events::activity::new       create a new activity 
events::email::admin_canceled       This takes a reg_id and sends the event admin (if he/she exists) a message via acs-mail-lite which tells them that this person's registration status has been changed to canceled. 
events::email::admin_pending       This takes a reg_id and sends the event admin (if he/she exists) a message via acs-mail-lite which tells them that this person's registration status is waiting for their approval. 
events::email::admin_waiting       This takes a reg_id and sends the event admin (if he/she exists) a message via acs-mail-lite which tells them that this person's has automatically been placed on the waiting list. 
events::email::request_approved       This takes a reg_id and sends the participant a message via acs-mail-lite which tells them that their reservation has been approved and the details of their event 
events::email::request_canceled       This takes a reg_id and email_body of a message and sends the participant a message via acs-mail-lite which tells them that their reservation has been 
events::email::request_pending       This takes a reg_id and sends the participant a message which tells them their reservtion is pending via acs-mail-lite 
events::email::request_waiting       This takes a reg_id and sends the participant a message via acs-mail-lite which tells them that they have been placed on the waiting list for an event 
events::event::attachments_enabled_p       are attachments configured? attachments require the attachment package mounted under events (as attach) and a row in the attachments_fs_root_folder_map with the events package_id and the desired fs instance root folder 
events::event::delete       delete an event 
events::event::edit       edit an event 
events::event::edit_event_notes       edit event notes 
events::event::get       <code>get</code> stuffs the following into <code><em>array</em></code>: <ul> <li>activity_id</li> <li>name</li> <li>description</li> <li>display_after</li> <li>city</li> <li>usps_abbrev</li> <li>venue_id</li> <li>timespan (in format specified in parameters)</li> <li>reg_deadline (in format specified in parameters)</li> <li>available_p</li> <li>max_people</li> <li>refreshments_note</li> <li>av_note</li> <li>additional_note</li> <li>timespan_id</li> <li>reg_cancellable_p (t or f)</li> <li>reg_needs_approval_p (t or f)</li> <li>pretty_reg_cancellable_p (Yes or No)</li> <li>pretty_reg_needs_approval_p (Yes or No)</li> <li>contact_email</li> </ul> 
events::event::get_creator       get creator name and email 
events::event::get_stats       <code>get</code> stuffs the following into <code><em>array</em></code>: <ul> <li>total_interested (the number of people approved, pending, and waiting)</li> <li>max_people</li> <li>approved</li> <li>pending</li> <li>waiting</li> <li>canceled</li> <li>venue_id</li> </ul> 
events::event::new       create a new event based on activity_id 
events::event::toggle_available_p       toggle event availability 
events::organizer::add_organizer       add an organizer in a role 
events::organizer::delete_organizer       delete an organizer from a role 
events::organizer::delete_role       remove org role from system 
events::organizer::edit_organizer       edit an organizer in a role 
events::organizer::edit_role       edit an organizer role 
events::organizer::get_role       retrieve an organizer role 
events::organizer::map_role       map a role (or roles) to an activity or an event 
events::organizer::new_role       create new organizer role; returns role_id 
events::organizer::unmap_role       unmap a role (or roles) from an activity or an event 
events::organizer::users_get_options       build options list for contacts 
events::registration::approve       cancel a registration 
events::registration::cancel       cancel a registration 
events::registration::edit_reg_comments       edit a registration comments 
events::registration::get       <code>get</code> stuffs the following into <code><em>array</em></code>: <ul> <li>event_id</li> <li>user_id<li> <li>user_name</li> <li>user_email</li> <li>reg_state</li> <li>creation_date</li> <li>approval_date</li> <li>comments</li> <li>package_url (includes the system url and site node url used for emailing - i.e. 
events::registration::new       create a new registration 
events::registration::waiting       cancel a registration 
events::security::can_admin_activity_p        
events::security::can_admin_event_p        
events::security::can_read_activity_p        
events::security::can_read_event_p        
events::security::can_register_for_event_p        
events::security::require_admin_activity        
events::security::require_admin_event        
events::security::require_read_activity        
events::security::require_read_event        
events::security::require_register_for_event        
events::time::to_sql_datetime       This takes a date from a form, and converts it into a format that the databases like, i.e. 
events::venue::all_parents_or_children       return ALL parent or children venues or null if there aren't any. 
events::venue::connect       connect this left and right venues together for this package. 
events::venue::connected_p       are these venues directly connected in this package? 
events::venue::connecting       return any and all connecting venues or "" or NULL (if sql_p) if there aren't any. 
events::venue::connecting_max        
events::venue::dechildize       removes the child from this parent and fixes any subtrees accordingly 
events::venue::delete       delete a venue 
events::venue::disconnect       disconnect this left venue from this right venues in this package. 
events::venue::edit       edit a venue 
events::venue::get       <code>get</code> stuffs the following into <code><em>array</em></code>: <p> <ul> <li>venue_name</li> <li>address1</li> <li>address2</li> <li>city</li> <li>usps_abbrev</li> <li>postal_code</li> <li>time_zone</li> <li>iso</li> <li>phone_number</li> <li>fax_number</li> <li>email</li> <li>needs_reserve_p</li> <li>max_people</li> <li>description (includes direction)</li> </ul> 
events::venue::in_use_p       is the venue being used? 
events::venue::make_child_of       make this child a child of this parent for this package. 
events::venue::new       create a new venue 
events::venue::venues_get_connecting_options       build options list for connecting venues 
events::venue::venues_get_hierarchy_options       build options list for 'parentizing' or 'childizing' venues 

SQL Files

sql/postgresql/events-activities-create.sql        
sql/postgresql/events-activities-drop.sql        
sql/postgresql/events-activities-package-create.sql        
sql/postgresql/events-activities-package-drop.sql        
sql/postgresql/events-attributes-create.sql        
sql/postgresql/events-attributes-drop.sql        
sql/postgresql/events-create.sql        
sql/postgresql/events-drop.sql        
sql/postgresql/events-events-create.sql        
sql/postgresql/events-events-drop.sql        
sql/postgresql/events-events-package-create.sql        
sql/postgresql/events-events-package-drop.sql        
sql/postgresql/events-orders-create.sql        
sql/postgresql/events-orders-drop.sql        
sql/postgresql/events-orders-package-create.sql        
sql/postgresql/events-orders-package-drop.sql        
sql/postgresql/events-organizers-create.sql        
sql/postgresql/events-organizers-drop.sql        
sql/postgresql/events-prices-create.sql        
sql/postgresql/events-prices-drop.sql        
sql/postgresql/events-registrations-create.sql        
sql/postgresql/events-registrations-drop.sql        
sql/postgresql/events-registrations-package-create.sql        
sql/postgresql/events-registrations-package-drop.sql        
sql/postgresql/events-venues-create.sql        
sql/postgresql/events-venues-drop.sql        
sql/postgresql/events-venues-hc-create.sql        
sql/postgresql/events-venues-hc-drop.sql        
sql/postgresql/events-venues-package-create.sql        
sql/postgresql/events-venues-package-drop.sql        

Content Pages

www/
      activity.adp
      activity.tcl Takes in an activity_id, displays the related activity to the user and shows all upcoming events for this activity.
     admin/
           activities.adp
           activities.tcl Displays a list of current and discontinued activities.
           activity-add.adp
           activity-add.tcl If an activity_id is supplied, the page will display the activity to an admin with options for modifying the event.
           activity-edit.adp
           activity-edit.tcl Allows admins to edit an activity's properties.
           activity-orders.adp
           activity-orders.tcl displays the order history of an event
           activity.adp
           activity.tcl Displays a particular activity to an admin, with options for modifying the event.
           administer.tcl This is the Site-Wide Events Administration Page.
           event-add-2.adp
           event-add-2.tcl Purpose: allow an admin to insert info for a new event, once a venue has been chosen.
           event-add.adp
           event-add.tcl Purpose: Allow an admin to select a venue for a new event, or add a new venue if necessary first.
           event-edit.adp
           event-edit.tcl Allows admins to edit an event's properties.
           event-orders.adp
           event-orders.tcl displays the order history of an event
           event-price-ae-2.tcl
           event-price-ae.tcl
           event-toggle-available-p.tcl Toggles the availability of an event.
           event.adp
           event.tcl Purpose: List one event with details, for administration.
           field-add.adp
           field-add.tcl Allows admins to select from existing custom fields
           field-create.adp
           field-create.tcl Purpose: allows admins to add a custom field to the registrations forms for the specified event.
           field-delete.adp
           field-delete.tcl Allows admins to confirm the removal of a field
           field-edit.adp
           field-edit.tcl Allows admins to confirm the removal of a field associated with the selected activity/event
           field-remove.adp
           field-remove.tcl Allows admins to confirm the removal of a field associated with the selected activity/event
           field.adp
           field.tcl Displays a list of fields Details for specific roles are one click deep.
           fields.adp
           fields.tcl Displays a list of roles Details for specific roles are one click deep.
           index.adp
           index.tcl Displays all upcoming events and the breakdown of registrations for them.
           join-groups.tcl Adds user to all user groups which own event activities.
           one-role.adp
           one-role.tcl Displays a list of roles Details for specific roles are one click deep.
           order-history-activity.tcl Display order history grouped by activity
           order-history-date.tcl Displays order-history grouped by date.
           order-history-month.tcl Purpose: Provides an overview of order history grouped by month.
           order-history-one-activity.tcl Purpose: To provide an overview of order history grouped by activity.
           order-history-person.adp
           order-history-person.tcl displays the order history of a person
           order-history-state.tcl Lists number of registrations in each state.
           order-history-ug.tcl Displays order history grouped by user group.
           order-history.adp
           order-history.tcl Present a selection of views for order history.
           order-same-person.tcl Lists registrations by one user
           order-search.tcl Search for existing orders
           organizer-add.adp
           organizer-add.tcl Choose a user to add as an organizer for an event.
           organizer-edit.adp
           organizer-edit.tcl Edit an organizer for an event role
           reg-approve.tcl Approve a Registration.
           reg-cancel-2.tcl Cancels a registration.
           reg-cancel.adp
           reg-cancel.tcl Cancel a Registration.
           reg-comments.tcl Update comments for one registration.
           reg-view.adp
           reg-view.tcl Allows users to check the status of an order/registration
           reg-waitlist.tcl Approve a Registration.
           role-add.adp
           role-add.tcl Allows admins to select from existing system roles
           role-create.adp
           role-create.tcl Create an org role
           role-delete.adp
           role-delete.tcl Allows admins to confirm the removal of a role
           role-edit.adp
           role-edit.tcl Edit an org role for either an event or an activity
           role-remove.adp
           role-remove.tcl Allows admins to confirm the removal of a role associated with the selected activity/event
           roles.adp
           roles.tcl Displays a list of roles Details for specific roles are one click deep.
           send-mail.adp
           send-mail.tcl this page allows you to sending email in bulk to event or activity registrants, it relies on the bulk-mail package
           spam-selected-events.tcl Select events to spam.
          spam/
                action-choose.tcl A page allowing admins to spam users and providing info on who spam will be sent to.
                spam-confirm.tcl Confirms sending spam.
                spam.tcl Confirms sending spam.
                spamees-view.tcl Purpose: To show an admin about to spam a bunch of people a list of all the spamees.
           venue-delete.tcl deletes a venue
           venues-ae.adp
           venues-ae.tcl Add or edit a venue.
           venues-connecting.adp
           venues-connecting.tcl Allows admins to connect/disconnect venues.
           venues-hierarchy.adp
           venues-hierarchy.tcl Allows admins to make levels of venues.
           venues.adp
           venues.tcl Lists event venues.
      event-info.adp
      event-info.tcl Displays event info
      index.adp
      index.tcl Displays all upcoming events and the breakdown of registrations for them.
      order-cancel.adp
      order-cancel.tcl Purpose: Give users the option of cancelling a registration.
      order-check.adp
      order-check.tcl Allows users to check the status of an order/registration
      order-one.adp
      order-one.tcl Registration form for an event.
      organizer.adp
      organizer.tcl Displays information about an event organizer
 
  Contact Us
  Project Open Business Solutions S.L.

Calle Aprestadora 19, 12o-2a

08902 Hospitalet de Llobregat (Barcelona)

Spain

 Tel Europe: +34 609 953 751
 Tel US: +1 415 200 2465
 Mail: info@project-open.com