Skip to content


Subversion checkout URL

You can clone with
Download ZIP
tree: f928bc0750
Fetching contributors…

Cannot retrieve contributors at this time

98 lines (70 sloc) 5.009 kb


This document aims to describe the design of PLAS by establishing workflows.

User creation and modification

Straightforward. Create the user with the least possible information necessary to create the user. Ask for the remainder (address, games, etc.) later, incentivize it.

Event creation and modification

Straightforward. Create an event and give it the necessary information (address, start, end, etc.)

Event ticketing and registration

A ticket is a prototype for a registration, that is, the admin creates an Event and then creates Tickets for the event. When the User wants to attend an Event, he selects a Ticket. Upon completion of his order, the Transaction is logged and the controller creates a Registration, or multiple Registrations if it's a ticket package. A package Ticket is always comprised of other Tickets, and a Registration purchased as a part of a package refers to its parent Registration.

Group and permission management

Users belong to groups. By default, there are several groups, but these are the most important:

  • Application Administrators
  • Regular Users
  • Anonymous

Anonymous can view the list of users, tournaments, events, seating map, etc. They can also create an account. This isn't a group per se, but is effectively the group for users who are not logged in.

Regular Users can do everything Anonymous can, but they can also register, receive gift tickets, sit on the map, join tournaments, etc.

Application Administrators have godmode and can do anything to anything.

Future groups for consideration include:

  • Event Administrators (create, modify, delete events)
  • User Administrators (modify, disable users)
  • Tournament Administrators (create, modify, delete tournaments)
  • Tournament Reporters (report winners of matches)
  • Shoutbox Moderators (delete offensive posts)
  • Check-In Administrators (grant free admission, change seating)
  • Check-In Workers (indicate that someone has checked in, correct address information)
  • Event Administrator (can change event details, add/modify/delete ticket options)

Permissions are strings like

  • users.administrate
  • users.checkin
  • events.update
  • shoutbox.moderate

The key thing to understand is the relation between users, user groups, and permissions. A UserGroup has Users and Permissions. Users themselves do not have Permissions. A user's permissions are resolved via the UserGroups to which the user belongs.

  1. If a user belongs to no groups, he has no permissions.
  2. If a user belongs to a group, he has the permissions the group has.
  3. A user may have the same permission from multiple groups.
  4. Permissions have parent permissions, so assigning a group a permission also gives that group any permission which is a child permission of the permission assigned.

Some objects, such as Tournaments and Event, may eventually have instance-specific permissions. Those will use Permissions, but will point to individual users or point to groups which have the necessary permissions.

It's always noun.verb.

PLAS Configs (Pcfgs)

Pcfgs are instance-specific variables. These variables are kept in the database and are set for a particular installation of PLAS. Examples of candidates for Pcfgs are PayPal vendor information, header titles, and other "set once at installation" variables.

Things which should not be put in Pcfgs are PLAS-internal variables, such as the version number or project URLs. These are hardcoded in initializers.

Tournament Workflow

When a user creates a Tournament, he gives it a name, description, max teams/ players, and start time. Users can sign up for the tournament, representing themselves or their team. When the tournament is started, Participants can enter scores (double entry -- winner and loser -- for regular users, single entry for tournament administrators). The tournament administrator can declare winners for each Match and eventually a winner for the whole Tournament. A Tournament is associated with a single event and is associated with that event at creation time.

On the backend, PLAS must account for various tournament backend software.

PLAS implements a basic tournament model for simple contests where there are no matches, no need to track scoring, and only one winner. This is useful for simple deathmatch tournaments or non-gaming events.

However, for more complicated tournaments, PLAS offers an interface to Challonge. The PLAS Tournament API mirrors the Challonge API, which we consider to be the gold standard for lightweight tournament softwares. For more information on how PLAS uses the Challonge API, read the challonge-api gem documentation or simply read through the Tournament controller.

Jump to Line
Something went wrong with that request. Please try again.