Register for InstructureCon25 • Passes include access to all sessions, the expo hall, entertainment and networking events, meals, and extraterrestrial encounters.
New FERPA requirements for cross-listed courses! and others have commented on the problems of cross listing. However, the ability to do cross-listing is controlled by the same permission as being able to create/edit/delete sections. I find this to be odd. I think that the ability to cross-list should not be tied to the ability to utilize sections within a course.
As the app/controllers/sections_controller.rb has the following code (with the relevant line highlighted):
# @API Cross-list a Section
# Move the Section to another course. The new course may be in a different account (department),
# but must belong to the same root account (institution).
#
# @returns Section
def crosslist
@new_course = api_find(@section.root_account.all_courses.not_deleted, params[:new_course_id])
if authorized_action(@section, @current_user, :update) && authorized_action(@new_course, @current_user, :manage)
@section.crosslist_to_course(@new_course, updating_user: @current_user)
respond_to do |format|
flash[:notice] = t('section_crosslisted', "Section successfully cross-listed!")
format.html { redirect_to named_context_url(@new_course, :context_section_url, @section.id) }
format.json { render :json => (api_request? ? section_json(@section, @current_user, session, []) : @section) }
end
end
end
The check for authorized actions means that:
Unfortunately, cross-listing provides a sneak path to add students to a course (as a teacher without administrative rights, but with the ability to create sections does a cross-listing - the students will be added to the target course - despite the fact that teacher does not have rights to add students to the course).
Moreover, if the current user can manually add students to the target course, then they can always add each of the students from a section to the target course. This means that there needs to be a check in the above code on whether the current user can enroll students in the target course.
Therefore, the second test should be something similar to:
authorized_action(@new_course, @current_user, :manage) && authorized_action(@new_course, @current_user, :manage_students)
Where (based on looking at ./app/models/role_override.rb and spec/apis/v1/enrollments_api_spec.rb) :manage_students would enable the creation of student enrollments. Thus unless the user is allowed to enroll students in the target course, the cross-listing would not occur.
If the permission to add students ( permission: Users - add / remove students in courses) to imported courses (i.e., courses that are automatically created by SIS imports) is disabled for the "Teacher" role, there should not be a problem in allowing teachers to create/edit/delete sections - while still meeting FERPA and other similar regulations (as there would not be any ability to cross-list a section worth of students and each section would only be within a single course). In fact, the use of sections could be used to reduce the visibility and interactions of students (and even teachers) to within their section, thus advancing student's privacy.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I was the professor for Computer Communications at KTH Royal Institute of Technology in Stockholm, Sweden during the period 1994-2023. As of 2023-04-01, I am now professor emeritus.
To interact with Panda Bot in the Instructure Community, you need to sign up or log in:
Sign In