I tried to submit some memberships the normal way this past weekend. It was a complete fail. I couldn’t even do it for just one membership. I would consider the system completely broken at this point. I talked to Boyd about it on the phone, so hopefully they are aware of it. However, I was able to submit the memberships using the new CSV batch processing. That worked at least.
Where do you see the option for submitting memberships from a CSV file?
I found the option on the dashboard.
Have you tried submitting memberships with various magazine options, to see if the amounts charged are correct?
I haven’t. All the memberships I had so far were without the magazine.
Is is new that renewals require birthdates? I thought they were only needed for new memberships? I’ve encountered this roadblock on the csv batch and on the web form.
I think birthdates and gender information are now both required.
I think the options for gender information are:
Male
Female
Nonbinary
Unknown/Prefer Not To Answer
TDs need to get in the habit of collecting this information when they accept a membership, along with complete mailing address information and preferably a unique email address, too. Affiliates purchasing vouchers under the group membership plan should also have this information available when redeeming a voucher. (If there is no unique email address on file, that member will not be able to take advantage of several membership benefits available through the US Chess website.)
Recently we noticed that there are nearly 400 current California members that we cannot classify as being part of the CA-N or CA-S affiliates because we have no valid ZIP code. This could conceivably affect apportionment of Delegates.
Well, this was news to me, only now the tournament has concluded, people are traveling or working. How much time will it take me to track down 8 people who are dodging election spam phone calls? Likely longer than the FIDE deadline. Frustrating. I also have a partially completed web form that is jammed in incomplete status. I can’t delete it or complete it unless I start faking birthdates, which seems tempting.
We’ve been advising TDs to collect complete information on memberships for YEARS! I suspect I’ve posted that suggestion dozens of times since 2005.
If you need players registered with FIDE, they also require a birthdate.
I haven’t tried it recently, so I don’t know if it’s still doing it. The bug that I ran into was that for a renewal, it would not prompt for stuff it didn’t know as usual (like birthdate/gender, etc.). This is the same as it has been. However, when you hit “Next” to actually submit the memberships, it would report an error saying that birthdate and gender were missing. Uh, OK? Well, you put in the appropriate information and then hit next and then it would complain about something else. The birthdate and gender boxes were no longer there. Well, you fix this issue and hit next. Guess what. The missing birthdate and gender errors are back. And so on and repeat…
No matter what the membership could not be submitted. The backdoor approach was to use the CSV batch method. This did not require the birthdate and gender info.
I have been trying the csv workaround, but the birthdates are stopping me today. Again, these are RENEWALS, not just new players. The USCF should already have the birthdates and I’m just duplicating birthdate collection now and raising hackles on identity theft.
I’m not new to the data era and have worked through ratings reports with 50+ errors over the past 15 years. Maybe I’m too old now, but I’m thinking I won’t be able to be self-reliant any more when dealing with the data processing and will need a USCF-employed facilitator soon, as if this era of short-staffing can afford people to become unable to help themselves.
The old membership process (the one I wrote in 2004/5) would not require an address unless there was no valid address on file.
Apparently that’s not an easy thing to do in Civi-CRM/Drupal. It may also violate the leakproof process, ideally no US Chess systems should make it possible to find out information beyond what’s already publicly available.
The tournament database already tends to violate the leakproof process, because one can often infer someone’s age by looking at what sections they play in, and can infer their location, at least somewhat, by looking at where the events they play in were held. And of course anyone who qualifies for an age-based Top 100 list has their current age listed, which could probably be used over time to narrow down a player’s birthdate to a month or so. But FIDE publishes birth years, so any player in the FIDE database has that information out there.
I apologize if I was venting my passive aggressive frustration on you, Mike. For what it’s worth, seeing the current Drupal version has made me really appreciate the version you wrote 16 years ago. You did great coding for a very complicated process.
People forget the things that didn’t work, especially at first, though. And I was never really happy with the TD/A membership batch process, I just didn’t know how to improve it.
I’ve had some initial discussions with our new IT project manager (he started on Monday), who is a chess player as well as a Civi-CRM and Drupal coder. I’m looking forward to walking him through the way the tournament submission and ratings systems currently work and discussing the process for rewriting all that code. I’m hoping to have a significant role in the testing of the new system so that we can fix most of the problems before trying to launch it.
And don’t worry about the venting, if I was still actively organizing and directing tournaments I’d probably be as frustrated as you are, too.
When I did the CSV batch I just left the birthdate and gender fields blank. I only filled in the minimal required fields and left everything else (address, etc.) blank. It was accepted just fine.
@Bill Buklis: I know that you bypassed the gender and birthdate requirements before. I’m curious if you repeated that it works applicable to this week.
I just made it through the process. The gender requirement was still stopping me. I followed the documentation and used “1” for female and “2” for male, but that didn’t work, so contrary to the instructions, I switched to “F” and “M” and finally got through. I guess I hadn’t attempted leaving gender blank like Bill did.
But when I entered payment information, the messages seemed unclear as to whether the payment worked, so I probably double-submitted the credit card. Some of the unrateds now have 2 membership IDs showing in the old MSA. I guess we’re stuck in another technical limbo area.
To pile on complaints, one of the renewals had a member with an invisible space at the end of their last name. This was visible on the MSA, but I couldn’t get the CSV file to match the valid last name even though it "looked " alike.
This is great news, and I fervently hope that the Civi-CRM people and the U.S. Chess EB will welcome the offer.
I have the feeling that, no matter how “retired” Mike Nolan claims to be, his presence will always be necessary to straighten out the kinks in these external software packages.
Bill Smythe
I am something of a hawk when it comes to data, I prefer dates that make sense over ones that do not make sense (like someone whose birthdate is decades if not centuries in the future due to a typo or more than some number of years ago), I also prefer names that don’t have extra spaces in them, because those mess up search engines. (Names with non-Latin characters in them are a separate matter, as is capitalization.)
I will let our IT group know that we (either still or once again) have several thousand names in the database with extra spaces in them, and that there are still nearly three dozen member records with illogical or impossible birthdates in them. I cannot guarantee that anything will be done about it.
Yes, those bug me too. Whenever I write an Excel sheet that allows users to type a name, I always apply the TRIM function to remove leading and trailing spaces, and to convert multiple consecutive spaces to a single space.
ALL software should do that. Are you listening, Civi-CRM?
That’s another pet peeve of mine. Accept birthdates only if they are in the range 1920 through 2019, or some such. If they supply only two digits, add 1900 if it’s 20 or more, or add 2000 to it if it’s less than 20.
Again, Civi-CRM, are you listening?
Indeed. Use a function like PROPER, or something similar.
The IT people should have known that there would be problems with any third party software, and that we didn’t want a black box that we could not correct ourselves.
I’m venting with you.
Bill Smythe
I don’t know enough about Civi-CRM internals to know if it is the source of the problems, though one would think that membership organizations, the primary users of Civi-CRM software, would not want extra spaces in member name fields for the same reasons that we don’t want them, they mess up member searches.
But maybe they just have a ‘name’ field, not separate fields for first name, last name, etc.
Civi-CRM, like most 3rd party canned packages, has a capability for user-defined data fields, and anything that we need that isn’t a pre-defined field would have to be in user-defined data fields. This would include nearly everything chess related. These user-defined data fields have no inherent data restrictions in them.
If member first name, member last name and membership expiration date are user-defined data fields, then it is incumbent on the people doing the programming to add those user-defined fields to also add data sanity checks. I know I made this point more than once in the briefing meetings I had with the people doing the membership system programming.
Birthdates are sort of a special case, you can make a good argument that there should never be a birthdate in the future for a US Chess member, but you cannot make that argument for all organizations, or for most other date fields, like membership expiration date.
As to birthdates in the past, we have data on members going back to when US Chess records were computerized in the mid 1970’s. It is not inconceivable that we could have had living life members back then who were born before 1880. As far as I can tell, the oldest living life member these days was born after 1920. (My suspicion is that if I were to run a list of members older than 90, there could easily be one or more members on that list who aren’t really over 90, their birth year is wrong.)
I think the sanity checks that were put into the membership system recently no longer allow birthdates in the future or more than 150 years in the past.
There is no rule that says the same sanity checks have to be used everywhere, so it might be reasonable to allow staff editing member records to enter birthdates back in the 1800’s but not allow birthdates earlier than 1920 for membership transactions being made by members or TDs.
I believe most of the birthdate problems are due to data entry mistakes. The most common is to put in the current year rather than the birth year. A membership transaction form could complain about any birthdate that would make the member less than 3 years old, we don’t get many members that young. (We do get some, I knew someone who bought a life membership for his son on the day he was born, I think it was still $200 at the time.)
Another common mistake is to transpose digits, so 1981 becomes 1918, creating a 104 year old member rather than a 41 year old member.
Requiring birthdates that are consistent with the type of membership being purchased is also possible, but we do get people who choose to buy an adult membership for a child, your guess as to why they do that is as good as mine. Should we not accept the extra money? That becomes a policy matter, not a programming decision.
Thank goodness I’m not actively running tournaments right now!