Pending Work

Unimplemented Requirements
Current Release Bugs

Unimplemented Requirements

Following are discussions of workarounds and/or technical designs for features that were not implemented in the current release of the CalStARS application. The IDs reference the Requirements section.

Functional

ID 2.3 Signature Forms

Based on discussions with the Cal Office of General Counsel, student-athletes must complete the Buckley Amendment form in hardcopy as mandated by FERPA (Family Educational Right to Privacy). The Cal Authorization Release form needs to be further investigated on the same grounds. The NCAA Drug Test Consent and Cal Drug Test Consent forms are only partially implemented because per Princeton University practice, the requirement to obtain a parent or guardian's signature for a student-athlete who is a minor (under 18 years of age) must be satisfied in hardcopy form.

ID 2.7 Form Pre-Population & ID 7 Conversion

Pre-population of forms with data from the prior school year entails a Conversion process that would move data from the current FileMaker Pro database into the CalStARS database. This requirement was merely a convenience for student-athletes (to do away with re-keying permanent information) so its absence does not prevent the use of the application for the current school year. Going forward, once the archiving feature is implemented, forms will be pre-populated with permanent student data because the application will have access to data from a prior school year in order to pre-populate forms for the current school year.

ID 3.1 Data Updates

Allowing student-athletes to update automobile and housing data, email, address, and phone number after a form has been "signed" entails that the "signed" values be retained and not overwritten by the update values. This is to satisfy the notion that a "signed" form is binding and permanent and cannot be changed. Retention of prior values requires an audit capability that can keep track of the prior value, update value, and change date so that they can be retrieved if warranted by circumstances. In the meantime, all updates can be recorded in the FileMaker Pro database instead.

ID 3.3 Recruitment Verification

This requirement is only partially implemented. The FinancialAid table already contains fields to store the "original recruitment status" value as entered by the student-athlete, as well as the "verified recruitment status" value as entered by the administrator. Code has also been written to allow only administrators (not student-athletes) to perform this task. However, logic still needs to be implemented to allow administrators to perform the task only after the form has been submitted by a student-athlete. Also, once an administrator has entered a "verified recruitment status", other administrators must be prevented from performing the same task.

ID 5.5.4 Data Updates Notification

This requirement is contingent on the implementation of requirement 3.1 Data Updates. A weekly email will automatically be sent to an administrator to flag all data updates for the week. This can be accomplished by setting up a cron job that will invoke a shellscript at the end of the week. The shellscript will send an e-mail to the appointed administrator with a hyperlink to the JSP page that produces the Data Updates Notification report and pass a parameter denoting the date marking the end of the week. When invoked, the Data Updates Notification report will read the date parameter and retrieve all updates from the database that fall within the a week of the date parameter. The report will then be displayed once corresponding authentication process has been completed.

ID 6 Data Transfer to FileMaker Pro

This requirement is necessary in order to synch-up the FileMaker Pro database with the CalStARS application data. The original design entailed a real-time data dump from CalStARS into a FileMaker Pro table via an ODBC connection. Some unresolved issues are the exact point in time at which the data transfer must occur and the frequency of the data dump. Currently, in CalStARS, the student-athlete can choose to submit in any random order. This means that CalStARS cannot supply all the data required by FileMaker Pro in one data dump. There are 2 options. First, a student-athlete's data is transferred only after all information required by FileMaker Pro has been submitted. Second, a student-athlete's partial data is transferred upon submission and subsequent data transfers are performed as more data is submitted. The second option will require FileMaker Pro to detect the occurrence of change in the contents of the student record.

Non-Functional

ID 1.2 Archiving

This is an important requirement because NCAA requires that form data be retained for a period of 6 years. Only administrators will have the capability to view forms from prior school years. The technical design impacts all modules of the application and the details are outlined below.

In order to retain 6 years worth of data, the data model will have to be expanded. Instead of just a Student table or Housing table, prior year data will be stored in a corresponding table such as Student_2002_2003 or Housing_2002_2003. The suffix appended to the table name denotes the school year that corresponds to the data stored in the tables.

The JavaBeans also have to be modified. Currently, each JavaBean is hard-coded to access the Student or Housing table and does not accommodate a suffix. All JavaBeans must be changed so that table names are formatted prior to the building and execution of the SQL query. This can be accomplished by the following declarations:

where "schoolyear" is the value of the school year parameter passed via the session cookie. Consquently, SQL queries can be built using the variables StudentTable and HousingTable.

Code already exists in the Admin Home page to allow an administrator to select a school year from which to view Forms and Reports. However, the code needs to be uncommented and session cookie values must be set to the selected school year. This will allow Forms and Reports (which have already been implemented to read the school year session parameter) to render the correct values. Finally the Admin Home page must provide a button labeled "Advance to Next School Year" for the super user. On click, this button will invoke the method "advanceSchoolYear" from the "SchoolYear" JavaBean. This method will execute all Archiving actions.

The "SchoolYear" JavaBean must be modified to contain the bulk of the code to implement the Archiving feature. Currently, the "advanceSchoolYear" method is already coded to, upon invocation, create a row in the SchoolYear table to for the new school year and to re-label the current school year as the "prior" school year. However, code needs to be written to move all data from the "current" tables such as Student and Housing to corresponding "prior" school year tables. For instance, if advancing to the school year 2004-2005, data must be copied to tables such as Student_2003_2004 or Housing_2003_2004. Some data in "current" school year must be retained in accordance with requirement 2.7.

ID 2 Security

Currently, user authentication passwords are transmitted in cleartext form over the network. Each JavaBean contains the database name, login, and password in cleartext form as well. Before going live with the application, database credentials must be reset to different values and not hard-coded into the JavaBeans. Passwords should also be encrypted while being transmitted over the network.

^top

Current Release Bugs

The following bugs have not been fixed in the current release.