NRAO Home  >  Green Bank  |  Wiki Topic:    GB > Software > PlanOfRecordC22008 > ModificationRequest6C208

Changes | Index | Contents | Search | Statistics | Go

DSS: User Data

Modification Request #6 (C2 2008)

• 1. Introduction
• 2. Background
  • 2.1 Terms
• 3 Requirements
• 4 Roundtoits
• 5. Design
  • 5.1 Internal Planing
• 6. Deployment
• 7. Test Plan
  • 7.1 Internal Testing
  • 7.2 Sponsor Testing
  • 7.3 Integration/Regression Tests
• 8. Out of Scope
• Signatures
• CCC Discussion Area

1. Introduction

Because of DSS's approach, it essentially schedules observers rather than projects. It is therefore critical that observers are associated with projects and their contact information is readily available. Though for the summer test semester we do not plan to use authentication for users, we do need to have access to observer information.

2. Background

See DSS project charter for more information.

The requirements in this MR are based off a discussion at ObserverContact.

2.1 Terms

• Static Contact Information - this includes all contact information that is not likely to change over short periods of time. For example, home and work mailing addresses, home and work telephone numbers, etc. This type of information can currently be found in the BOS or through e2e interactive services.
• Dynamic Contact Information - this includes all contact information of a transitory nature such as: observing black-out dates, short-term use telephone numbers, etc. For example, the phone number for the observer's hotel where they will be on vacation is not static information - it will likely only be used during their vacation.
• Black-out Dates - a date-time range that specifies a period when an observer cannot be available.

3 Requirements

1. The initial set of "observers" associated with a project must come from the project investigators.
2. The DSS must associate projects with observers, and vice-versa.
3. The DSS must manage observer's static contact information:
   • The DSS must be able to retrieve and use (ex: notifications, announcements) the addresses, telephone numbers, and email addresses of an observer.
   • The DSS must be able to provide a means for the observers to manage this information themselves.
4. The DSS must manage observer's dynamic contact information:
   • The DSS must manage observer black-out date-times:
     • The observer must be able to easily manage (create, read, update, delete) black-out date-times
     • The observe must be able to easily view the black-out date-times of the other observers also on the same projects as themselves.
     • All observer's associated with a given project must be notified if all observer's on said project have specified the same black-out date-times (i.e., in case there is no one available to observe the project).
     • An allocation will not be available for scheduling if no valid observers are available.
   • The DSS must manage observer's contact information for observing:
     • If no 'dynamic' information is specified, the DSS must provide 'static' information for contacting an observer (i.e. - by default the observer will be phoned at home and/or work).
     • An observer must be able to specify multiple phone numbers with descriptions.
5. The DSS must manage user scheduling information:
   • The DSS must be able to retrieve and use the observer's reservation information to determine if the observer is on site.
   • The DSS must provide means for the observer to manage their reservation information.
   • The DSS must manage an observer's qualifications for observing:
     • The DSS must provide feedback on whether a user is trained for observing.
     • An allocation will not be available for scheduling if no observers are trained or on site.
   • The DSS must provide an interface for adding new observers to projects and their contact information.

4 Roundtoits

• On-site information should show up in an observer's black-out date calendars (or other calendars).

5. Design

See the Dynamic Scheduling Documentation.

The basic idea for implementing the above requirements for this summer is "whatever's easiest". For instance, requirement 3 will be satisfied by leveraging the Business Office System (BOS).

5.1 Internal Planing

• Create new Python installation with all the current libraries used by nell and antioch. New versions of TurboGears and SQLAlchemy are needed to take advantage of enhancements that support multiple database connections.
• Document new Python installation
• Update code and unit tests to work with new Python installation.
• associate dss.projects table with bos_1_0.person table via many-to-many join table spanning the dss and bos databases.

6. Deployment

Not being deployed at time of completion.

7. Test Plan

7.1 Internal Testing

Unit tests.

7.2 Sponsor Testing

Inspect skeleton as it is developed.

7.3 Integration/Regression Tests

None required since it is not being deployed upon completion.

8. Out of Scope

Eventually, we should exclusively use the e2e interactive services database for static contact information.

Signatures

APPROVED: I acknowledge that my request is fully contained in this MR, and if the SDD delivers exactly what I specified, I will be happy.

ACCEPTED: I acknowledge that I have validated the completed code according to the acceptance tests, and I am happy with the results.

Written	- PaulMarganian - 15 Apr 2008
Checked	- MikeMcCarty - 16 Apr 2008
Approved by Sponsor	- KarenONeil - 16 Apr 2008
Approved by CCC	- AmyShelton - 16 Apr 2008
Accepted/Delivered by Sponsor	- KarenONeil - 05 May 2008

Symbols:

• Use %X% if MR is not complete (will display )
• Use %Y% if MR is complete (will display )

CCC Discussion Area