Record Management

The record management form was developed for internal use when we migrated to the SIS Framework and left snapshot in the dust. Previously my boss would the override snapshot SQL script, but, since that no longer works anymore, she needed a way to override or even just simply adjust records such as users, courses, and enrollments when I wasn’t around to do the dirty work. The form takes place in two parts.

The first part of the form as seen below is where you simply enable or disable the record. You do have the option to override the SIS framework which, if you’ve chosen the “Course Enrollment” or “Insert Manual Override” selection will take you to the next part of the form. Below is an example where I enable my enrollment in the course XL-WBCT-1003-010IN-FA2014 and choose to override it. *Note: The code automatically takes into account that the record availability indicator is set to N if it’s disabled and accordingly updates it to Y if you’re choosing to enable a record.

rm1

Now, if this were simply a user or a course and not an enrollment, running the update and overriding the SIS framework would not require the use of a second form. It’s simply a little easier to insert the overrides for them.

If you haven’t already checked out my other pages talking about overriding the SIS Framework, well, basically the process I’ve implemented is to create some tables in a separate schema in our main Blackboard database that a script checks against. The script selects all of the rows from the table, inserts them into an array, and then looks for them in a feed file. If the row is present, it removes it so that it doesn’t get processed and effectively undo the update you just made. That’s the simplified version. So basically if you enable a record such a user, you’re effectively inserting a row into a tablet that looks like:

Because that’s the line in the record that is causing a record to be disabled. To “override”, you simply look for that line in a feed file and remove it. It’s not as fluid as setting a data source to SYSTEM but it gets the job done.

Now onto the next form. This is what’s presented when you either do a manual override or override a course enrollment. A manual override would come in handy when you know in advance if a feed file is going to come over that will cause potential issues with records that are already set to the way they’re supposed to be. For example this is a good way to get around the pesky merge enrollments bug where a student’s availability in one course is set to N in one course and Y in another, effectively making them unavailable in the master source.

rm3

As you can see there are plenty of notes for users to guide them along making the correct input choices for the override.

Since you enabled my enrollment in the course previously and now want to override it, you need to enter “N” for the available indicator and “disabled” for the row status. As previously mentioned: this “override” equates to the row in the enrollments feed file that is causing the record to become disabled, so, you look for it, remove it, and your record remains untouched.

If you choose the dropdown box above the fields to “User” or “Course” ┬áthe fields will change to the appropriate headers for those types of feed files.

Lastly at the bottom of my page unseen in the first two screenshots is simply a history of changes stating who made an update and when. It’s simple but a nice history to track changes to records.

rm2

The source code for the first form:

The source code for the second form:

 

Leave a Reply

Your email address will not be published. Required fields are marked *