This is my short list of items which I want to implement this season:

1. New/update Swim Team theme.  This really isn’t related to wp-SwimTeam per se but our site is looking a little dated and it is time to freshen it up.
2. Results Import:  I said I was going to do this last season and I never finished it.  I really want to get this done this year.
3. Export of Meet Entries:  The wp-SwimTeam plugin has all of the informtation (roster, scratch list, event list, etc.) to generate a Meet Entries file in SDIF format.  Providing this file will greatly simplify getting a team’s entries into either Hy-tek or WinSwim (or any other tool which imports meet entries).  This will likely be first on my list after fixing the name bug and the GUI inconsistencies.
4. Document all of the short codes on the wp-SwimTeam demo site.  I really need to do this.  It would make it much easier for new people to pick up the plugin and do something useful with it quickly.

As it turns out the mistake our volunteer made was an honest one and I tracked it down by examining the Opt-In/Opt-Out records in the database.  I have always logged the user ID for the user who submitted an Opt-In/Opt-Out request but never displayed it as I never had a need.  It would have been really useful last weekend – imagine digging through your database using phpMyAdmin on an iPhone which is how I found it because I wasn’t anywhere near a computer at the time.

As a result of this exercise I have enhanced the Swim Meet Report on the Report menu to optionally show the user detail for the user who submitted the request.  I also changed the Time Stamp so it can be shown if desired.  Both of these options are on by default.

This release also addresses a bug where Opt-In/Opt-Out email confirmations were being sent to the Registration e-mail address.  For a lot of teams this is probably same address but for the MacDolphins it is not.  The result was our Accountant was being flooded with Opt-In/Opt-Out email confirmations and has been for the past three years!  She never mentioned it to me until recently.  Oops!

The release is now available from the Download page but has not been committed to the WordPress Plugin Repository yet because WordPress changed all of their passwords last week.  While I can login to WordPress.com without any problems, I cannot get access to the plugin repository.  Hopefully I will get this sorted out soon and then it should appear as an automatic update from the WordPress plugin repository shortly.

Update: I finally got my WordPress.org password issue straightened out and have committed the latest set of changes.  The automatic update process should proceed within a couple hours.

The MacDolphins are testing this functionality this weekend for our Time Trials on Tuesday and barring any problems, I’ll make it available via the WordPress plugin repository later tonight or early tomorrow.  If you want it early, download it and install it manually from the Download page.

The Job Reminder e-mail will look fairly similar to a Job Sign Up e-mail and will be sent when the Admin chooses to initiate the action.  E-mails can be controlled to limit who receives them based on the Job Duration (Full Meet, Partial Meet, Full Season, etc.).  In most cases, the Reminders need to be sent out to the people working the Meet Jobs.

Look for this update in the next day or so after I’ve done a bit of testing with it.

While working on this new functionality I also found a couple of minor bug which I have also fixed.  One of the bug failed to account for a swimmer unregistering for a season so they still would have been seen as active.

I hope to have a release  out in the next day or so.

While working on this I found some problems with the Events module which I have also fixed.  One was a very odd case which only was exposed in Chrome as it worked fine under IE9 and FireFox 4.  It turned out to be some sort of a Javascript difference between browsers so I have changed the GUI for the Load Events form.

If you switch from the stroke based model to the event based model for opt-in/opt-out, you may see some empty or unknown events for existing records.  These are due to a non-existent event id in the record.  It doesn’t really hurt anything but does look odd on the report so I plan to look into it.

I am looking for someone to do some testing before I release an update, if you want to help, get in touch with me.

The meet event information has been in wp-SwimTeam for quite some time but I’ve yet to do anything with it as other things, like the Jobs system, have taken priority.  Knowing which swimmers are registered for which event will make the generation of a Meet Entries file fairly straight forward to implement.

Wp-SwimTeam doesn’t currently support this usage model but I can see the need to do so.  The system already allows the definition and assignment of events to a swim meet, it needs to be extended to allow swimmers to register to particular events instead of the global Opt-In/Opt-Out option which is currently available.

I don’t plan to eliminate the current usage model because it works well for our swim team but I plan to extend it by allowing what I am referring to as the Opt-In/Opt-Out usage model which will either be by Stroke (the existing model) or by Event (the new model).

Fortunately the data model I set up when I first implemented Opt-In/Opt-Out will handle this change fairly easily with one exception.  For some odd reason I called the field in the database which stores the stroke code ‘eventcode’.  This was a bad idea and I am going to change it to ‘strokecode’ in the next release of the plugin which will cause a bump in the database version.  This isn’t the first time I’ve changed a database column name so I am not too worried about it but I wanted to be up front about what I am doing and why.

In the current Opt-In/Opt-Out Stroke based usage model a user can start from a swim meet and update all of their swimmers on a per meet basis or they can start from a swimmer and update all of the meets on a per swimmer basis.  This will remain the case.

However, for the Event based usage model all action will have to be initiated from the swimmer, it will not be possible to update multiple swimmers for a single meet.  This change is due to the swimmers being in different age groups so the events have to be relevant to a swimmer which isn’t possible (or easy anyway, I guess anything is possible) for multiple swimmers.

What about swim ups?  I am not sure how I want to handle swim ups right now.  In the first implementation I will allow an Admin user to register a swimmer into any event but a parent/guardian (standard user) will only be allowed to register their swimmer for the events that correspond to the swimmer’s age group.

Feel free to comment on whether or not I have missed anything and I am looking for someone to validate the usage model once I have it up and running on the wp-SwimTeam Demo site.