About a week ago one of the volunteers inadvertently registered (Opt-In) our entire rosters for a swim meet. An Opt-In will supercede any existing Opt-In or Opt-Out information so we lost our entire scratch list for our meet this past Tuesday. I was out running errands getting my son ready to go on a mission trip when I started seeing numerous registration e-mails coming across my phone. Yikes – what happened? Initially I thought someone had gotten administrative access to our database and was playing games.
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.
I have tracked down the problem that was causing the opt-in/opt-out list to be displayed incorrectly when called from the wpst_meet_report short code. I have fixed the problem and made a new release available. The release is now available from the Download page and has been committed to the WordPress Plugin Repository. It should appear as an automatic update from the WordPress automatic update process in the next couple of hours.
I have started looking at generating meet entries (SDIF) directly from wp-SwimTeam. When you factor in events, strokes, registrations, scratches, and relays, the problem of generating meet entries becomes fairly complicated. I’ve been sitting on the couch watching golf and perusing the SDIF specification and have a pretty good idea of what I want to do, now I just need to decide how to do it. For the time being, I think I am going to focus on individual events as they are much easier generate than the relay events. However, I don’t want code myself into a corner and make relay events hard to implement so I can’t decide what to do. I also need to decide if I approach this from a roster perspective (ie by swimmer) or from the meet perspective (ie by event). Hmmm …. decisions, decisions!
I have uploaded an early release of 1.9.646 to the Downloads page. This new version has the ability to send out Job Assignment reminder e-mails. There is a new action available from the Manage->Swim Meets tab called “Job Reminders”. This action will pull all of the job assignments for the requested meet and send a reminder e-mail to each person.
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.
Several clubs, including my own, have asked if I would add a feature to send out reminder e-mails to people for the Jobs they have signed up for. Today I implemented this feature and am in the process of testing it on the wp-SwimTeam Demo site.
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.
This evening I finished the Job Commitment Report. I am not sure why but I had a tough time getting going on this one. It will appear as a new tab on the Reports menu and will report the total number of credits a user has committed to for the requested season. The report is limited to the users who have swimmers registered for the specified season.
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.
I have completed all of changes to support the opt-in/opt-out event model I described late last week. I have not released the update yet as I am still doing some testing. I have it running on the wp-SwimTeam demo site. You can see an example of what one of the reports would look like when swimmers are registered on an event basis instead of a stroke basis.
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.
I’ve made a fair amount of progress today on the new Opt-In/Opt-Out Event model. One of the big benefits of this model is it will facilitate being able to generate a Meet Entries file (SDIF) which could be consumed by Hy-tek Meet Manager or WinSwim.
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.
I’ve had an ongoing dialog with a team in Texas using wp-SwimTeam that has a much different usage model for participating in Swim Meets than the MacDolphins do. Instead of registering or scratching for a meet, their team has their swimmers register for particular events. In speaking with a parent of one of our year round swimmers, they do the same type of thing for their year round meets.
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.
A quick turnaround on the bug reported a short time ago. It has been fixed and I have posted v1.7.608 of wp-SwimTeam. This fixes the bug which essentially made the Manage->Users tab almost unusable unless you had a very small number of users.
This release has also been pushed to the WordPress plugin repository so it should be available via the plugin updater fairly soon.