There is a pretty serious bug in the last couple of releases. It appears that the changes I made to support Multi-Site affected the Jobs module.
It appears that jobs that have already been committed to one user appear as available to all other users.
I am at a Lacrosse tournament and have limited access from my phone to be sure. For now, I recommend putting your Jobs module in “Admin” sign up mode until I investigate later tonight. Use the Jobs tab on the Options menu to disable User job sign up.
One of the changes I made in the last week has introduced a pretty significant bug in the Jobs module. If you assign a set of jobs from the Swim Meet tab, it may unassign a bunch of previously assigned jobs, possibly even from prior seasons. I have identified the bug and am in the process of fixing it.
This afternoon I released v1.18.747 of wp-SwimTeam. This release includes what I am calling Phase 1 of the new Event Model. The event model has been completely overhauled in anticipation of being able to generate Meet Entry files in SDIF format directly from wp-SwimTeam. The whole Events tab looks and works differently. Events are collected into what I call Event Groups. This release adds the ability to import events from a Hy-tek Events File (.hyv). Events are managed (added, deleted, imported, re-ordered, etc.) within the context of an event group. In Phase 2 events will be connected to a swim meet via an event group although the swim meet will still retain the ability to re-order the events on a meet by meet basis.
Key features in this release are:
Phase 1 of overhauled Event Model is complete. The new Event Model introduces the concept of Event Groups. Events are now defined in the context of an Event Group. Swim meets currently do not have any connection to Events but that will chance in a release fairly shortly in Phase 2.
Added ability to import events from a Hy-tek Events File (.hyv) into an Event Group.
Added ability to delete all events from an Event Group.
Changed Google Maps API Key from required to optional. If the API key hasn’t been entered, wp-SwimTeam will now gracefully work without it.
I changed a lot of code in this release, if you run into anything odd or functionality that isn’t working or behaves differently, let me know ASAP and I’ll do my best to fix it quickly. Now that I am back to a stable code base I should be able to turn bug fixes pretty quickly. That is hard to do when you’re doing a bunch of remodeling!
This release has been committed to the WordPress Plugin Repository so you should an update notification on your Dashboard. You can also download it and manually update it from the Download & Installation Page.
Edit (4/16/2012 @ 10:07 AM): This update includes a database update so you must de-activate and re-activate the plugin after updating to have the database upgrade run. One of these days I’ll figure out a more elegant way to do this!
I ran into a problem this past week that I am not sure will affect anyone else but my own swim team. Our volunteer coordinator let me know that she was unable to add new jobs. I couldn’t replicate the behavior in my development area which required me to debug it on the live server (ugh).
Because most of the things I add and/or changes I make to wp-SwimTeam are for the MacDolphins (but not always), I usually test them on the MacDolphins web site before releasing an update. When I first added the Jobs module to wp-SwimTeam I had defined column names in the database table. At some point I decided to be more descriptive with my names and changed the column names. I think, but I can’t be sure, that I did this before publicly releasing the plugin update. WordPress usually, but unfortunately not always, handles database schema changes correctly and will change column names.
In my case, WordPress, for whatever reason, didn’t change the column name, it defined a new one. While this isn’t of itself a real problem, having a few unused columns in the database isn’t preferred, it isn’t a real big problem either. Except that the default value for the column was never defined (oops) and at some point, MySQL (maybe MySQL5) started to care that the column wasn’t initialized.
The net result was we was we were unable to add new jobs because MySQL was returning an error message due to the uninitialized column that wp-SwimTeam wasn’t accounting for. The simple solution for us was to simply delete the columns that shouldn’t have been there in the first place and won’t ever be there for people using the plugin now.
In the process of chasing this problem down, I found an area of my database interface where I wasn’t properly accounting for possible database errors. I have updated the database interface class and the Jobs module which sits on top of it. Over time I will also retrofit this change into other parts of the plugin as I work on them.
Look for a plugin update to be released in the next day or so.
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.
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.
I have one more feature to add to the Jobs module before I consider it complete. I have a request to be able to send out Reminder Notifications on a per swim meet basis which should be pretty straight forward to implement and I hope to have it done in the next day or two.
Once that is complete, I need to decide what to do next. I have a couple of choices.
I’ve had a couple requests to be able to import a roster into wp-SwimTeam. I don’t think this will be too difficult technically but it does require a couple decisions. Since swimmers in wp-SwimTeam are connected to parent or guardian users, what WordPress userid would the imported swimmers be connected to? The obvious choice is the Admin user or user running the import. Swimmers could then be updated at a later time to connect them to the appropriate WordPress user if/when it exists.
Import results. This has long been on my to-do list because the MacDolphins need it. I’ve been working on processing results off an on as a side project (see Flip-Turn) with the intent to fold that work into wp-SwimTeam when it is functioning and useful. I already have a lot the functionality working and the GUI will look familiar to wp-SwimTeam users but I have yet to tackle relays and really push the robustness of the SDIF parsing.
Hy-tek/SDIF compatibility. This is also something I need for the upcoming season. Anyone who has read much of this blog knows that I am not a big fan of Hy-tek and their goofy checksum and weak support of SDIF. Since it isn’t likely to change and lots of teams use Hy-tek, we need to resolve the data exchange problem. This issue may be the highest priority for me personally and I’ve debated whether to build some functionality into wp-SwimTeam to try and resolve sharing data with Hy-tek teams.
Comments and suggestions are welcome. I try to incorporate suggestions quickly if I can.
I have just released wp-SwimTeam v.1.5.579, you can find it on the download page and shortly, via the automatic plugin updater. This release fixes an issue which has bothered me personally for a long time.
There was a problem in the E-mail Confirmation code for both registrations and opt-in/opt-out. This same code was used for the new Jobs module so it existed there too. For a long time the confirmation e-mails were duplicated and if a swimmer had to two contacts, only one of them would receive the e-mail. I have finally found and fixed this problem so e-mail confirmation should be cleaner and sent to the appropriate people.