The MSIX system has been providing enhanced error reports for submitted files for quite some time. They originally only sent the files known as SSORI which only contained very basic error information. But a few years ago they started to send the SSOREI files that have much more detailed error information in them. My initial implementation for processing these SSOREI files would simply bundle up the various errors and submit them to our status logging system which would in turn send them to me in an email. For a couple years after that, I contacted states personally whenever I got reports from MSIX about "invalid values" in the submission files, and we would work through the issues together.

We've got a new person here at MS/EdD, which is pretty exciting for us. Jeff no longer has to be the "new hire" now that he's been here for fifteen years. You may have noticed that we've tried on a couple new people over the past year or so, but they just didn't seem to fit. But we think Kati will be here a while and we think you're going to like her. It will take us some time to get her fully up to speed, so try to be gentle during that period. But she's a fast learner and should be an increasingly visible presence to all of you. She's got more degrees than any decent person should have, some hopefully useful experience in the wide world of education, and I'm told she speaks a bit of Spanish although you couldn't prove it by me. She'll be working the ground somewhat between Jay and Marcy while trying to learn from both.

Indiana has been our worst kept secret. Usually when we bring a new state on, I wait to send out a wecome post until we've got them all connected up with MSIX and somewhat stable. But Indiana is a special case because they're still using their old system for their MSIX connection and that may continue for quite a while yet. So I'm going to go ahead and give a belated but no less enthusiastic welcome to Emily Salinas, Adrian Martinez, and last but not least Valerie Beard who is out with her new baby right now. Adrian has probably set a record for giving me the most really thoughtful Suggestion Box entries in such a short period. Several of his ideas have already been added, and one will be going out soon. I'll probably cover it in the next post. So anyway, Wecome Indiana!

Many of you have heard us say something like, "This will go out in your next release." Whenever we do some kind of enhancement or change for your state, we'll typically "check it in" which makes it ready to be shipped out. But it may be days, weeks, or sometimes even months before it will actually show up in your production system. So you might not always know when to go looking for whatever the change was. But if you go to your MIS2000 web application, you can always see the current release date of your system. Many of you use the MIS2000 web application every day, but if you're not familiar with it, you can just go to <your state>.msedd.com to see it. For example, in Alabama you'd go to al.msedd.com. Or in Minnesota, it would be mn.msedd.com.

I know over the years I've found myself occasionally saying, "With more digging, I think I could work out exactly..." This usually arises after I've been asked to figure out how a student or a COE got to be the way it is. For all of the desktop and tablet machines that periodically upload, we've always had very good evidence left around about who changed what when in the form of transaction files. Everything that came in from the field could only come in through these files, so whatever happened had to be contained in them somehow. It often took a good bit of digging, but we could pinpoint exactly what happened. But for changes made directly on the state system, we couldn't depend on this mechanism since the state doesn't upload to itself. But at the state level, we always had good backups that we could rely on to let us see when things changed, and since there are very few people who have direct access to the state, we could usually work out what happened ...

This is another suggestion that came to us from Adrian Martinez in Indiana. He wanted a way to add Services for all the students on a COE. It had never struck me before, but every COE is essentially itself a list of students, so why not just expose all the functionality we currently have for Student Lists for COEs? Kind of obvious but I'd never considered it before. If you want some more blog posts on the evolution of Student Lists over the past few years, look here and here.

I'm not even going to dig back through my old blog posts to see what I've written about autologout in the past. Suffice it to say it has never worked well and I've been hating it as long as anyone else. It just had all sorts of issues. So a few weeks ago I buckled down and completely rewrote the whole thing from scratch. And I think it's going to be much, much better now. Basically, just about anything counts as "activity" now. If you type anything into the page or move your mouse over it in any way, it will recognize that you're there and keep your connection to the server alive.

Last fall I blogged about having introduced an export for your Student Lists here. So now whenever you do the export, you'll see the Student ID as the leftmost column:

You may have received an email from the MSIX team last week with subject "Changes to the Batch Submitter Accounts for MSIX Data Submission". I just wanted to make sure everyone knows we're aware of the change and have been working with the MSIX team to test our support for the new authentication protocol. There's nothing any of the states need to do. We'll take care of the whole thing.

Back in blog post Enrolled Students filter in Web Search I talked about having added an Enrolled checkbox for filtering student search results. Some time after that we decided to add the additional ability to filter by enrolled within a particular school year. It looks like this: