PYROS

h1. TODO

List of tasks by application, and general tasks (organization, tools, ...)

{{>toc}}

---

h2. %{margin-left:0px; font-weight:bold; font-size:25px;  display:block; color:red;}General tasks%

* DJANGO : 

 * Upgrade to Django 1.10

 * Remplacer le serveur web de "dev" (manage runserver) par un vrai serveur web pour la "prod" (Apache + serveur d'application Python, par exemple gunicorn)

(cf https://projects.irap.omp.eu/projects/pyros/wiki/Project_Development#Serveur-Web)

* COMET installation : Include in the install_requirements.sh script (by using stable official version for Python 3 (when available) on Linux (and Mac) and Windows 10

* GIT : Create a "dev" branch (do not write anymore on the "master" branch)

---

h2. %{margin-left:0px; font-weight:bold; font-size:25px;  display:block; color:red;}Applications tasks%

h3. Dashboard

 * Create the backoffice views as the modules are integrated in pyros

 * Think about a system of permissions

h3. Scheduler

 * views

  * Link the main page to the current schedule instead of the simulation page

  * Show user sequences in the schedules (with links)

  * Give accces to old schedules (day / days before / all end-night plannings / all plannings)

  * Give access to the refused sequences of a schedule, and the reasons of rejects

 * scheduler

  * Change the system to determine night start/end (they must be given in parameter, only if first_schedule is True)

  * Store the reasons of rejects (create a new attribute, in shs ?)

  * What is the 'flag' attribute ? (@AK)

  * Do not create the execute_sequence tasks if it's not the night (- 120 seconds)

  * Priority and quota computing

  * Quotas evolution

  * Blank space filling

  * At the end of a scheduling send, it to the IC ?

h3. Alert Manager

 * Web :

  * Print if there is an alert in progress in the main page

  * Link the alerts to their status and results

 * Connect to a real VOEvent broker

 * Determine the communication with FSC for strategy change

 * VOEvents :

  * Extract the good fields (see AK Q&A 07/01/2016)

  * Fill the request & alerts objects

  * Use strategies to build a request

  * Possibility to change the default strategy

  * Handle VOEvent updates

  * Be careful to not create 2 alerts for a same GRB, seen by 2 different satellites 

h3. Analyzer

 * Apply the calibrations in the right function

 * Apply the analyses only if it's a GRB

 * Implement the analyses

 * Send analyses to FSC

h3. Majordome

 * TaskManager

  * When a sequence is cancelled, give back the quota to the user

  * In case of alert, do not stop the ongoing plan, and make the instruments abort

 * execute_sequence

  * Add the PLC checks at start (to see if we do the slew)

  * Use the global telescope (instead of creating one here)

  * Give first_schedule as false when a scheduling is launched

  * Remove the default countdown (1, for tests)

 * system_pause

  * Abort the isntruments

  * Stop the execution tasks

 * system_restart

  * Start a scheduling

 * change_obs_conditions

  * Change sequences status (if  needed)

  * If some status changed, re-launch a scheduling

h3. Monitoring

 * views

  * Move the dashboard here

  * Print the instrument status

  * Print PLC informations (with the evolution)

  * In the dashboard screens, put scroll on each screen to see the old logs

 * Monitoring task

  * Uncomment the scheduling at the beginning

  * Implement night start/end computation

  * Initialize communication with the instruments

  * Configure intruments at start

  * Send software versions to the IC

  * Initialize connection with PLC

  * After the starting actions, loop to wait for the instruments configuration to be finished

  * Ask PLC for status

  * Ask filter wheel for status

  * Store the instruments & PLC status

  * Send all status to IC

  * Analyse PLC status (obs conditions, ...)

  * Create tasks of obs condition changes

h3. Observation Manager

 * execute_plan :

  * Use the cameras at a global level instead of creating them here (same for the filter wheels)

  * Uncomment the instruments_ready waiting function

  * Uncomment the observation_ending waiting function

  * Try to remove code duplication

  * Determine what needs to be done at the end of an observation

 * create_calibrations :

  * Make the calibration images

  * Generate super images

  * Send them to the IC

h3. Routine Manager

 * Web

  * Put the goods fields (for coordinates etc)

  * Only propose the objects that matches the conditions (ex: scientific programs of the user only)

  * Do all the needed checks

  * Add automatic computation of JD1/JD2

  * Add checkbox for JD / GD

  * Add options : copy my sequence on x days, and authorise report

  * Add ETC-IS simulation

  * Add help for new users (and for it the first time an account come on the page)

 * Do more checks at unserialization

 * views

  * When saving, do more checks on coordinates, jd1/2 etc

  * Uncomment filter for alerts removing

  * When submitting, use the monitoring to determine sequences status

  * When submitting, modify the first_schedule to False, when scheduling

  * When unsubmitting, uncomment the check for EXED and EXING removing

  * When unsubmitting, uncomment the scheduling and change the first_schedule to False

h3. User Manager

 * Password recovery

 * Profile page

 * User validation by administrator / commission

 * Handle permissions and access

h3. Common

 * Network communication for every instrument

 * Change the 'first_schedule' to False at the end of RequestBuilder.validate()