Thanks for the feedback. You noted you have outlined the php classes you think are needed - are you willing to post or send me a copy of your classes ?
thanks oscar On Monday 26 June 2006 9:57 am, Robert Nickel wrote: > On 2006.06.25 22:35:34 -0600, Oscar Schultz wrote: > > Since you already put in a lot of time and effort you should better know > > where the problems are in a web based system. Outlining the problems > > would save anyone just starting a lot of time and false starts. > > lol. My efforts were toward the normalization of the database and creation > of the php classes for the various objects in a web based system. However, > I will try to make some sense of what I've been thinking. > > > Please outline what requirements you believe a tracking program should > > satisfy and what features you believe are needed (perhaps level 1,2 and 3 > > level requirements/features). > > [...] > > The requirements for the tracking program, in my mind, are quite simple. > Reduce the amount of effort required by the Scout Master to track this > information and provide meaningful information to the Scout Master or > individual scout in a timely manner. Beyond that, other features are just > window dressing. > > The core features that *must* be implemented (Level 1): > > o Troop roster. > - First name, last name, middle initial (optional). > - Flag for leader or scout. > o Configurable rank requirements. > - Since BSA is taking great pleasure in rearranging old requirements > and adding in new ones, it's beneficial to have a flexible system for the > ranks Scout -> Eagle. > - These rank requirements should be unique items in case the > requirements change and the boy is not responsible for the new requirement > structure. o Merit badge listing. > - This listing should include the merit badge number, name and whether > or not the individual merit badge is a required merit badge. > o Troop positions tracking. > - Ability to input troop positions and who filled them (if anyone) with > start and end dates. > o Reporting system. > - Answer questions frequently asked by SM and CC like, "What boys need > for first class?" or "What paperwork is this boy in need of?" or "What > merit awards have been earned by the troop this year?" > > The features I believe are worth doing (Level 2): > > o Merit awards for youth and adults. > - Duty to God *could* be integrated here but is likely better suited to > being a stand alone application if this is to be available for all > scouting organizations. > - This is a great place to track awards for On My Honor and other > similar items. > o Attendance roster. > - Allow for input of meeting dates and roster of boys attending. > o Paperwork tracking system. > - Input various items that need to be filled out (i.e. a permission > slip for each boy attending a campout). > - The system should be flexible enough to accept lists of boys that > need to have the paperwork in and a deadline. > - Ideally, this could be used for tour permits and other such items. > - Some sort of comments field for this system would be ideal allowing > for todo items and some minor collaboration between leaders. > > Please note there is no mention of a calendar. Calendaring is a *HUGE* > part of the scouting program but I don't believe it has anything to do with > the tracking of progress. There are already many good calendaring systems > freely available. Why do we want to reinvent this wheel? > > > Please outline the security/protection requirements (rather than > > implementation methods) you found. > > Please note above that the only personal information input into the system > is to be the full name of the individual and whether or not they're a scout > or a leader. > > If the potential leaking of this information coupled with the individual's > scouting history is deemed too risky, then that individual may be excluded > from the system or assigned a non-identifying name for inclusion in the > system. [0] > > As for the general security of the code and database, ssl should be > employed. I don't see a need for encrypting the database or handling > key/certificate distribution if the system is implemented with just a > first/last name pair.[1] > > I hope this sounds reasonable. If not, please be gentle whilst crushing my > ideas. :-) > > --Robert > > [0] Perhaps a first name of Non-disclosed and a last name of an index > number. [1] I know. The question is IF you're paranoid, but if you're > paranoid enough. _______________________________________________ Ldsoss mailing list [email protected] http://lists.ldsoss.org/mailman/listinfo/ldsoss
