After receiving a
complaint from an instructor unable to enroll a student in her custom made course site, I
learned that this student is already enrolled in her course, but disabled. I don't understand the reason for the disabled status, since
this course site is not a normal course, and so is not managed by our snapshot process. Of even greater concern, is the fact that the I - as Administrator - can find no tool to enable this student 's enrollment once disabled.
Since the student is disabled she doesn't appear as a User in the course.
I can see her disabled enrollment status by viewing Administrato > Users panel, but see no way to change this student's course enrollment status.
What am I missing?
Is the student's account disabled? That might explain why the enrollment looks like it's disabled. Otherwise, without knowing your processes for enrolling students in the first place, it's hard to guess how the enrollment got there or how it got disabled.
The "disabled" status is controlled by the snapshot process. You can't normally re-enable a disabled record (user or enrollment) from the Administrator GUI, unless you have a building block to do it. We used to use one called "Manage Users in Classes" from Emory University, but it doesn't work in Bb 9.1. So, you need to either re-enable or delete it via the snapshot, or directly in the database.
HI Dan, if you have not already got a reply for this:
Disabling can be managed by your system administrator with a simple query if you are self-hosting. If you are managed hosted then you can put a ticket in BTB and they will do it for you. Mostly snapshot or your enrollment processes control this process. Check with your IT folks for the clarification. There has never been a time when Sys Admins had the ability to re-enable students.
Use SNAPSHOT Manual Modes (only updates the entry in the feed file) to reinstate "disabled" objects. In this case, for "user_enrolment", create a feed file with an entry for the disabled user(s) only (remember header and footer). On the command-line invoke the following command/argument sequence (run as your Application user/owner - eg. bbuser) to action the feed file:
/<YOURPATH>/blackboard/apps/snapshot/bin/snapshot_override.sh -Ddata.source.key=<DSK_OF_ORIGINAL_USER_ENROL> -V <VIP_OF_YOUR_BB> -f ENR_MANUAL -C /<YOURPATH>/blackboard/apps/snapshot/data/snapshot.properties -t /<YOURPATH_TO_FEED_FILE>.txt
NB: will probably be disabled again after the next SNAPSHOT run if that entry has been omitted from the feed file (csv or xml)
Did any of this actually help you? Am I the only one appalled at a system that won't let you correct it's mistakes? We also use a snapshot process, and I can tell you we don't have any files that say to "dis-enable" any students. Why the heck would we? Why can't this be fixed? "It's never worked" and "there used to be a building block that fixed it but it doesn't work anymore" are completely unacceptable answers.
Cordially-Alex Sergay, Manager of Online Learning Systems, Misericordia University
You don't use a snapshot file with a list of students to "dis-enable". Rather, the way the snapshot process works is that if you run a particular feed in SNPSHT mode, that file is treated as a complete list of all valid records for that particular data source key, and any records associated with that data source key that are not included in the feed are disabled. This allows you to use feeds to, say, update the enrollments for a specific semester by simply generating a list of current enrollments, without needing to specifically construct a list of all the students who may have dropped classes since the last time you did an enrollment update.
You don't HAVE to run your snapshot feeds in SNPSHT mode. As Victor suggested, you can run them in MANUAL mode, and new records will be created and existing records updated as needed, but no records will be disabled.
© Blackboard, Inc.