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.
In the latest 1.6.x released I changed the actions on the Manage->Users tab from a row of buttons to a drop down list. In the process I have introduced a bug because none of the controls on the user list (expand, search, page forward, page back, etc.) work. I am working on the issue and hope to have an update out shortly.
The major feature that I had been working on which I didn’t complete is the ability to generate a Jobs vs. Commitment report. The Jobs module allows each job to assigned some number of credits and there is a setting to set the minimum number of credits each user is responsible for. By default the system will use zero which means there isn’t a minimum. In the latest release, when a user looks at their My Jobs tab, it will show the jobs they have committed to and sum up the credits. If the sum of the credits is less than the minimum, an error notification will be displayed for the user.
Right now this message is only displayed on the My Jobs tab but an administrator will also see it when view selecting the Jobs action for any user from the Manage->Users tab. I had given some thought to displaying the notification anytime a user logged in but have conclude that would be too intrusive. I may make it an optional setting at some point though.
The one thing I haven’t figured out is how to handle a situation like we have with our own team. On our team we ask each family to volunteer four times (four credits) for the season regardless of how many swimmers they have. If both parents are in the system (primary and secondary contacts) right now they would be erroneously flagged if each signed up for two jobs because together, they have met our requirement.
Reporting job commitments versus user is pretty easy and I will do that in the next few days but I have also considered reporting job commitments versus swimmer so that both contacts can be accounted for. In speaking with some teams locally, they require two volunteer commitments per swimmer so that is yet another permutation to account for. In the short term I will likely only report commitments versus users and leave it at that for now and revisit it after the season as there are some other things I need for our season which starts in three weeks: Results, Meet Entries, and some work on WinSwim/Hy-tek interoperability.
It took longer than I wanted and I didn’t get all of the features I wanted done, but I have release v1.6.605 of wp-SwimTeam tonight. This release addresses a number of things my own team has been asking for, in particular with respect to jobs. A number of our parents have asked how they can see which jobs they have signed up for and if they have scratched their swimmers or not. A key new feature in this release is the Swim Meets report is now exposed to all users but the information presented to users is limited to their swimmers and their jobs.
- Fixed bug when optional user and/or swimmer field count is zero preventing reports from running.
- Added My Jobs tab for all users. User can now easily see which jobs they’ve signed up for.
- Added e-mail field to user profile. Users are familiar with the swim team profile, easy to update.
- Exposed Swim Meet report to all users allowing users to see their swimmer opt-in/out and jobs easily.
- Added Dashboard widget.
- Fixed quite a few minor bugs – too many to list!
This release is available now on the Download page and will be available from the WordPress plugin updater later tonight
There is a bug with the User and Swimmer reports which will manifest itself when either the User or Swimmer optional field count is set to zero AND the table where the optional fields are stored is completely empty. I have fixed the bug and checked it but am not quite ready to do a release due to some other changes I am in the process of making not being finished yet. The bug will also manifest itself when trying to export a list of users or swimmers as CSV.
If you run into this problem, let me know – there is a fairly easy work-around that will prevent it from happening.
WordPress 3.2 beta is out for testing and with it comes several requirements. The two notable requirements are PHP 5.2.14 or newer and MySQL 5.0 or newer. I will likely move to 3.2 for wp-SwimTeam development once it is released and I’ve done some testing with it. I’ve been running under PHP5 (5.2.14 and 5.3.x) for a while now so I don’t see this as an issue but it might be for people running on older web hosts.