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 arsdigita.com 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.
Top
III. Events Administration
With the new design, there are three classes of users:
To better keep adcom team members in the loop, an e-mail notice is sent out to adcom@arsdigita.com
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.)
Top
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.
Top
III. New Events Sign Up
There are many e-mails to info@arsdigita.com 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.
Top
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
-- lin@arsdigita.com
--
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.
Top
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.
Top
VIII. Implementation Notes
Top
IX. Revision History
| Document Revision # |
Action Taken, Notes |
When? |
By Whom? |
| 0.1 |
Creation |
2/16/2000 |
Lin Chen |
| 1.0 |
Revision |
|
|
