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.
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.
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 |
---|
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.
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 );
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 );
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) );
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 );
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.
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:
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]
[screenshot of admin page for wait-listing a registration]
[screenshot of page for e-mailing registrants]
[screenshot of entrance to ACS chat rooms]
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_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 );
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.
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 );
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) );
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 );
[screenshot of main admin page]
[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]
[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]
[screenshot of page for e-mailing registrants]
[screenshot of an ACS bulletin board]
[screenshot of registration page]
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 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:
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.
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
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
events::activity::delete delete an activity events::activity::edit edit an activity events::activity::exists_p does the activity exist in this package instance? 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::exists_p does the event exist as part of this package instance? 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::make_event_date return a templating date type suitable for use with forms. events::event::new create a new event based on activity_id events::event::reg_deadline_elapsed_p has the reg deadline elapsed events::event::toggle_available_p toggle event availability events::event::verify_bulk_mail_reminder if bulk mail is installed, this proc will check if the given event has a bulk mail email reminder, if it does it will make update the send date to fit any changes in an events start date, if none exists, then it will create such a reminder. 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::organizer_exists_p is there an organizer for this role_id/event_id? we're not worried about being smart enough to check for an exact match - if there's an organizer in this role, we'll update (need to change logic to support many-to-one organizer relationship) 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::exists_for_activity_p does a registration for this user exist for this event? events::registration::exists_p does the registration exist as part of this package instance? 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::do_abort do an abort if security violation 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::child_of_p is this child a child of this parent in this package? events::venue::connect connect this left and right venues together for this package. events::venue::connected returns list of already connected venues 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::exists_p does the venue exist? 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::parents_or_children return all initial parent or children venues or null if there aren't any. events::venue::right_of_p is this right a right of this left in this package? events::venue::unsafe_connecting_relationship_p will there be a safe connecting relationship between this left and right venue in this package? events::venue::unsafe_parental_relationship_p will there be a safe parental relationship between this parent and child venue in this package? 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 events::venue::venues_get_options returns a list of lists suitable for use in a form
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 |
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