Is Visit a content item condition met when admin impersonates a user?
While helping a student today, I wanted to walk through some content on her behalf to make a section of a course available to her. It seemed as if visiting content while impersonating a user doesn't make the "visited" checkmark appear. It does appear if you switch your admin role to "view as learner" but not when you impersonate an actual student.
Is this the normal expectation for impersonate? Can you point me to documentation that describes the things that can and can't be changed while impersonating, or other limitations.
Thanks.
Best Answer
-
As a Brightspace instructor, you can impersonate a student to view the course from their perspective without affecting their progress. This feature allows you to navigate through course content, quizzes, and assignments just like the student would, without logging any activity that would change their completion status, grades, or course progress records.
While impersonating, you can review how content appears to the student, test assessments, and see the layout of the platform as they would experience it. However, Brightspace ensures that this impersonation does not modify the student’s actual participation data or progress tracking. This is particularly useful for checking course settings or troubleshooting without skewing analytics or student engagement metrics. So in effect, what you describe is normal behavior of the platform and that is how it is configured. All of this is based on experience, since, even though I searched for it, I did not find the aforementioned documentation. Let's wait and see if anyone supports us.
Answers
-
Makes sense. Thanks for this. It was my best guess. Certainly the normal case is one wouldn't want impersonating to change a learner's status,
A few years ago, we had some courses that relied on an old tech product to produce a SCORM and were able to use impersonate to "clear" the faulty retention of what we referred to in the SCORM object as "bookmarks" for students in cases where platform problems meant completion wasn't retained between sessions. We redeveloped so this isn't a problem with our new versions but I was in the habit of "yup done that" being retained when impersonating because of this issue which was — in retrospect — a function of the tech used to create the SCORM back around 2015. I don't anticipate needing to "clear content" for current students in BrightSpace itself or in newer SCORM objects so it will be the rare situation (like the one I was working on when I discovered the issue reported here) when I'd want an "impersonate" session to change status for the student.
You mentioned testing. When one switches from admin to "View as Learner" one does get checkmarks for the "student view" version of oneself so that solves that use case. An instructor or admin can test conditional release using "View as Learner".
