Magellan Telescopes   ObserverReminders UserPreferences
 
HelpContents FindPage Diffs Info Edit Subscribe XML Print View

Magellan Scheduling and Observer's Reminders

Process overview/Requirements

This is a suggested timeline for how the schedule and reminder program will be used; it isn’t a good description of what a typical (or atypical) user will do since most people are interested only in particular sections.

  1. Enter user information. A link on the front page will take you to a form that allows one (who?) to enter user information. Each record contains: first name, last name, email address, charge-to institution, date updated. Email addresses are in the database but not in clear text anywhere. This will be loaded at project startup but invoked later only when a user can't be found (or is known ahead of time not to be in the database).
  2. Enter telescope schedule information. A link on the first page send you to the schedule entry form. Ian can set an access code to open it for entry by institutional schedulers. Institutional schedulers log in and enter the following information: Run start date, run end date, PI, observers (including the PI if he/she is traveling), instrument(s) requested (and by implication the telescope). Check that start date < end date, end date minus start date is less than some number (20 days), start date and end date are no more than 9 months in the future and 2 months in the past (to update what really happened). PI and observer names are pull-downs from user information (to minimize data entry errors). Dates are picked off a calendar or pull-down. Ian (or assistant) enters engineering time and Carnegie observers. Masks needed?
  3. Sanity check by Magellan scheduler (Ian). A "print" button on the front page generates a simple calendar (similar to http://www.ociw.edu/schedule/2006/sch2006_10.html?). Ian signs off on the schedule.
  4. Lock out further updates. On an administration page. The institutional schedulers are locked out (password system). Only Ian can change it after this.
  5. Upload to Google calendar. On an administration page. Ian clicks a button to send it to the Google calendar.
  6. Send reminders. Daily cron job looks to the future and sends reminder emails for slit mask cutting, travel forms, instrument setup forms. Reminders are cc:d to a mailman list for the record (and to get some level of confirmation that the mail was sent and looks OK). The subject line should be informative enough to find easily a specific entry in a mailmain archive.
  7. Watchdog check. The daily cron job also sends a watchdog email to a separate machine (different location). A watchdog cron job from the other machine sends “help me” email to administrators if two days go by without a ping from the “Send reminders” machine.
  8. Log compliance. The mask, setup, and travel forms are modified to set a flag in the database that says the task has been completed.
  9. Second notice. If the deadline for mask, setup, or travel passes (the daily cron job), a second email notice is sent, this time with copies to management.
  10. Third notice. After a third deadline date passes without action, management alone is notified and calls or emails the PI directly.

Observer functions

Do observers need any access besides the mask, setup, and travel forms? They can see the Google calendars. Should the schedule/reminder, mask, setup, and travel forms be integrated?

Hardware requirements?

Where does this run? Where's the watchdog machine? Where's the mailman list?

PythonPowered