Enrolling Administrators

One of the challenges of having 42 institutions is managing the administrators. (Actually we created some 12 spare institutions but why is anotherĀ  post.) So my challenge was how to not drive myself insane trying to enroll the 6 same admin users to each institution. The best way in my opinion is to create the users in an IMS XML file for each institution and import the data. Creating the users was easy. Next was doing the enrollments.

Naturally, I turned to the Vista 8 Enterprise System Integration Guide on pages 66-67 and 95-96 where it describes which roles can be enrolled at which learning contexts. They go from the lowest most common enrollments at the section level up to the division level. Yeah, there was not anything for the institution level. It even had a comment before the table on pages 66-67:

NOTE: Roles not specified in the table can only be added through the Vista Enterprise administrative interface.

So, because the Institution Administrator is not listed, I could not enroll users to it through the import? It depressed me for about a week. A flash of inspiration had me check the Vista 3 documentation. Sure enough, on page 49 of the Vista 3 System Integration Guide, Institution Administrator is listed. (Admin roles at domain and server contexts, designer roles at instiution and domain contexts are also listed.)

The XML is easy enough to write. Normally, when writing this XML, I just need to refer to the SourcedId for objects I create, so I know their values. However, with this, I need to the know the SourcedId.Id for the institution.

Fortunately, we have collected the properties to a institution.properties and parse it to generate what to run at the command line. Rather than by hand copying the files into place one-by-one, I created a script to take a template, check this institution.properties and place the files in the correct place. In order to make each object unique, a portion of the SourcedId.Name was changed to the name of the destination folder.

Now I just need to add to the script a portion to change the SourcedId.Id for the Institution to the source_id value in the institution.properties. That is easy. Much easier than figuring out where to look in the documentation to find what is correct.


In spelunking the Vista database, the main pieces of an enrollment are the user, the learning context, the membership, the role, and the role’s label. Its almost trivial how easily these tie together. Once you have them, then you can do all kinds of cool things…

  • Administrator reports Section Designer role was deleted but the Build tab is still showing. So, you dump out the user’s enrollments to confirm the role was in fact deleted. It turns out the user had a Designer role at a higher context. [1]
  • Instructor reports students who were never enrolled in the section appear as having missed an assignment. Support at the school says the it has a template, so naturally the vendor thinks it must be a bad template. Wait, you say, I didn’t think student data was part of the template. That changes everything! So, you dump out the enrollments for the members of that learning context to see who is or is not enrolled. Oh, the students were enrolled in the class. They are just deleted now.

[1] Designer access at a higher level means the Build tab shows. So if you hold Institution Designer and Section Instructor, then you have the Build tab you’d normally expect to need Section Designer to use.