canvas-lms/app/controllers/user_lists_controller.rb

32 lines
1.2 KiB
Ruby
Raw Normal View History

2011-02-01 09:57:29 +08:00
#
# Copyright (C) 2011 Instructure, Inc.
#
# This file is part of Canvas.
#
# Canvas is free software: you can redistribute it and/or modify it under
# the terms of the GNU Affero General Public License as published by the Free
# Software Foundation, version 3 of the License.
#
# Canvas is distributed in the hope that it will be useful, but WITHOUT ANY
# WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
# A PARTICULAR PURPOSE. See the GNU Affero General Public License for more
# details.
#
# You should have received a copy of the GNU Affero General Public License along
# with this program. If not, see <http://www.gnu.org/licenses/>.
#
class UserListsController < ApplicationController
2011-02-01 09:57:29 +08:00
skip_before_filter :verify_authenticity_token
before_filter :require_context
2011-02-01 09:57:29 +08:00
# POST /courses/:course_id/user_lists.json
refactor user creation/invitations closes #5833 fixes #5573, #5572, #5753 * communication channels are now only unique within a single user * UserList changes * Always resolve pseudonym#unique_ids * Support looking up by SMS CCs * Option to either require e-mails match an existing CC, or e-mails that don't match a Pseudonym will always be returned unattached (relying on better merging behavior to not have a gazillion accounts created) * Method to return users, creating new ones (*without* a Pseudonym) if necessary. (can't create with a pseudonym, since Pseudonym#unique_id is still unique, I can't have multiple outstanding users with the same unique_id) * EnrollmentsFromUserList is mostly gutted, now using UserList's functionality directy. * Use UserList for adding account admins, removing the now unused Account#add_admin => User#find_by_email/User#assert_by_email codepath * Update UsersController#create to not worry about duplicate communication channels * Remove AccountsController#add_user, and just use UsersController#create * Change SIS::UserImporter to send out a merge opportunity e-mail if a conflicting CC is found (but still create the CC) * In /profile, don't worry about conflicting CCs (the CC confirmation process will now allow merging) * Remove CommunicationChannelsController#try_merge and #merge * For the non-simple case of CoursesController#enrollment_invitation redirect to /register (CommunicationsChannelController#confirm) * Remove CoursesController#transfer_enrollment * Move PseudonymsController#registration_confirmation to CommunicationChannelsController#confirm (have to be able to register an account without a Pseudonym yet) * Fold the old direct confirm functionality in, if there are no available merge opportunities * Allow merging the new account with the currently logged in user * Allow changing the Pseudonym#unique_id when registering a new account (since there might be conflicts) * Display a list of merge opportunities based on conflicting communication channels * Provide link(s) to log in as the other user, redirecting back to the registration page after login is complete (to complete the merge as the current user) * Remove several assert_* methods that are no longer needed * Update PseudonymSessionsController a bit to deal with the new way of dealing with conflicting CCs (especially CCs from LDAP), and to redirect back to the registration/confirmation page when attempting to do a merge * Expose the open_registration setting; use it to control if inviting users to a course is able to create new users Change-Id: If2f38818a71af656854d3bf8431ddbf5dcb84691 Reviewed-on: https://gerrit.instructure.com/6149 Tested-by: Hudson <hudson@instructure.com> Reviewed-by: Jacob Fugal <jacob@instructure.com>
2011-10-13 04:30:48 +08:00
# POST /accounts/:account_id/user_lists.json
2011-02-01 09:57:29 +08:00
def create
return unless authorized_action(@context, @current_user, @context.is_a?(Course) ? [:manage_students, :manage_admin_users] : :manage_account_memberships)
2011-02-01 09:57:29 +08:00
respond_to do |format|
introduce preferred user list search mode closes #7059, #7411 preferred is a compromise between open registration and closed registration. if a single user is found, that user is found without introducing any temporary user to allow user disambiguation. if no users are found, or multiple users are found, it's the same behavior as open registration. as part of this, the "only search existing users" checkbox has been removed. instead, preferred searching will be used in the following cases: * adding an admin, and open registration is enabled * adding an admin, open registration is disabled, and the user has permission to create new users * adding a user to a course, open registration is enabled, and delegated authentication is in use * adding a user to a course, open registration is disabled, and the user has permission to create new users the notable case that preferred searching is not used, and the user would want to use search existing users is open registration enabled, and adding a user to a course. in this case, a temporary user will be created instead of sending the invitation to the existing user. however, the end user experience is identical (invitation sent to e-mail, invitation visible in the same locations in the UI), with the small exception that the end user gets the opportunity to create a separate account if desired (but not preferred). test plan: * go through each of the cases above for a user that doesn't exist yet, a single matching user exists, or multiple users exist. it should behave as described above Change-Id: Idbc7fe23bfc7430b4cd25f7981f5dc08b9e4ffda Reviewed-on: https://gerrit.instructure.com/8966 Tested-by: Hudson <hudson@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com>
2012-02-24 06:24:48 +08:00
format.json { render :json => UserList.new(params[:user_list], @context.root_account, @context.user_list_search_mode_for(@current_user)) }
2011-02-01 09:57:29 +08:00
end
end
end