canvas-lms/lib/user_search.rb

225 lines
10 KiB
Ruby
Raw Normal View History

# frozen_string_literal: true
#
# Copyright (C) 2012 - present 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/>.
user searching module refs #CNVS-2326 Added a UserSearch module that provides and interface for searching across the name, the email, and the sis id (and the database id), and added a trigram index on the columns that will be searched against. also made a slight refactor to the AR initializer in order to expose some of the behavior I wanted more granularly and added some specs to cover it fixed a small permissions bug in course.rb and pulled some scoping out of the courses controller down into the user search module TEST PLAN: This is currently not accessible from the site itself, this is just the ground work for the eventual user search api endpoint. The code is not called by anything currently in production either so there is no need for regression testing. The one thing to check would be the creation of new users (and pseudonyms and communication channels). There have been new indexes added to columns on those tables and there is some documentation indicating that writing to these indexes can be time consuming if the data set is quite large. It would be worth making sure that there have not been any unacceptable performance regressions in the creation of any of those record types in a database that has a full load of data (comparable to the production environment) Change-Id: I8fb13a6ec714f27efc8012c5ed2bed4d963c24e6 Reviewed-on: https://gerrit.instructure.com/16459 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Clare Hetherington <clare@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com>
2012-12-29 03:28:09 +08:00
module UserSearch
def self.for_user_in_context(search_term, context, searcher, session=nil, options = {})
search_term = search_term.to_s
return User.none if search_term.strip.empty?
SearchTermHelper.validate_search_term(search_term)
@is_id = search_term =~ Api::ID_REGEX && Api::MAX_ID_RANGE.cover?(search_term.to_i)
@include_login = context.grants_right?(searcher, session, :view_user_logins)
@include_email = context.grants_right?(searcher, session, :read_email_addresses)
@include_sis = context.grants_any_right?(searcher, session, :read_sis, :manage_sis)
context.shard.activate do
users_scope = context_scope(context, searcher, options.slice(:enrollment_state, :include_inactive_enrollments))
users_scope = users_scope.from("(#{conditions_statement(search_term, context.root_account, users_scope)}) AS users")
users_scope = order_scope(users_scope, context, options.slice(:order, :sort))
roles_scope(users_scope, context, options.slice(:enrollment_type, :enrollment_role,
:enrollment_role_id, :exclude_groups))
end
user searching module refs #CNVS-2326 Added a UserSearch module that provides and interface for searching across the name, the email, and the sis id (and the database id), and added a trigram index on the columns that will be searched against. also made a slight refactor to the AR initializer in order to expose some of the behavior I wanted more granularly and added some specs to cover it fixed a small permissions bug in course.rb and pulled some scoping out of the courses controller down into the user search module TEST PLAN: This is currently not accessible from the site itself, this is just the ground work for the eventual user search api endpoint. The code is not called by anything currently in production either so there is no need for regression testing. The one thing to check would be the creation of new users (and pseudonyms and communication channels). There have been new indexes added to columns on those tables and there is some documentation indicating that writing to these indexes can be time consuming if the data set is quite large. It would be worth making sure that there have not been any unacceptable performance regressions in the creation of any of those record types in a database that has a full load of data (comparable to the production environment) Change-Id: I8fb13a6ec714f27efc8012c5ed2bed4d963c24e6 Reviewed-on: https://gerrit.instructure.com/16459 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Clare Hetherington <clare@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com>
2012-12-29 03:28:09 +08:00
end
def self.conditions_statement(search_term, root_account, users_scope)
user searching module refs #CNVS-2326 Added a UserSearch module that provides and interface for searching across the name, the email, and the sis id (and the database id), and added a trigram index on the columns that will be searched against. also made a slight refactor to the AR initializer in order to expose some of the behavior I wanted more granularly and added some specs to cover it fixed a small permissions bug in course.rb and pulled some scoping out of the courses controller down into the user search module TEST PLAN: This is currently not accessible from the site itself, this is just the ground work for the eventual user search api endpoint. The code is not called by anything currently in production either so there is no need for regression testing. The one thing to check would be the creation of new users (and pseudonyms and communication channels). There have been new indexes added to columns on those tables and there is some documentation indicating that writing to these indexes can be time consuming if the data set is quite large. It would be worth making sure that there have not been any unacceptable performance regressions in the creation of any of those record types in a database that has a full load of data (comparable to the production environment) Change-Id: I8fb13a6ec714f27efc8012c5ed2bed4d963c24e6 Reviewed-on: https://gerrit.instructure.com/16459 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Clare Hetherington <clare@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com>
2012-12-29 03:28:09 +08:00
pattern = like_string_for(search_term)
params = {pattern: pattern, account: root_account, path_type: CommunicationChannel::TYPE_EMAIL, db_id: search_term}
complex_sql(users_scope, params)
user searching module refs #CNVS-2326 Added a UserSearch module that provides and interface for searching across the name, the email, and the sis id (and the database id), and added a trigram index on the columns that will be searched against. also made a slight refactor to the AR initializer in order to expose some of the behavior I wanted more granularly and added some specs to cover it fixed a small permissions bug in course.rb and pulled some scoping out of the courses controller down into the user search module TEST PLAN: This is currently not accessible from the site itself, this is just the ground work for the eventual user search api endpoint. The code is not called by anything currently in production either so there is no need for regression testing. The one thing to check would be the creation of new users (and pseudonyms and communication channels). There have been new indexes added to columns on those tables and there is some documentation indicating that writing to these indexes can be time consuming if the data set is quite large. It would be worth making sure that there have not been any unacceptable performance regressions in the creation of any of those record types in a database that has a full load of data (comparable to the production environment) Change-Id: I8fb13a6ec714f27efc8012c5ed2bed4d963c24e6 Reviewed-on: https://gerrit.instructure.com/16459 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Clare Hetherington <clare@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com>
2012-12-29 03:28:09 +08:00
end
def self.like_string_for(search_term)
pattern_type = (gist_search_enabled? ? :full : :right)
wildcard_pattern(search_term, :type => pattern_type, :case_sensitive => false)
user searching module refs #CNVS-2326 Added a UserSearch module that provides and interface for searching across the name, the email, and the sis id (and the database id), and added a trigram index on the columns that will be searched against. also made a slight refactor to the AR initializer in order to expose some of the behavior I wanted more granularly and added some specs to cover it fixed a small permissions bug in course.rb and pulled some scoping out of the courses controller down into the user search module TEST PLAN: This is currently not accessible from the site itself, this is just the ground work for the eventual user search api endpoint. The code is not called by anything currently in production either so there is no need for regression testing. The one thing to check would be the creation of new users (and pseudonyms and communication channels). There have been new indexes added to columns on those tables and there is some documentation indicating that writing to these indexes can be time consuming if the data set is quite large. It would be worth making sure that there have not been any unacceptable performance regressions in the creation of any of those record types in a database that has a full load of data (comparable to the production environment) Change-Id: I8fb13a6ec714f27efc8012c5ed2bed4d963c24e6 Reviewed-on: https://gerrit.instructure.com/16459 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Clare Hetherington <clare@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com>
2012-12-29 03:28:09 +08:00
end
def self.scope_for(context, searcher, options={})
users_scope = context_scope(context, searcher, options.slice(:enrollment_state, :include_inactive_enrollments))
users_scope = order_scope(users_scope, context, options.slice(:order, :sort))
roles_scope(users_scope, context, options.slice(:enrollment_role, :enrollment_role_id, :enrollment_type, :exclude_groups))
end
def self.context_scope(context, searcher, options={})
enrollment_states = Array(options[:enrollment_state]) if options[:enrollment_state]
include_prior_enrollments = !options[:enrollment_state].nil?
include_inactive_enrollments = !!options[:include_inactive_enrollments]
if context.is_a?(Account)
User.of_account(context).active
elsif context.is_a?(Course)
context.users_visible_to(searcher, include_prior_enrollments,
enrollment_state: enrollment_states, include_inactive: include_inactive_enrollments).distinct
else
context.users_visible_to(searcher, include_inactive: include_inactive_enrollments).distinct
end
end
user searching module refs #CNVS-2326 Added a UserSearch module that provides and interface for searching across the name, the email, and the sis id (and the database id), and added a trigram index on the columns that will be searched against. also made a slight refactor to the AR initializer in order to expose some of the behavior I wanted more granularly and added some specs to cover it fixed a small permissions bug in course.rb and pulled some scoping out of the courses controller down into the user search module TEST PLAN: This is currently not accessible from the site itself, this is just the ground work for the eventual user search api endpoint. The code is not called by anything currently in production either so there is no need for regression testing. The one thing to check would be the creation of new users (and pseudonyms and communication channels). There have been new indexes added to columns on those tables and there is some documentation indicating that writing to these indexes can be time consuming if the data set is quite large. It would be worth making sure that there have not been any unacceptable performance regressions in the creation of any of those record types in a database that has a full load of data (comparable to the production environment) Change-Id: I8fb13a6ec714f27efc8012c5ed2bed4d963c24e6 Reviewed-on: https://gerrit.instructure.com/16459 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Clare Hetherington <clare@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com>
2012-12-29 03:28:09 +08:00
def self.order_scope(users_scope, context, options={})
order = ' DESC NULLS LAST, id DESC' if options[:order] == 'desc'
if options[:sort] == "last_login"
users_scope.select("users.*").order(Arel.sql("last_login#{order}"))
elsif options[:sort] == "username"
users_scope.select("users.*").order_by_sortable_name(direction: options[:order] == 'desc' ? :descending : :ascending)
elsif options[:sort] == "email"
users_scope = users_scope.select("users.*, (SELECT path FROM #{CommunicationChannel.quoted_table_name}
WHERE communication_channels.user_id = users.id AND
communication_channels.path_type = 'email' AND
communication_channels.workflow_state <> 'retired'
ORDER BY communication_channels.position ASC
LIMIT 1)
AS email")
users_scope.order(Arel.sql("email#{order}"))
elsif options[:sort] == "sis_id"
users_scope = users_scope.select(User.send(:sanitize_sql, [
"users.*, (SELECT sis_user_id FROM #{Pseudonym.quoted_table_name}
WHERE pseudonyms.user_id = users.id AND
pseudonyms.workflow_state <> 'deleted' AND
pseudonyms.account_id = ?
LIMIT 1) AS sis_user_id",
context.try(:resolved_root_account_id) || context.root_account_id
]))
users_scope.order(Arel.sql("sis_user_id#{order}"))
else
users_scope.select("users.*").order_by_sortable_name
end
end
def self.roles_scope(users_scope, context, options={})
enrollment_roles = Array(options[:enrollment_role]) if options[:enrollment_role]
enrollment_role_ids = Array(options[:enrollment_role_id]) if options[:enrollment_role_id]
enrollment_types = Array(options[:enrollment_type]) if options[:enrollment_type]
exclude_groups = Array(options[:exclude_groups]) if options[:exclude_groups]
adds sorting to columns in courses and people search adds sorting to the 'Courses' and 'SIS ID' columns of the Courses tab and the 'Name' and 'Last Login' columns of the People tab closes CNVS-33425 test plan: - turn on Account Course and User Search feature flag - go to /accounts/1/search/courses - make sure Courses and SIS ID columns are clickable and sortable - make sure that keyboard interaction and a11y looks good - go to /accounts/1/search/people - do the same for the Name and Last Login columns of the People tab add sorting by Teacher column in courses add sorting by first alphabetical teacher to the 'Teacher' column of the Courses tab test plan: - turn on Account Course and User Search feature flag - go to /accounts/1/search/courses - make sure the Teacher column is clickable and sortable - make sure that keyboard interaction and a11y look good add sorting by Enrollments column in courses add sorting by number of students enrolled to the 'Enrollments' column of the courses tab test plan: - turn on Account Course and User Search feature flag - go to /accounts/1/search/courses - make sure the Enrollment column is clickable and sortable - make sure that keyboard interaction and a11y look good add sorting by Email and SIS ID columns in People add sorting by 'Email' and 'SIS ID' columns of 'People' search tab test plan: - turn on Account Course and User Search feature flag - go to /accounts/1/search/people - make sure the Email column is clickable and sortable - make sure the SIS ID column is clickable and sortable - make sure that keyboard interaction and a11y look good change UserPane to extend React.Component change UserPane.js to be a class that extends React.Component instead of using the old React.createClass test plan: - go to /accounts/1/search/people - make sure the user search feature works the same as before fix queries and lint warnings fix SQL queries based on Tyler's suggestions and fix some lint warnings throughout test plan: - go to /accounts/1/search/courses - make sure sorts still work - make sure queries are as correct and efficient - go to /accounts/1/search/people - do the same - make sure Gergich is relatively happy sort teachers in course and lint fixes change course search so that teachers are sorted alphabetically within a course (if it has multiple teachers). also a few lint fixes here and there. test plan: - go /accounts/1/search/courses - make sure that teachers are sorted within a course Change-Id: I710878bd8ce98ba2fa4eb0c357721864df338939 add a sortable column for subaccounts to course search add a new column to course search for subaccount make it sortable like the other columns test plan: - turn on Account Course and User Search feature flag - go to /accounts/1/search/courses - make sure the correct subaccounts are showing - make sure the subaccount column is clickable and sortable - make sure that keyboard interaction and a11y look good Change-Id: Ic8b8f258c27c16982a450286f6b715c9e04d425e fix focus for keyboard navigation in Course Search sorting prevent the CoursesList from rerendering sometimes on sorts so that it doesn't lose focus test plan: - turn on Account Course and User Search feature flag - go to /accounts/1/search/courses - make sure keyboard interaction doesn't lose focus Change-Id: I6236c92f6e71596d3dc38ef756e6ac808e9e99c2 fix invalid email sorting in User Search fix the sorting of invalid emails in User Search so that invalid emails (that don't show up) come last test plan: - turn on Account Course and User Search feature flag - go to /accounts/1/search/courses - make sure that invalid blank emails are sorted last Change-Id: I56e6b1e57a1d494e7667c3cfc7b14a10976ec52e fix invalid emails showing in User Search fix User Search so that invalid emails don't display when the "Load More..." button is pressed test plan: - turn on Account Course and User Search feature flag - go to /accounts/1/search/courses - have more than 10 users so "Load More..." is there - click "Load More..." and make sure invalid emails don't display for the newly-loaded users Change-Id: I5bc23c616ae88da73f8632699c3bde1bffee994d fix IE11 User Search sorting issue fix User sorting in IE11 so that it doesn't go back to the Courses tab when trying to sort test plan: - use IE11 - turn on Account Course and User Search feature flag - go to /accounts/1/search/people - make sure sorting works (doesn't take you to Courses tab) Change-Id: I63491ca0b08812e21ed0ed2eb2f8a4bd1b791b89 fix add user in User Search bug where email doesn't show up fix User Search so that when a user is added, their email shows up without refreshing the page test plan: - turn on Account Course and User Search feature flag - go to /accounts/1/search/people - add a new user with a valid email - make sure it displays before refreshing Change-Id: Ib339bab3ea858c7c1ab18a6065ef4936941cb24b remove debugger Change-Id: Ibf88893ea35d795d8966c7580100ac135c8cfe93 Reviewed-on: https://gerrit.instructure.com/120294 Tested-by: Jenkins Reviewed-by: Ryan Shaw <ryan@instructure.com> QA-Review: Jeremy Putnam <jeremyp@instructure.com> Product-Review: Andrew Katsanevas <akatsanevas@instructure.com>
2017-06-15 06:40:09 +08:00
if enrollment_role_ids || enrollment_roles
users_scope = users_scope.joins(:not_removed_enrollments).distinct if context.is_a?(Account)
roles = if enrollment_role_ids
enrollment_role_ids.map{|id| Role.get_role_by_id(id)}.compact
else
enrollment_roles.map do |name|
if context.is_a?(Account)
context.get_course_role_by_name(name)
else
context.account.get_course_role_by_name(name)
end
end.compact
end
users_scope = users_scope.where("role_id IN (?)", roles.map(&:id))
elsif enrollment_types
enrollment_types = enrollment_types.map { |e| "#{e.camelize}Enrollment" }
if enrollment_types.any?{ |et| !Enrollment.readable_types.keys.include?(et) }
raise ArgumentError, 'Invalid Enrollment Type'
end
if context.is_a?(Account)
# for example, one user can have multiple teacher enrollments, but
# we only want one such a user record in results
users_scope = users_scope.where("EXISTS (?)", Enrollment.where("enrollments.user_id=users.id").active.where(type: enrollment_types)).distinct
else
if context.is_a?(Group) && context.context_type == "Course"
users_scope = users_scope.joins(:enrollments).where(:enrollments => {:course_id => context.context_id})
end
users_scope = users_scope.where(:enrollments => { :type => enrollment_types })
end
user searching module refs #CNVS-2326 Added a UserSearch module that provides and interface for searching across the name, the email, and the sis id (and the database id), and added a trigram index on the columns that will be searched against. also made a slight refactor to the AR initializer in order to expose some of the behavior I wanted more granularly and added some specs to cover it fixed a small permissions bug in course.rb and pulled some scoping out of the courses controller down into the user search module TEST PLAN: This is currently not accessible from the site itself, this is just the ground work for the eventual user search api endpoint. The code is not called by anything currently in production either so there is no need for regression testing. The one thing to check would be the creation of new users (and pseudonyms and communication channels). There have been new indexes added to columns on those tables and there is some documentation indicating that writing to these indexes can be time consuming if the data set is quite large. It would be worth making sure that there have not been any unacceptable performance regressions in the creation of any of those record types in a database that has a full load of data (comparable to the production environment) Change-Id: I8fb13a6ec714f27efc8012c5ed2bed4d963c24e6 Reviewed-on: https://gerrit.instructure.com/16459 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Clare Hetherington <clare@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com>
2012-12-29 03:28:09 +08:00
end
if exclude_groups
users_scope = users_scope.where(Group.not_in_group_sql_fragment(exclude_groups))
end
users_scope
user searching module refs #CNVS-2326 Added a UserSearch module that provides and interface for searching across the name, the email, and the sis id (and the database id), and added a trigram index on the columns that will be searched against. also made a slight refactor to the AR initializer in order to expose some of the behavior I wanted more granularly and added some specs to cover it fixed a small permissions bug in course.rb and pulled some scoping out of the courses controller down into the user search module TEST PLAN: This is currently not accessible from the site itself, this is just the ground work for the eventual user search api endpoint. The code is not called by anything currently in production either so there is no need for regression testing. The one thing to check would be the creation of new users (and pseudonyms and communication channels). There have been new indexes added to columns on those tables and there is some documentation indicating that writing to these indexes can be time consuming if the data set is quite large. It would be worth making sure that there have not been any unacceptable performance regressions in the creation of any of those record types in a database that has a full load of data (comparable to the production environment) Change-Id: I8fb13a6ec714f27efc8012c5ed2bed4d963c24e6 Reviewed-on: https://gerrit.instructure.com/16459 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Clare Hetherington <clare@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com>
2012-12-29 03:28:09 +08:00
end
private
def self.complex_sql(users_scope, params)
users_scope = users_scope.group(:id)
queries = [name_sql(users_scope, params)]
if complex_search_enabled?
queries << id_sql(users_scope, params) if @is_id
queries << login_sql(users_scope, params) if @include_login
queries << sis_sql(users_scope, params) if @include_sis
queries << email_sql(users_scope, params) if @include_email
end
queries.map(&:to_sql).join("\nUNION\n")
end
def self.id_sql(users_scope, params)
users_scope.select("users.*, MAX(current_login_at) as last_login").
joins("LEFT JOIN #{Pseudonym.quoted_table_name} ON pseudonyms.user_id = users.id
AND pseudonyms.account_id = #{User.connection.quote(params[:account])}
AND pseudonyms.workflow_state = 'active'").
where(id: params[:db_id]).
group(:id)
end
def self.name_sql(users_scope, params)
users_scope.select("users.*, MAX(current_login_at) as last_login").
joins("LEFT JOIN #{Pseudonym.quoted_table_name} ON pseudonyms.user_id = users.id
AND pseudonyms.account_id = #{User.connection.quote(params[:account])}
AND pseudonyms.workflow_state = 'active'").
where(like_condition('users.name'), pattern: params[:pattern])
end
def self.login_sql(users_scope, params)
users_scope.select("users.*, MAX(logins.current_login_at) as last_login").
joins(:pseudonyms).
joins("LEFT JOIN #{Pseudonym.quoted_table_name} AS logins ON logins.user_id = users.id
AND logins.account_id = #{User.connection.quote(params[:account])}
AND logins.workflow_state = 'active'").
where(pseudonyms: {account_id: params[:account], workflow_state: 'active'}).
where(like_condition('pseudonyms.unique_id'), pattern: params[:pattern])
end
def self.sis_sql(users_scope, params)
users_scope.select("users.*, MAX(logins.current_login_at) as last_login").
joins(:pseudonyms).
joins("LEFT JOIN #{Pseudonym.quoted_table_name} AS logins ON logins.user_id = users.id
AND logins.account_id = #{User.connection.quote(params[:account])}
AND logins.workflow_state = 'active'").
where(pseudonyms: {account_id: params[:account], workflow_state: 'active'}).
where(like_condition('pseudonyms.sis_user_id'), pattern: params[:pattern])
end
def self.email_sql(users_scope, params)
users_scope.select("users.*, MAX(current_login_at) as last_login").
joins(:communication_channels).
joins("LEFT JOIN #{Pseudonym.quoted_table_name} ON pseudonyms.user_id = users.id
AND pseudonyms.account_id = #{User.connection.quote(params[:account])}
AND pseudonyms.workflow_state = 'active'").
where(communication_channels: {workflow_state: ['active', 'unconfirmed'], path_type: params[:path_type]}).
where(like_condition('communication_channels.path'), pattern: params[:pattern])
user searching module refs #CNVS-2326 Added a UserSearch module that provides and interface for searching across the name, the email, and the sis id (and the database id), and added a trigram index on the columns that will be searched against. also made a slight refactor to the AR initializer in order to expose some of the behavior I wanted more granularly and added some specs to cover it fixed a small permissions bug in course.rb and pulled some scoping out of the courses controller down into the user search module TEST PLAN: This is currently not accessible from the site itself, this is just the ground work for the eventual user search api endpoint. The code is not called by anything currently in production either so there is no need for regression testing. The one thing to check would be the creation of new users (and pseudonyms and communication channels). There have been new indexes added to columns on those tables and there is some documentation indicating that writing to these indexes can be time consuming if the data set is quite large. It would be worth making sure that there have not been any unacceptable performance regressions in the creation of any of those record types in a database that has a full load of data (comparable to the production environment) Change-Id: I8fb13a6ec714f27efc8012c5ed2bed4d963c24e6 Reviewed-on: https://gerrit.instructure.com/16459 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Clare Hetherington <clare@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com>
2012-12-29 03:28:09 +08:00
end
def self.gist_search_enabled?
Setting.get('user_search_with_gist', 'true') == 'true'
user searching module refs #CNVS-2326 Added a UserSearch module that provides and interface for searching across the name, the email, and the sis id (and the database id), and added a trigram index on the columns that will be searched against. also made a slight refactor to the AR initializer in order to expose some of the behavior I wanted more granularly and added some specs to cover it fixed a small permissions bug in course.rb and pulled some scoping out of the courses controller down into the user search module TEST PLAN: This is currently not accessible from the site itself, this is just the ground work for the eventual user search api endpoint. The code is not called by anything currently in production either so there is no need for regression testing. The one thing to check would be the creation of new users (and pseudonyms and communication channels). There have been new indexes added to columns on those tables and there is some documentation indicating that writing to these indexes can be time consuming if the data set is quite large. It would be worth making sure that there have not been any unacceptable performance regressions in the creation of any of those record types in a database that has a full load of data (comparable to the production environment) Change-Id: I8fb13a6ec714f27efc8012c5ed2bed4d963c24e6 Reviewed-on: https://gerrit.instructure.com/16459 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Clare Hetherington <clare@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com>
2012-12-29 03:28:09 +08:00
end
def self.complex_search_enabled?
Setting.get('user_search_with_full_complexity', 'true') == 'true'
user searching module refs #CNVS-2326 Added a UserSearch module that provides and interface for searching across the name, the email, and the sis id (and the database id), and added a trigram index on the columns that will be searched against. also made a slight refactor to the AR initializer in order to expose some of the behavior I wanted more granularly and added some specs to cover it fixed a small permissions bug in course.rb and pulled some scoping out of the courses controller down into the user search module TEST PLAN: This is currently not accessible from the site itself, this is just the ground work for the eventual user search api endpoint. The code is not called by anything currently in production either so there is no need for regression testing. The one thing to check would be the creation of new users (and pseudonyms and communication channels). There have been new indexes added to columns on those tables and there is some documentation indicating that writing to these indexes can be time consuming if the data set is quite large. It would be worth making sure that there have not been any unacceptable performance regressions in the creation of any of those record types in a database that has a full load of data (comparable to the production environment) Change-Id: I8fb13a6ec714f27efc8012c5ed2bed4d963c24e6 Reviewed-on: https://gerrit.instructure.com/16459 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Clare Hetherington <clare@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com>
2012-12-29 03:28:09 +08:00
end
def self.like_condition(value)
ActiveRecord::Base.like_condition(value, 'lower(:pattern)')
user searching module refs #CNVS-2326 Added a UserSearch module that provides and interface for searching across the name, the email, and the sis id (and the database id), and added a trigram index on the columns that will be searched against. also made a slight refactor to the AR initializer in order to expose some of the behavior I wanted more granularly and added some specs to cover it fixed a small permissions bug in course.rb and pulled some scoping out of the courses controller down into the user search module TEST PLAN: This is currently not accessible from the site itself, this is just the ground work for the eventual user search api endpoint. The code is not called by anything currently in production either so there is no need for regression testing. The one thing to check would be the creation of new users (and pseudonyms and communication channels). There have been new indexes added to columns on those tables and there is some documentation indicating that writing to these indexes can be time consuming if the data set is quite large. It would be worth making sure that there have not been any unacceptable performance regressions in the creation of any of those record types in a database that has a full load of data (comparable to the production environment) Change-Id: I8fb13a6ec714f27efc8012c5ed2bed4d963c24e6 Reviewed-on: https://gerrit.instructure.com/16459 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Clare Hetherington <clare@instructure.com> Reviewed-by: Brian Palmer <brianp@instructure.com>
2012-12-29 03:28:09 +08:00
end
def self.wildcard_pattern(value, options)
ActiveRecord::Base.wildcard_pattern(value, options)
end
end