Skip to content

Spark System White Papers

Asaf Azulay edited this page Nov 20, 2017 · 9 revisions

Spark Modules

The Spark is the main BurnOS kernel. It allow to manage a full Burn event: Managing Users, Tools for managing communities and ticketing/gate management.

User Management

The spark manage all the Burn Organization users. The Authenticate method is done thru external systems that holds the burn profiles (on MIDBURN event, the drupal billing system is the main profile system).

The Flow

  • Once a user is logged into the system, the spark check for password authentication on the external authentication server.
  • If user logged, we will search for him on the spark db, if not exists, we will create a new profile on the spark dbs.
  • The user regards his permissions, will have the right modules to be displayed, with data referenced the current event id.

Modules & Permissions

Event Manager

The Event manager, is an editor to manage the events and its properties. Each burn event has a start date, and end date, and additional parameters of the groups

  • Create a new event Setting event properties:
    • Event name
    • Event start time, event end time
    • Tickets id for events
    • Enable/Disable group type for events.
      • Camps Groups
      • Department Groups
      • Art Installation Groups
    • Start date + end date to create new Camps
    • For each group, files schema for upload, and date + time to upload.
    • Define group types: Camps / Department / Art_Installation

The Gate

  • Gate - Module is active to any user who has GateAdmin flag and for events that has gate.

    Gate module synchronize the tickets from the billing & profile datasource, and register the ticket within the ticket code to its event. It allow to ticket-in and ticket-out users, and to limit user event entrance by early arrival limits. Gives statistics about the event: number of burners in the event, hourly and 24 hours statistics.

Spark Communities (Groups)

  • Theme Camps - Module is active to any logged user and for events that has camps.

    For users, they can do the following:

    • See the available camps, and send request to join.
    • Register to a camp and see Camps activities and members information (if allowed by Camp Admin)
    • Access to public camp files, like shared documents link etc.

    Each camp has one or more admins, that has the options:

    • To edit the camp properties (information about the camp)
    • Send users join requests, or approve users
    • Watch Camp members information.
    • Assign Early arrivals [optional]
    • Assign Suppliers [not implemented yet]
    • Upload requested files about the camps (Safety Books, Camp Designs)
    • Copy camp information from old events camps. [not implemented yet]
    • Create a full activity calendar within the community. Activities can be public or private. [not implemented yet]
  • Theme Camps Admin - Module is active to user who has CampsAdmin flag and for events that has camps. User can be only in one Camp at a time. These Modules allow the Camps Admin to do:

    • See all the Camps, and edit their properties as Camp Admin.
    • Disable and Revive camps.
    • Edit special properties for camps, like position on map, amount of early arrivals and amount of maximum camp members.
    • Edit event camps properties: Registration time, File slots & upload/download times.
    • Execute reports regard Camps statistic, how many in event information.
    • Search for users within camp.
  • Production Departments Module is active for user who is approved in at least one department, and the event has departments.

    The production management works the same as Theme Camps, with some different:

    • The Department Admin can add users and approve them.
    • Different properties for department
    • User Profile can be with more than one department.
  • Production Department Admin Module is active for user who has ProdDepsAdmin, and the event has departments.

    The Production Departments Admin, works like Theme Camps Admin.

  • Art Installation Module is active for user who is approved in at least one art_installation, and the event has art_installation

    The Art Installation works the same as Theme Camps, with some different:

    • The Art Installation Admin can add users and approve them.
    • Different properties for art installation
    • User Profile can be with more than one art installation
    • The Art Installation will be synced from external system, and will hold only the members structure.
  • Art Installation Admins Module is active for user who has ArtInstAdmin, and the event has art_installation flag.

    The Art Installation

  • Volunteers

  • Midburn Association

  • Theme Camps Viewer and search [IMPLEMENTED]
    The Theme Camps API is open (for camps that are public), and can be visible and searchable in external web forms.

  • Art Installation Viewer and search [NOT IMPLEMENTED]
    The Art Installation API is open (for public art installation), and can be visible and searchable in external web forms.

The DB Layer

The Spark platform on initialize, creating a db, with all of its data structures. The DB contains: events table, which hold the events information, with primary key event_id users table, which hold all the users information and properties groups table, which hold all communities data, unique by the event_id flag and community type (theme_camps,art_installation,production_departments etc) groups_members, communities members tickets table, which hold the ticket

Communities Properties

The Spark Communities has several properties:

  • PreSaleTicketQuotaAssigned - The Admin of the community type (Camps,Art,Prod etc...) has a way to update for the community how many quota for presale to be bought. After ward, the Manager of the community can set update to whom assign the Ticket (upto the quota).
  • EarlyArrivalAssigned - The Admin of the community type (Camps,Art,Prod) has a way to update for the community how many quota for early arrival we need to set. The Gate system use that info, to allow maximum of entrance on early stage to the event.
  • Position - Community position during the event