BlueprintSelfScheduling



This launchpad blueprint has been implemented as part of 0.7 release series of the TAC Energy server.

Story Description

 * As registered participant I want to be able to self-schedule a new competition on the TAC Server.
 * As participant I want to be sure that only I myself can change my competitions while I want to be able view or be invited to all other competitions too so that nobody can change my own competition setup.
 * As participant I want to be able to invite several other registered competition participants to join my competition so that I can easily schedule competitions with several participants
 * As the TAC server I will send out a mail to all participants of a competition notifying them that the competition starts soon so that they can prepare their agents in advance.
 * As the TAC server I will queue any newly created competition so that previously registered competitions are executed first
 * As the TAC server I will continuously observe the "future competitions" list and execute the first competition in this list whenever the previous competition was finished so that only one competition runs at a time.
 * As the TAC server I allow participants a grace period within which they can submit their ready notifications before I remove the competition from the "future competitions" list.

Competition States

 * Created: Initial state after a new competition was created be a registered participant (initiator) and stored in the database.
 * Scheduled: After the initiator finished adding participants to the competition, he can schedule it for execution by clicking the "start" button in the competion view of the web interface
 * Initialized: Competitions with state "scheduled" are picked up by a (java quartz) cron job, which then initializes the respectie competition by creating products (timeslots) and by computing all required demand / supply forecasts for it.
 * Ready: After the competition was initialized, the TAC server sends out a mail to all competition participants asking them to submit a "ready notification" to the server. After the last competition participant submitted the ready notification, the competition state is changed to ready
 * Runinng: A competition runner job picks up on "ready" competition after another. During the execution of a competition its state is set to running.
 * Finished: After a competition is finished regularly, its state is set to finished.
 * Interrupted: Whenever technical or human interruptions in the competition workflow occur, its state is set to interrupted.
 * [Deleted]

Possible Transitions:
Created -> Created, Scheduled, Deleted

Scheduled -> Interrupted

Initialized -> Interrupted

Ready -> Interrupted

Running -> Interrupted

Finished -> Created, Deleted

Interrupted -> Created, Deleted

Back to ServerBlueprints