Use new database as an opportunity to verify current data

[adehnert]

I think we should consider only importing the fields that groups can't set themselves, the optional fields, and like the president. The idea would be that we would then require each group to fill out the rest by hand. That would accomplish two things:

1. Provide some impetus for the information to be up to date. Lots of people will probably just copy-and-paste, but lots will sanity check the information as they do so.
2. Allow us to make groups trigger the validation routines, not us. For example, if we set up the new DB to require that the website and constitution be valid URLs, those filters will get triggered by somebody who (presumably) has the necessary data to put in correct values.

[adehnert]

Fields in the current database main area

[r] require (initially blank]
[i] import
[b] initially blank

[i] Name
[i] abbreviation
[r] Activity category (add other)
[r] Description

[r] membership numbers

[r] website URL
[b] meeting times
[r] officer email
[r] group email

[r] constitution url (note about what to put if you don't have one)
[b] advisor name
[r] athena locker

Signatories

• Import president
• Definitely don't import financial, reservation
• Don't import treasurer

Other fields in the old database

• Import notes as internal notes
• Import account numbers as internal notes
• Import ASA log as note as well? (Or at least CSV.)

[adehnert]

Fixed:

commit a8cd440dd4281a8472281f3a7fbb517fb535480e
Author: Alex Dehnert <adehnert@mit.edu>
Date:   Mon Jan 23 03:37:25 2012 -0500

    Data verification infrastructure (Trac: #22)
    
    This includes:
    * a script to remove data that we want people to verify
      (groups/purge_for_transition.py)
    * code to make more fields required in the normal update interface
    * explanatory message to help people with problematic constitutions
    * adding an "Other" activity category so we can require that field