TODO
Version 1 (Paul Carensac, 08/09/2016 11:31 am) → Version 2/113 (Paul Carensac, 08/09/2016 12:20 pm)
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%
---
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()
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%
---
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()