Events Package Overhauling Plan

This is some speculation on what would make EventsPackage better

Created by: Will, Last modification: 14 Jun 2007 (20:37 UTC) by laetzer
Events are a complicated thing. This page is a resource for brainstorming and planning a professional events package for bitweaver. Please feel free to append ideas, resources, or whatever else may make an events package better.

While this page defines the needs or a possible new implementation for an event calendar system, also have a look at CalendarResearch for an evaluation of existing solutions.


People Thinking and Working On This

If you want to join the fun on a very dedicated level so as to see implemention of this through to reality, add your name or handle here with a method of contact.
wjames5: wjames5-at-nyc.rr.com
michael dean: mdean@sourceview.com
phoenixandy: andy at andystanford dot me dot uk

Big Issues

  • Event Recurrance
    See the first comment by James at the bottom of this page
  • Invitation and Viewing Permissions Management
  • Notification Management

Possible Table Changes

EVENTS TABLE

event_id
content_id
title - Liberty Package
body/data - Liberty Package
description
start_time
end_time
recurance (will take a stringe of days 0-7, weeks, months, years)
location (text)
lat - Geo Package
lng - Geo Package
category - Pigeonholes Package
comments - Liberty Package
invite_guests - T/F
image
url
permissions - Liberty Package

GUESTLIST TABLE

event_id
name
email_address
status

NOTE: The above tables include fields which might be covered by other packages and thus not really be in the table. They are noted with their dependent package.

Additional References


Comments

questions

by James Thompson, 25 Sep 2006 (22:22 UTC)
How will you input events that start at sundown?
Especially if they repeat, the time will change every day.

recurance is a complicated issue to handle things like:
First and Third Thursday each month
Second Wednesday every other month
See RFC-2445 for one approach: http://tools.ietf.org/html/rfc2445

How will Daylight savings be handled? Example an event scheduled for 11AM localtime each day. If you convert this to UTC when storing, then when daylight svings starts/stops, the localtime corresponding to the UTC time will move and the event will no longer show at 11AM localtime.

Some events will have multiple dates associated with them, perphaps the event times should be in a separate table? Or force user to enter as multiple events?


Re: questions

by WaterDragon, 03 Jan 2009 (10:24 UTC)
Sundown will not be supported but the plan is to support almost anything supported by RFC-2445 via a separate times table as you point out. This is in the current events schema but there is no UI for that part yet.

events linked with rooms

by sourceview, 07 Nov 2006 (18:04 UTC)
In the late 80's we produced a software package in "visual basic" entitled Facilities Master. This was a very good program that handled events, recurring events, rooms for the event, rental fees, equipment ordered, invoicing, etc. It was meant for universities and the like and could handle a large number of rooms, large number of concurrent events, etc. Personally, I think handling events in this manner is superior. It not only included directions and maps, but intra-organizational maps and directions, so people wouldn't be left stranded in front of a large skyscraper or something.

Trigger System

by lugie, 07 Nov 2006 (19:15 UTC)
How similar is this package to the concept of Event Triggers?

When "X" occurs, do "Y".

X is the trigger, Y is the result of the action.

Examples:
  • When USER REGISTERS, send email to user.
  • When USER CONFIRMED EMAIL, create user blog.

I think this sort of functionality will add a whole new level to bitweaver flexibility, and I'm wondering if in-site actions can be considered "EVENTS," and if basically, the ability to respond to events internally will be included with the proposed package.

Re: Trigger System

by WaterDragon, 03 Jan 2009 (10:23 UTC)
Not similar at all. Events is intended to track calendar type events. The triggers you are looking for will be built as part of the Switchboard Package.

Some comments

by Lester Caine, 08 Nov 2006 (18:14 UTC)
Start Time is the event time that we already have.
End time may be easier to manage as duration as it will track start time then.
( I have some fun with my existing room booking system where the duration changes based on the week of the month which currently we just implement as a set of meetings one for each week of the month - what ever you plan someone will break it :) )

We need a location time zone and daylight saving flag - the new PHP5.2 stuff may handle this, but simple time zone has already been flagged as lacking, and we need some means of managing daylight saving within bitweaver.
( Calendar also needs updating with proper daylight saving flag for local time display)

Room booking system is an extension of this, but I KNOW that we need a full planner rather than the calendar display in order to make it work.

Protector is intended to provide proper group management of content. So people in one group can't see content such as an event that is assiged to a group they are not a member of.

Personally I anticipate a number of types of event module rather than trying to shoehorn everything into one. The package structure of bitweaver allows that to happen easily, and events was just a shell to get it started.