There were a also a few minor bugs addressed but nothing of any real consequence.

A parent can now indicate when their swimmers are participating (for meets defined as opt-in) or not participating (for meets defined as opt-out) on either a full meet or event basis.  The meet report will display a summary of swimmer participation based on the type of meet.

A couple of the options on the Report Form are disabled because they aren’t functional yet.  They will probably work in a day or two.

This release also introduces a new mode for Swimmer Labels – Frozen.  When Swimmer Labels are unlocked, they can be bulk assigned.  When they are locked, Swimmer Labels can be edited on a per swimmer basis but no bulk assigned.  When they are frozen, they can’t be edited at all.  I added this because I inadvertently reassigned the swimmer labels for the MacDolphins yesterday without meaning to.  Whoops.

I fixed a few other minor issues as well but nothing significant, mostly presentation of forms and such.

If you download v0.1.375 yesterday, you will want to download v0.1.376 and update the plugin.

In addition to fixing this problem, I added some additional error checking and validation around swimmer birthdates and registering for an active season.  The Add Swimmer capability now includes an “override” to allow swimmers who are too old to be added to the database.  This is being done to support team records, which likely has swimmers who have long since aged out of swim team.

This build also fixes an issue with database queries that appears from time to time when a large number of swimmers was in the database.  The query infrastructure has been improved to leverage the existing WordPress query structure.

There were also a few more UI clean up changes.

This build has not had an extensive amount of testing but I believe it is an improvement over the last build.  I hope to get some solid testing in tonight using a dump from the MacDolphins database.

I have been noodling on how to implement the MacDolphins need for an online scratch sheet solution since I started this project.  It was one of the areas we really struggle with.  We’ve had a scratch sheet posted on the bulletin board for people to sign up on but it was ineffective.  We’ve tried using e-mail which worked better but getting the information from the collection point to the heat sheet continued to be problematic.  Hopefully connecting it to the web site will be a good solution to this ongoing problem.

The basic functionality is now working.  When a swim meet is entered into the system, it is characterized as either Opt-In or Opt-Out (the labels can be set from the Options menu).  An Opt-In meet requires all swimmers to register in order to participate.  An Opt-Out swim meet assumes all active swimmers are participating unless the swimmer withdraws from a meet (or subset of meet events).  For the MacDolphins, all dual meets are Opt-Out events and our local invitational city meet is an Opt-In event.

In addition to the new Opt-In/Opt-Out functionality (which doesn’t include reports yet), I made quite a few improvements to the UI, particularly with the messages which are displayed after an action is executed.  I also took care of some CSS issues which were most notable when using the default light blue Dashboard color scheme.  I prefer the grey one which is why I hadn’t noticed the problem previously.

The next phase of Opt-In/Opt-Out will be reporting followed by exporting a meet specific roster in SDIF format.

This build completes the changes to the option model for the optional fields for users and swimmers.  In prior builds the optional fields were hard coded at 5 for both swimmers and users and the data was stored as part of the user and swimmer records.  This build allows an administrator to set the number of optional fields for users and swimmers (independently) and offers several new types of optional fields (required and optional URLs and e-mail addresses) and stores optional data in a separate table.

The extent of this change was pretty extensive which is why there hasn’t been a release in almost a month.  Unfortunately the old option data is not migrated to the new table so if you are using optional fields, you may have to re-enter some data.  I had to do this with my own swim team.  It is a nuisance.  The old data is still in the database in the users and swimmers table but not accessed.

This build also fixes numerous GUI nits with messages and guidance, it should all be consistent now although I am sure I have missed something.  It also fixes a bug with age groups when swimmer label prefixes are not being used.

I strongly recommend backing up your database before installing this update!

The wp-SwimTeam plugin handles inactive swimmers and families just fine however the E-mail Users plugin we’re using to contact our swim families doesn’t know anything about active or inactive families so people who aren’t interested any more are getting copies of e-mail they shouldn’t really receive.  Most ignore them but some don’t want to be bothered.  I don’t want to build an e-mail system into wp-SwimTeam, there are plugins that already do that.  I am not really interested in building a custom role manager either but that might be the solution.  By default I have all users as subscribers now, I could also look into assigning inactive users to have “no role on this blog” and see if that prevents them from receiving e-mail.

Anyway, I am back and have been working on re-implementing how I had handled the optional fields for users and swimmers.  It has always bothered me that I had hard coded five (5) optional fields in – I knew it was wrong but never bothered to work out a better solution.  Before I left for Sweden I implemented a new model which is loosely based on how WordPress handles user meta data.

I had completed the work on the user and swimmer profile aspect of the new option model but the Report Generator was broken as was the ability to export users and swimmers in CSV format.  It turns  out fixing the Report Generator was more involved than I thought it would be but I now have the User portion of it completed and committed to SVN.  Doing the swimmer report should be pretty straight forward, I can reuse most of the code.  The hard part is done, to do it for swimmers is pretty simple.

So what is the downside?  I haven’t figured out a good way to migrate any information currently stored in the old option fields to the new model.  For our swim team I think I am just going to manually re-enter since we have decided to eliminate one of the fields anyway.

On the upside, the new option models allows the site administrator to configure an arbitrary number of extra fields and fields can now be defined as URL, E-mail, Text, Clothing Size, or Yes-No fields.