ArsDigita Archives

Events Module Rework Detailed Design

by Lin Chen

I. Introduction

User Pages of this module

The main focus of the re-work is to make the user inferface simpler and easier to use. It also includes adding a few new features. The existing data model and code are preserved. The major changes of the re-work are described in the following sections:

II. Event Structure

Previously, there were three layers: user groups, activities and events. In the index page of the events user pages, all events are listed grouped by user groups. The new design is to reduce to two layers: event types and events. No data model change is involoved here. The event type is just the former activity. The user group layer is still there but user will never be aware of it. All event types are created with owning user group of "Employees". This happened behind the curtain. There is no user group displayed in the user interfaces.

The advantage of doing this is the simplicity. Now, when an event admin comes to create a new event, she just need to pick the type and fill in the event info. It's more straight forward. The disadvantage is we lose one layer and the access control can't be as granular as before. The argument is that for site, it's important to have a central control of what is published on the events page. So it's better to have all events be under one group and go through the same approval procedure.


III. Events Administration

With the new design, there are three classes of users:

  • Registered Users
    Registered users have access to user pages under /event/. They can view the list of current ArsDigita events, external events; view the details of a event; register for a event (may subject to approval); cancel the registration made by oneself.
  • Employees
    Besides having all priviledges a registered user has, an employee can create events, event types, and venues. Also an employee can administer the events created by herself or the events which she is the contact person of, which includes:

    • Edit the event properties
    • View registration status
    • Spam registrants

    But the events created by an employee are subject to approval from an Event admin. Before the new event being approved, it will not be displayed at user page /event/index.

  • Event Admins
    This class of users include the member of "Events Administration" group, as well as the site wide admins. Besides all the priviledges the employees have, this class of users can admin all events, approve new events.

To better keep adcom team members in the loop, an e-mail notice is sent out to each time a new event is published. (If the new events is created by an events admin, then the notice is sent when it's created. Otherwise, the notice is sent when it's approved by an admin.)


IV. Non Registered Users

There have been discussions about whether to allow non registered users register for our events. There are arguments either way. Taken into accouts both factors:

  • It is important to allow some events be offered to non-registered users,
  • Handle non-registerd users in event module is a pain

The following method is taken. Each event has a property called "register url". The creator of the event can choose not to use the registration form generated by the events module, instead provide a link to the custom event registration form. The custom event registration form can easily be generated using survey module. (For example, webseminar page.) So even though all registration forms generated by events module requires registration, people can create their own registration form and make it available to public. In the event info page, if the "register url" field is not empty, then it will be displayed to users for registration instead of the system generated one.


III. New Events Sign Up

There are many e-mails to asking about bootcamp, etc. So one of the requirements is to provide a sign up page so registered users can sign up for e-mail alerts of upcoming events, news.

The approach taken is to create a new group type "News & Events Alert", then create three groups under this type.

  • ArsDigita News
  • ArsDigita Bootcamps
  • ArsDigita Events

On the sign up page, users can check one or more options. Then the users will be added to corresponding groups.

The advantage of doing this way is that users can go to page /spam/spam and change their e-mail alert elections at one place.


VI. Data Model Change

The original data model of the Events module is used. More columns have been added for addtional features. An upgrade sql script is provided.

-- /www/event/upgrade.sql

alter table events_events add (
        event_name varchar(400),
        event_desc varchar(4000),
        approval_date date,
        register_url varchar(400)

update events_events e
set event_name = (select short_name from events_activities a
                  where a.activity_id = e.activity_id),
set event_desc = '(select description from events_activities a
                  where a.activity_id = e.activity_id)',
set approval_date = sysdate;

Each event has a name. On the user index page, all current, approved events have names, time, places listed, grouped by event types.


VII. Tcl Procedures

This is only one new tcl procedure which is defined in file "events-defs-2.tcl" under /tcl.

  • events_is_admin_p
    This proc takes three parameter
    • user_id
    • event_id default 0
    • external_p default 0

    1 is returned if the user_id is a site-wide admin or events admin. If event_id is passed in, then if the user_id is the creator of the event, 1 is returned. If external_p is passed in as 1, then the event is treated as if it's an external event. 0 is returned otherwise.

    Please note that external events are stored in a different table than the arsdigita events.


VIII. Implementation Notes


IX. Revision History

Document Revision # Action Taken, Notes When? By Whom?
0.1 Creation 2/16/2000 Lin Chen
1.0 Revision