Trying to submit a tournament report yesterday I ran into a problem I can’t get around. The affiliate listed in the rating report is not the affiliate I put in. I checked the thexport file and the correct ID is in the file. I figured out what the problem is.
There is an affiliate field dropdown in the rating report. This lists several of the affiliates I am authorized for, but not all of them. The list currently has 11 entries (I work with a lot of different affiliates). In this particular case the affiliate for this tournament is not included in this list. As a result I can’t select this affiliate for the tournament. And since it isn’t in the list the page is auto-selecting the first affiliate in the list which, of course, is not the correct one.
Who is the best person to contact for this?
What I could do is submit the tournament under the wrong affiliate which will have the Chief TD authorized for it. Can this be easily changed afterward to the correct affiliate?
I’ve noticed additional oddities with memberships in the tournament rating report where either the rating report or MSA thinks they are expired, when it isn’t. But, I expect those and can work around it.
Bill, you are authorized for 19 affiliates, but 9 of those are not current, 2 lapsed at the end of September and one at the end of October. It only lists current affiliates, so it only lists the 11 that are current and active. (There’s a 30 day grace period.)
If the affiliate you want to use is one of those lapsed affiliates, it needs to be renewed.
As to updating the event to change the affiliate ID, changes to rated events should be sent to ratingsmgr@uschess.org.
MSA isn’t the primary member database, and since July of last year Gambit hasn’t been the primary member database, either. Memberships are kept in CIVI-CRM, which is on another server.
For the most part, new, renewed or updated memberships are updated on MSA within about 5 minutes, though failures can occur. I don’t know the process they’re using to check for failed updates.
Gambit is only refreshed twice a day but the validation program checks the live database for IDs that are either not found on Gambit or are not active/current on Gambit. Checking the CIVI-CRM database takes a lot longer (like 500 times longer), so we only do it when the information on Gambit isn’t sufficient to validate the ID. But if there’s an issue with checking the remote database (rare but it does happen) then it wouldn’t know the ID is valid and current.
Yes, that was exactly the issue. I just found out myself. I should have realized that his affiliate had expired, but then it is the first time I’ve run across this. It makes total sense. I’m sure he’ll get his affiliate renewed straight away.
I have another idea, which might work (although I doubt it). Heh heh.
If the two affiliate lists differ by one, due to a recent or upcoming expiration, specify the next affiliate in the list.
For example, if there are 11 affiliates in one list and 10 in the other, and the desired affiliate is number 7 on the longer list and omitted from the shorter list, specify whichever affiliate is number 7 on the shorter list. With any luck, the U.S. Chess software will just look at the pointers (i.e. the number 7), and choose number 7 on the longer list.
Yes, I know. It probably won’t work. I said that already.
I’d make that probably a definitely. What if you want the 11th affiliate on the longer list which is 10th on the shorter list? Using a pointer would make the correct affiliate unavailable, so no programmers worth their salt would do it that way.
Yes, I know, my scheme wouldn’t work anyway if it was the last affiliate on the list.
I find myself wondering, though, whether some of the programmers who are rewriting our website ARE worth their salt. Mike Nolan has already told us that CIVI-CRM takes 500 times longer than the old way.
The reason it is so much slower is that instead of doing a lookup in a membership table that is part of the PostgreSQL database (which takes a few milliseconds), you have to look it up in a different membership table (actually a set of joined tables due to how CIVI-CRM stores data) using a different database platform (MySQL) on a server located several hundred miles away using an Internet connection and with a procedure called a ‘foreign data wrapper’ that allows the native database platform to communicate with other types of database servers. In tests, this can take five seconds or longer for each lookup.
I don’t have access to the CIVI-CRM server to run tests for how long it would take to do that same lookup in the native database platform (MySQL) running on the same server, even with all the joins, but I assume it would be much faster than five seconds.
Please note that I have conveniently re-arranged your first sentence so that all the words are in alphabetical order. That way, it is about as easy to read as it was before.
Once upon a time, we had custom software (mostly written by you, Mike) that did exactly what it had to do, directly. With the software upgrade, we now have canned software, which is large and does all kinds of things we don’t need, but still does not do everything we do need. I fear this may be our future.
The new software does things the office needed that the old software couldn’t do, especially in the area of fundraising and 501(c)(3) compliance.
There’s always some give-and-take in a software development project, using a canned package like CIVI-CRM has its pluses and its minuses, the minuses mostly have to do with extending it to do things that aren’t part of its core function. Unfortunately, a complicated membership structure with add-ons like magazines, third party membership batching and family plans are all outside of that core function. And I suspect the voting member stuff is a further complication.
The tournament/ratings stuff (that I mostly wrote in 2004) is also in need of updating, I doubt there’s a canned package that will be able to handle it. But custom development is always a LOT more expensive. And replacing an existing package creates complications that writing one from scratch (like TD/A) doesn’t have.
When I was doing that coding in 2004, the TD/A stuff was a lot easier to get working, because it was all brand new, than the ratings programming, because we needed to make sure that the new programming did the same things the old one did, coming up with the same ratings. And even then there were a few edge cases that never quite came up with the same rating, for reasons that were not clear.
In rewriting the tournament submission modules, some things will likely change. I can safely predict that not all of these changes will be seen as improvements by TDs.
I realize that I never really bothered to look at that field as it was always the correct affiliate from the upload. The only reason I noticed it was that the rating report refused to validate since the chief TD wasn’t authorized for the default selected affiliate. When trying to figure out how the chief TD couldn’t be authorized when I had already verified that beforehand is when I realized the affiliate had changed. If coincidentally this chief TD was also authorized for the first one in the list it probably would’ve taken longer to figure out what happened.
A better solution would be to include the bad affiliate in the list and selected, but with a note saying this affiliate isn’t active or some such. Then it would be obvious. Only the one invalid affiliate needs to be included.
It is supposed to be possible to use the token on an item in a select list to make that item unselectable, but I’ve never used it that way. In your case, we’d wind up listing 19 affiliates, including all the expired ones. Might even be possible to use the function to list active affiliates first, then lapsed ones.
But this hasn’t seemed to be a major problem over the last 15 years, is it worth a few (billable) hours of developer time?
No, not quite what I meant. It would have only 12 entries. The 11 valid ones plus the submitted one flagged as invalid. The backend would then reject validation with a note saying that this Affiliate cannot be used because it is expired (or some such error). This would make it blatantly obvious what the problem is.
Now, is this worth changing? Probably not as this is theoretically a rare occurrence.
Heh heh.
