|
BSAdv Project on SourceForge
|
Users:
| BSAdv Home Page
| Release Notes
| Using BSAdv
| Youth Protection
| Installation
Developers:
| To Do List
| Database Tables
| Extending BSAdv
| Database Consistency
Releases starting with the number zero are not useful for a unit. They are distributed here to allow potential developers to try it. Adequate youth protection measures are not yet in place and the functionality is not yet adequate. Additionally, not enough time has been spent testing the code, so bugs exist.
This is finally getting close to complete. It is ready for final debugging. There will be comments and questions before it ready for release.
Converted to Joomla 1.6/1.7. Implemented access control using features of this Joomla release. Details can be found in the youth protection section. Note that the web site administrator must assign users to groups and must assign access control for these groups to the various parts of BSAdv. This is a critical part of protecting the information in the unit web site.
Added a check for the Joomla revison. Will not allow installation to a Joomla revision prior to 1.6.
Added user_id to scouts table. A Scout is assigned an id if he is a registered web site user. Recording this id will associate the web site id to the Scout in the BSAdv database. Added this field to the Scout edit form.
Cleaned up the back end. Changed configuration items to component parameters.
Added a component to dump the unit data in an SQL format, suitable to re-install.
Changed the JavaScript conversions to and from JSON. Replaced eval() with JSON.parse(). Replaced the custom function bsadvJsonStringify with JSON.stringify. This improved security and removed problems with JavaScript inherited functions. This will restrict use to those browsers that support these JSON functions, but only for those users who enter data.
Plans exist for converting BSAdv for use by Cub Scouts and other types of groups. The first step is to separate the advancement and merit badge databases from the BSAdv software. This will allow them to be updated separately. Next, the Cub Scout (or other group) advancement data needs to be mapped to the Boy Scout tables, and parallel update paths defined for the Cub Scout advancement updates. The different terminology used in the web pages for Cub Scouts will be implemented with translation files. Stay tuned. This will be interesting.
Added controller scoutawards to view and edit awards associated with a single Scout.
There is not a large amount of new content in this release, but it completes most of the required functionality. The next step is to implement the access controls of Joomla 1.6.
The mechanism to track alternate merit badge requirements did not work with requirements having nested alternate requirements. Instead of making a more complicated method, we will use a manual process instead. This simplifies the tables somewhat. We removed the table mbreqsgrps. Similarly, we removed the table ranksreqsgrps.
To replace the computation of completions, we added a table to enter this information manually. The new table scoutsawards records when awards are earned, purchased and awarded. This adds significantly more features than the previously noted changes removed. We added a new table awards which lists the awards that can be earned by Scouts and adult leaders.
A large amount of space in the database had previously been assigned to store the text of the meritbadge requirements. This is not the intent of BSAdv, so we removed the description field in the mbreqs table. Similarly, we removed the description field in the ranksreqs table. The merit badge and rank requirements will be referred to by their number and letter designations.
Added the awards controller to display awards that have not been purchased or distributed to the Scouts. Awards that have been distributed are documented in the Scouts' advancement records.
Added the scoutranks, accounts and account controllers. This completes the controllers needed to create, edit and delete data in the various tables.
Added the static controller to display pages without database information. Created pages to select edit controllers and report controllers. Report controllers create HTML output from the database, but do not modify the database. It is expected that simple menu entires will access these edit and reports pages.
Added field events_id to the accounts table. This optionally allows an account to be assigned to an event.
Added features to add and delete entries in various tables. Previous releases could only edit existing entries. Cleaned up bugs in various components, including susceptibility to an SQL injection exploit. Checks are now made to all id entries from the user.
Completed the adult, adultdeeds and adultaccounts controllers. These are very similar to scout and scoutdeeds and scoutaccounts from the previous release.
Additional controllers were added to allow the user to select a specific Scout, adult or event, to sebsequently view or edit data on that Scout, adult or event. A common controller is used to consolidate the code to one place. This works similarly to the checkout controller, interacting with the user, then calling another controller.
Added the table adultsaccounts to keep track of adult expenditures.
Added the table dblog to log changes to the database. It is often useful to keep track of who is modifying the database, and how successful they have been.
Bug fix to site/views/scout/tmpl/default.php to fix the edit form for items with null values.
Consolidated the actual database calls of the model update functions into a single generic include file: /models/commonUpdate.php. This simplifies the implementation of a global database update enable, and a global logging enable. As a result, most models were modified to use this common update function. Three additional variables were added to the config table:
A future update will implement a similar centralized database include file for database reads.
Completed the scout, scoutdeeds and scoutaccounts controllers. As with previous releases, we will subsequently define other web interfaces to efficiently enter and review data. These three new components extensively use JavaScript, DHTML and JSON.
Added the table checkout to keep track of potential multiple people editing the same database. This is a system to warn users of potential syncronization problems with two or more users editing the same table. It does not keep these problems from occurring, by locking access to tables. Instead, it just makes the user(s) aware of the potential problem. The reason we did not lock tables is because there are occasions where one person will have multiple edit windows open for a coordinated edit session. We do not want to enforce policies that would eliminate the efficient use of multiple edit windows.
Modified the previous event controller to check out and check in the edit sessions. This required splitting the view and edit modes, so the user can check out the table prior to actually editing it. The user now cannot switch between the view and edit modes via JavaScript. A reload of the data is rnow equired when switching. Checking in is done invisibly in the model update function. These changes required significant edits to the previous code.
Completed the event controller. It is the most complex part yet, and manipulates data in various tables that have the most complex relationships. It is likely that better HTML display representations will be found in the future, allowing a clearer view of the data and their interrelationships. For now, this will suffice.
The event part heavily utilizes JavaScript and DHTML to reduce delays between user actions and display responses. This requires a significant amount of data to be transferred to the browsers' JavaScript. Most of this data is the standard definition of ranks and merit badges, and their requirements. Having this information in JavaScript allows the user to easily enter event participation and accomplishments without waiting for server responses. There is much more JavaScript in this part than I originally thought there would be. Due to the delays in this release, we probably have not tested it as thoroughly as we should. JSON is used to transfer the information from the server to JavaScript and back to the server.
Added fields to the deeds table.
Bug Fix.
The install SQL files had the line:
SET SQL_MODE="NO_AUTO_VALUE_ON_ZERO";
This caused the BSAdv entry in the Joomla components table to
have an index of zero. Uninstalls somehow DELETED ALL COMPONENTS!
My aplolgies to anyone adversely affected.
Added controller event. It is currently incomplete, but it is easier to include it in the bug release than to remove it. It does show how most of how the final code will work. Due to the complexity of the underlying data, I have used Javascript to ease the task on the user. It is fun to play with, and helps the user understand the relationships between events and deeds. This should be complete in February 2009.
15 March 2009: The Javascript is much more complex than I anticipated. Progress is going well, but it is taking longer than I planned.
Added table adultsdeeds. Previously, we recorded the obligatory two-deep adult attendence in fields in the deeds table. The adultsdeeds table allows us to track adult participation in events. This helps us answer questions about accomplishments, sometimes long after they occurred.
Completed controller peruse. Peruse allows a user to follow the links betwen the tables to find specific data. Peruse probably benefits the developers more than the users, because it implements access methods for all of the tables. Peruse introduced read and update access via JTable for the BSAdv controller. There is a lot of cleaning up to do in the code, but it appears to work fairly well for now.
Added controller onerecord. It was difficult to implement a generally-useful record editing task to the peruse controller, so we created a new controller, called onerecord. It implements single record editing features that any controller in BSAdv can utilize. Following an update or cancel, a redirect is done to a location stored in a session variable. This allows the onerecord controller to return the user to the place where they started.
Added email field to scouts table. We previously thought that this would be a violation of youth protection, but that is what the backend is for. We included the email field here becase they are so common, even for youth.
Added dummy data: unit number and Council name to the config table. This information is needed for reports.
Added config table. This allows the unit web site administrator to configure several things about the web site front end, including limiting Scout information for youth protection.
Fixed various typographical errors.
Initial release.
Thanks to Sourceforge.net for hosting our project.