events

Here's a screen mockup of "Add Event". No surprises here. I've introduced a concept of "no time" (at least I think I have) - stolen from my Palm scheduler. Obviously location comes from the "location" module. I've added a concept of "publishing location" which means whether or not the location you input shows up in the node. It would be nice if the location information could be sucked in via a filter in either the description or instructions text. "Instructions" could be detailed instructions about how to find the event, or information on how to join a call. There is also the concept of "private" - what that actually does needs to be worked out in more detail.

I'm copying out jimw's recent comments (http://groups.drupal.org/node/465#comment) to begin a separate thread.

jimw brings up a couple of issues that has been talked about at some length. Specifically he is interested in roles like "volunteer", "presenter" etc. as they relate to Events:

Here's a class diagram covering all of the classes I've discovered that would be used in the first pass. I'm sure this will change in the next few days. I'm going to break this down in subsequent posts so we can look at some of the more interesting issues in greater detail. See below:

This is the third of three sequence diagrams for the first pass at Events -

This is the second of three sequence diagrams for the first pass at Events -

This is a sequence diagram (1 of 3) that covers most of the UCs in the first pass. Sequence diagrams are useful for looking at the relationships between different classes in the system within particular Use Cases or scenarios. They are pretty straight forward and I find them pretty useful.

I've done more work to define what I think a reasonable "first pass" could look like for events. My objective is to establish end-to-end functionality, but to cut back on features so that this phase could be completed in a relatively short timeline. I have used the UCs from my original pass through and so this new diagram is a subset of the original:

Here is a first pass at documenting all of the use cases* to be touched on by the Events system. This list drew from the existing documentation that I could find and tries to be inclusive and exhaustive. I will update as people point out additions, mistakes etc.

• Use Cases are a notation meant to capture meaningful system capability from an end-user perspective. They can be used to document requirements and inform implementors as to the intent behind requirements. There are some standard ways to create and use Use Cases - but personally I feel that they are what you make of them. The image below does not contain Use Cases per se, but the titles of Use Cases. They are meant to describe the scope of the project in a way that is useful to all participants.

In a meeting today discussing the next generation of the Events systems we recognized that mail issues were a pretty big deal. We'll be working and posting specific use cases shortly. In the meantime there was a stong feeling from those present that we should coordinate all mail issues with this group.

There are two broad issues - the UI and the back-end services.

UI

• The ability to compose and deliver HTML and text emails
• A well designed UI for non-technical end-users
• Ability to drop in merge codes for personalization and common text

API

• abstracted mail delivery services
• ability to create unique tokens
• auto-generation of reply addresses

I'm sure this is an incomplete (if not mis-informed) list - but you get the idea :). Our initial question is what level of coordination do we need to have? Our assumption is that send.module does much of what we need already. What else should we be thinking about?

During our IRC meeting and phone call we came to the following list of action items:

• Define Relationships via a common API – crunchywelch
define_relationship(nid = INT, uid = INT, status_flag = STR, module_name = STR);
retrieve_relationships(array(nid = INT, uid = INT, status_flag = STR, module_name = STR));
retrieve_relationships(array(nid = ARRAY, uid = ARRAY, status_flag = ARRAY, module_name = ARRAY)); ?
retrieve_relationship(rid);
        – statusflag value = string defined within module


• Mail UI – drob – check-in with Amazon and the folks working on mail
• Mail API – drob – check-in with Amazon and the folks working on mail
• Use Cases on groups.drupal.org – drob to put up his UC titles for others comments
• Librarian - ?? - drob thought it a good idea to have a committed Librarian for all things events - however no-one volunteered
• Theme and/or helper functions that modules can use to help with theming - grugnog