Internal Event Management

Tracker Integration

Event access/management, the core function of the tracker, requires different levels of access and views for each member on a per-event granularity. The presentation of this function must adequately reflect the role of the techie viewing an event. These include:

• Request Routers – Person(s) who receive notification of all new event requests and assigns an event to a member. Should see, by default, all pending requests and maybe other assigned requests that are still pre-quote)
• Event Administrators – Typically the TiC and anyone else granted admin rights to all events (see note). Should see all pending events to which he/she is an administrator.
• Members – All techies should be able to see published events and those details currently in the schedule file.

Finance administrators and Equipment managers do not have a specialized view within event management, as they have entirely specialized sections for their fulfillment of that role. Additionally, it’s likely that they will also be event administrators for some events separate from their finance and equipment manager roles.

Event Management Views

Listing/Viewing/Administering

Events Listing: The event administrator view and the membership view can be combined and presented in the same section with different dividing titles. (e.g. “Your upcoming TiC events”, “Your Upcoming Events”, and “Other upcoming events”)

Event View (members): Members should be able to request roles, add notes, and confirm attendance.

Event View (administrators): Administrators should be able to modify event details as specified below (see Event Administrator Information). They should be able to generate mail soliciting members to confirm/request roles or contact the organizer. They should also have access to view/modify a special section called the TiC Sheet containing:

• Organizer contact info
• Equipment checklist
• Truck pack
• Channel list
• Rigging plot
• Pricing list

Request Routing Interface

For Request Routers, the default is to render the same view as above. There should be a link to an additional separate section dedicated to the routing interface. The link to the routing interface should only appear when the user is designated as a Request Router.

The routing interface should default to a listing of pending event requests, a quick delete button with confirmation (for obvious spam) and if they have any notes attached by other Event Routers. Viewing an individual request should allow the router to be able to assign a TiC/admin, delete the request, merge the request with another, or create a note for other event routers to see.

Event Request Process Flow (internal perspective)

• Organizer requests event through form (see External Organizer Interface)
• Request Router (see Internal Role & Membership Management) assigns an event administrator/TiC or decides if anyone/who outside of exec should have read access to this original request. Event status is changed to assigned.
• Event Administrator (usually the TiC, see Internal Role & Membership Management) manages the event and details henceforth

Request Router Information

Received from organizer

• Title
• Organization
• Primary Contact, Phone, & E-Mail
• Event Date(s)
• Event Location(s)
• Specific Needs/Comments
• Payment method
• Status (automatically categorized as request)

This is taken from the External Organizer Interface)

Modified by Request Router

• Event administrators
• Status (changed to assigned)
• Request Routing notes (do not persist)

Event Administrator Information

Received from Request Router

• Everything from Request Router except R. R. comments, which get flushed in the transition from Request to Event.
• Event requests should be treated as separate entities from events

Modified by Event Administrator

• Quote
• Status
• Other event administrators
• Equipment
• Roles
• Published status (changing status to “confirmed” should auto prompt for publish)
• Close event and send to finances manager for invoicing