...
The fix was assigned to Fred Roos from fruition while he was at 25 Science Park. Backeberg and Roos sat in a cubicle and pair-programmed the solution, saved as update set 2014/01/30 - 1. The fix is a modify to the user import transform scripts to treat these unicorn alumni as active users, even though Central Auth knows they have graduated and should be inactive. This fix was a good start, but there were lingering problems. Those issues were finally settled on update set 2014/03/28 - 1.
Testing the fix
We need to identify some unicorn alumni, and then confirm their status in the system.
...
When I compare those I get like 3640 active 2013 alumni, and 18 inactive 2013 alumni. I don't see any reason it should not be 100% active, and I think there's a subtle bug in the way Fred wrote the alumni check. I think this needs a slight amount of work to be correct.D941 works properly, there should be zero users who graduated in 2014 and are NOT set active.
How to ingress fake mail to TEST
It is possible to ingress fake mail to TEST, but the process is a lot of effort for low return. Basically, the way you do this is you send mail to PROD service now as the user you want to emulate, then you copy and paste the received message details from PROD service now into TEST service now, then tell ServiceNow to 'process message' on the fake received mail you created manually in TEST. Does that sound hard? It is. Verifying the user detail is a sufficient test of this bug.
Backeberg reticence for releasing this
As I wrote up the test cases for this, I spotted several anomalous users in TEST and DEV. I quickly discerned that IST imports in DEV and TEST were broken. After I fixed those, I noticed further issues. We do special processing on imports for IST table, where we only run the transform script on a row entry in the import table if the value changed from the last run. As these values are only changing rarely, very few records are getting updated that would use the changed transform script. Ergo there were several users that were not fixed by the changes for D941.
Therefore there will also need to be a manual deploy for part of D941. We will need to do a one-time change to set all affected records to Active.
And that reminds me of a compounding bug. If we are also setting the graduated for a certain year, and then the next year rolls around, and the records continue to not change, those records will continue to be Active, even though the reasons for that will no longer exist.
I think one possible way to fix this entire issue, rather than doing this one time change, is instead to do a delete of all of IST, or at least a delete from IST of all the unicorn users. This would force THOSE records to all go through the update process.