MessageableUser refactor with sharding
Separates, streamlines, and makes shard-aware all use cases of
User#messageable_users *other* than searching (call site in
SearchController#matching_participants).
Produces three new methods that take the bulk of that responsibility:
* User#load_messageable_users -- given a set of users, filter out the
ones that aren't messageable, and load any common contexts for those
that are.
* User#load_messageable_user -- as User#load_messageable_users, but for
just one user.
* User#messageable_users_in_context -- given a context (a course,
section, or group), return the list of messageable users in that
context.
refs CNVS-2519
remaining on CNVS-2519 is to tackle the search application of
User#messageable_user. mostly there, but reconciling pagination
with ranking by number of shared contexts is proving problematic, so I'm
going to separate that into another commit.
meanwhile, I've renamed User#messageable_users to
User#deprecated_search_messageable_users to discourage any accidental
new uses and left it otherwise untouched. searching for users on the
same shard should be unaffected. You can still locate messageable users
on other shards to insert into conversations by browsing the shared
contexts.
test-plan:
* create user A in shard X
* create user B in shard Y
* for situations where A could message B if on the same shard:
- setup the situation where the common tie is on shard X (e.g. course
on shard X and both A and B in it). run exercises below
- setup the situation where the common tie is on shard Y. run
exercises.
- if appropriate, setup the situation where the common tie is on
shard Z. run exercises.
* for each setup described above, login as A:
- A should see the "message this user" button on B's profile
- if the common tie is a course, section, or group, A should see B
under that context when the context is selected in the recipient
browser
- if a conversation exists involving both A and B, when A loads the
conversation they should see B tagged with the common contexts
* regression test searching for messageable users from the same shard
Change-Id: Ibba5551f8afc2435fd14a2e827a400bf95eae76a
Reviewed-on: https://gerrit.instructure.com/17569
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
2013-02-05 06:18:20 +08:00
|
|
|
#
|
|
|
|
# Copyright (C) 2013 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 MessageableUser < User
|
|
|
|
COLUMNS = ['id', 'short_name', 'name', 'avatar_image_url', 'avatar_image_source'].map{ |col| "users.#{col}" }
|
|
|
|
SELECT = COLUMNS.join(", ")
|
|
|
|
AVAILABLE_CONDITIONS = "users.workflow_state IN ('registered', 'pre_registered')"
|
|
|
|
|
|
|
|
def self.build_select(options={})
|
2013-03-04 15:56:39 +08:00
|
|
|
options = {
|
|
|
|
:common_course_column => nil,
|
|
|
|
:common_group_column => nil,
|
|
|
|
:common_role_column => nil
|
|
|
|
}.merge(options)
|
|
|
|
|
|
|
|
common_course_sql =
|
|
|
|
if options[:common_role_column]
|
|
|
|
raise ArgumentError unless options[:common_course_column]
|
|
|
|
connection.func(:group_concat, connection.adapter_name =~ /postgres/i ?
|
|
|
|
:"#{options[:common_course_column]}::text || ':' || #{options[:common_role_column]}::text" :
|
|
|
|
:"#{options[:common_course_column]} || ':' || #{options[:common_role_column]}")
|
|
|
|
else
|
|
|
|
'NULL'
|
|
|
|
end
|
|
|
|
|
|
|
|
common_group_sql =
|
|
|
|
if options[:common_group_column].is_a?(String)
|
|
|
|
connection.func(:group_concat, options[:common_group_column].to_sym)
|
|
|
|
elsif options[:common_group_column]
|
|
|
|
options[:common_group_column].to_s
|
|
|
|
else
|
|
|
|
'NULL'
|
|
|
|
end
|
|
|
|
|
|
|
|
"#{SELECT}, #{common_course_sql} AS common_courses, #{common_group_sql} AS common_groups"
|
MessageableUser refactor with sharding
Separates, streamlines, and makes shard-aware all use cases of
User#messageable_users *other* than searching (call site in
SearchController#matching_participants).
Produces three new methods that take the bulk of that responsibility:
* User#load_messageable_users -- given a set of users, filter out the
ones that aren't messageable, and load any common contexts for those
that are.
* User#load_messageable_user -- as User#load_messageable_users, but for
just one user.
* User#messageable_users_in_context -- given a context (a course,
section, or group), return the list of messageable users in that
context.
refs CNVS-2519
remaining on CNVS-2519 is to tackle the search application of
User#messageable_user. mostly there, but reconciling pagination
with ranking by number of shared contexts is proving problematic, so I'm
going to separate that into another commit.
meanwhile, I've renamed User#messageable_users to
User#deprecated_search_messageable_users to discourage any accidental
new uses and left it otherwise untouched. searching for users on the
same shard should be unaffected. You can still locate messageable users
on other shards to insert into conversations by browsing the shared
contexts.
test-plan:
* create user A in shard X
* create user B in shard Y
* for situations where A could message B if on the same shard:
- setup the situation where the common tie is on shard X (e.g. course
on shard X and both A and B in it). run exercises below
- setup the situation where the common tie is on shard Y. run
exercises.
- if appropriate, setup the situation where the common tie is on
shard Z. run exercises.
* for each setup described above, login as A:
- A should see the "message this user" button on B's profile
- if the common tie is a course, section, or group, A should see B
under that context when the context is selected in the recipient
browser
- if a conversation exists involving both A and B, when A loads the
conversation they should see B tagged with the common contexts
* regression test searching for messageable users from the same shard
Change-Id: Ibba5551f8afc2435fd14a2e827a400bf95eae76a
Reviewed-on: https://gerrit.instructure.com/17569
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
2013-02-05 06:18:20 +08:00
|
|
|
end
|
|
|
|
|
2013-03-04 15:56:39 +08:00
|
|
|
def self.prepped(options={})
|
2013-02-27 01:30:06 +08:00
|
|
|
options = {
|
|
|
|
:strict_checks => true,
|
|
|
|
:include_deleted => false
|
|
|
|
}.merge(options)
|
2013-03-04 15:56:39 +08:00
|
|
|
|
|
|
|
# if either of our common course/group id columns are column names (vs.
|
|
|
|
# integers), they need to go in the group by. we turn the first element
|
|
|
|
# into an array and add them to that, so that both postgresql/mysql are
|
|
|
|
# happy (see the documentation on group_concat if you're curious about
|
|
|
|
# the gory details)
|
|
|
|
columns = COLUMNS.dup
|
|
|
|
if options[:common_course_column].is_a?(String) || options[:common_group_column].is_a?(String)
|
|
|
|
head = [columns.shift]
|
|
|
|
head << options[:common_course_column] if options[:common_course_column].is_a?(String)
|
|
|
|
head << options[:common_group_column] if options[:common_group_column].is_a?(String)
|
|
|
|
columns.unshift(head)
|
|
|
|
end
|
|
|
|
|
|
|
|
scope = self.scoped(
|
|
|
|
:select => MessageableUser.build_select(options),
|
|
|
|
:group => MessageableUser.connection.group_by(*columns),
|
|
|
|
:order => 'LOWER(COALESCE(users.short_name, users.name)), users.id')
|
|
|
|
|
|
|
|
if options[:strict_checks]
|
|
|
|
scope.where(AVAILABLE_CONDITIONS)
|
2013-02-27 01:30:06 +08:00
|
|
|
elsif !options[:include_deleted]
|
|
|
|
scope.where("users.workflow_state <> 'deleted'")
|
MessageableUser refactor with sharding
Separates, streamlines, and makes shard-aware all use cases of
User#messageable_users *other* than searching (call site in
SearchController#matching_participants).
Produces three new methods that take the bulk of that responsibility:
* User#load_messageable_users -- given a set of users, filter out the
ones that aren't messageable, and load any common contexts for those
that are.
* User#load_messageable_user -- as User#load_messageable_users, but for
just one user.
* User#messageable_users_in_context -- given a context (a course,
section, or group), return the list of messageable users in that
context.
refs CNVS-2519
remaining on CNVS-2519 is to tackle the search application of
User#messageable_user. mostly there, but reconciling pagination
with ranking by number of shared contexts is proving problematic, so I'm
going to separate that into another commit.
meanwhile, I've renamed User#messageable_users to
User#deprecated_search_messageable_users to discourage any accidental
new uses and left it otherwise untouched. searching for users on the
same shard should be unaffected. You can still locate messageable users
on other shards to insert into conversations by browsing the shared
contexts.
test-plan:
* create user A in shard X
* create user B in shard Y
* for situations where A could message B if on the same shard:
- setup the situation where the common tie is on shard X (e.g. course
on shard X and both A and B in it). run exercises below
- setup the situation where the common tie is on shard Y. run
exercises.
- if appropriate, setup the situation where the common tie is on
shard Z. run exercises.
* for each setup described above, login as A:
- A should see the "message this user" button on B's profile
- if the common tie is a course, section, or group, A should see B
under that context when the context is selected in the recipient
browser
- if a conversation exists involving both A and B, when A loads the
conversation they should see B tagged with the common contexts
* regression test searching for messageable users from the same shard
Change-Id: Ibba5551f8afc2435fd14a2e827a400bf95eae76a
Reviewed-on: https://gerrit.instructure.com/17569
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
2013-02-05 06:18:20 +08:00
|
|
|
else
|
2013-03-04 15:56:39 +08:00
|
|
|
scope
|
MessageableUser refactor with sharding
Separates, streamlines, and makes shard-aware all use cases of
User#messageable_users *other* than searching (call site in
SearchController#matching_participants).
Produces three new methods that take the bulk of that responsibility:
* User#load_messageable_users -- given a set of users, filter out the
ones that aren't messageable, and load any common contexts for those
that are.
* User#load_messageable_user -- as User#load_messageable_users, but for
just one user.
* User#messageable_users_in_context -- given a context (a course,
section, or group), return the list of messageable users in that
context.
refs CNVS-2519
remaining on CNVS-2519 is to tackle the search application of
User#messageable_user. mostly there, but reconciling pagination
with ranking by number of shared contexts is proving problematic, so I'm
going to separate that into another commit.
meanwhile, I've renamed User#messageable_users to
User#deprecated_search_messageable_users to discourage any accidental
new uses and left it otherwise untouched. searching for users on the
same shard should be unaffected. You can still locate messageable users
on other shards to insert into conversations by browsing the shared
contexts.
test-plan:
* create user A in shard X
* create user B in shard Y
* for situations where A could message B if on the same shard:
- setup the situation where the common tie is on shard X (e.g. course
on shard X and both A and B in it). run exercises below
- setup the situation where the common tie is on shard Y. run
exercises.
- if appropriate, setup the situation where the common tie is on
shard Z. run exercises.
* for each setup described above, login as A:
- A should see the "message this user" button on B's profile
- if the common tie is a course, section, or group, A should see B
under that context when the context is selected in the recipient
browser
- if a conversation exists involving both A and B, when A loads the
conversation they should see B tagged with the common contexts
* regression test searching for messageable users from the same shard
Change-Id: Ibba5551f8afc2435fd14a2e827a400bf95eae76a
Reviewed-on: https://gerrit.instructure.com/17569
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
2013-02-05 06:18:20 +08:00
|
|
|
end
|
2013-03-04 15:56:39 +08:00
|
|
|
end
|
MessageableUser refactor with sharding
Separates, streamlines, and makes shard-aware all use cases of
User#messageable_users *other* than searching (call site in
SearchController#matching_participants).
Produces three new methods that take the bulk of that responsibility:
* User#load_messageable_users -- given a set of users, filter out the
ones that aren't messageable, and load any common contexts for those
that are.
* User#load_messageable_user -- as User#load_messageable_users, but for
just one user.
* User#messageable_users_in_context -- given a context (a course,
section, or group), return the list of messageable users in that
context.
refs CNVS-2519
remaining on CNVS-2519 is to tackle the search application of
User#messageable_user. mostly there, but reconciling pagination
with ranking by number of shared contexts is proving problematic, so I'm
going to separate that into another commit.
meanwhile, I've renamed User#messageable_users to
User#deprecated_search_messageable_users to discourage any accidental
new uses and left it otherwise untouched. searching for users on the
same shard should be unaffected. You can still locate messageable users
on other shards to insert into conversations by browsing the shared
contexts.
test-plan:
* create user A in shard X
* create user B in shard Y
* for situations where A could message B if on the same shard:
- setup the situation where the common tie is on shard X (e.g. course
on shard X and both A and B in it). run exercises below
- setup the situation where the common tie is on shard Y. run
exercises.
- if appropriate, setup the situation where the common tie is on
shard Z. run exercises.
* for each setup described above, login as A:
- A should see the "message this user" button on B's profile
- if the common tie is a course, section, or group, A should see B
under that context when the context is selected in the recipient
browser
- if a conversation exists involving both A and B, when A loads the
conversation they should see B tagged with the common contexts
* regression test searching for messageable users from the same shard
Change-Id: Ibba5551f8afc2435fd14a2e827a400bf95eae76a
Reviewed-on: https://gerrit.instructure.com/17569
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
2013-02-05 06:18:20 +08:00
|
|
|
|
|
|
|
def self.unfiltered(options={})
|
|
|
|
prepped(options.merge(:strict_checks => false))
|
|
|
|
end
|
|
|
|
|
|
|
|
def self.available(options={})
|
|
|
|
prepped(options.merge(:strict_checks => true))
|
|
|
|
end
|
|
|
|
|
|
|
|
def self.context_recipients(recipients)
|
|
|
|
recipients.grep(Calculator::CONTEXT_RECIPIENT)
|
|
|
|
end
|
|
|
|
|
|
|
|
def self.individual_recipients(recipients)
|
|
|
|
recipients.grep(Calculator::INDIVIDUAL_RECIPIENT).map(&:to_i)
|
|
|
|
end
|
|
|
|
|
|
|
|
def common_groups
|
|
|
|
common_contexts_on_current_shard(global_common_groups)
|
|
|
|
end
|
|
|
|
|
|
|
|
def common_courses
|
|
|
|
common_contexts_on_current_shard(global_common_courses)
|
|
|
|
end
|
|
|
|
|
|
|
|
# only MessageableUser::Calculator should access these directly. if you're
|
|
|
|
# outside the calculator, you almost certainly want the versions above that
|
|
|
|
# transpose to the current shard. additionally, any time you access these,
|
|
|
|
# make sure you're still on the same shard where common_course_id and/or
|
|
|
|
# common_group_id were queried
|
2013-03-04 15:56:39 +08:00
|
|
|
attr_accessor :global_common_courses, :global_common_groups
|
|
|
|
|
|
|
|
# this will be executed on the shard where the find was called (I think?).
|
|
|
|
# as such, we can correctly interpret local ids in the common_courses and
|
|
|
|
# common_groups
|
|
|
|
def after_find
|
|
|
|
@global_common_courses = {}
|
|
|
|
if common_courses = read_attribute(:common_courses)
|
|
|
|
common_courses.to_s.split(',').each do |common_course|
|
|
|
|
course_id, role = common_course.split(':')
|
|
|
|
course_id = Shard.global_id_for(course_id.to_i)
|
|
|
|
@global_common_courses[course_id] ||= []
|
|
|
|
@global_common_courses[course_id] << role
|
MessageableUser refactor with sharding
Separates, streamlines, and makes shard-aware all use cases of
User#messageable_users *other* than searching (call site in
SearchController#matching_participants).
Produces three new methods that take the bulk of that responsibility:
* User#load_messageable_users -- given a set of users, filter out the
ones that aren't messageable, and load any common contexts for those
that are.
* User#load_messageable_user -- as User#load_messageable_users, but for
just one user.
* User#messageable_users_in_context -- given a context (a course,
section, or group), return the list of messageable users in that
context.
refs CNVS-2519
remaining on CNVS-2519 is to tackle the search application of
User#messageable_user. mostly there, but reconciling pagination
with ranking by number of shared contexts is proving problematic, so I'm
going to separate that into another commit.
meanwhile, I've renamed User#messageable_users to
User#deprecated_search_messageable_users to discourage any accidental
new uses and left it otherwise untouched. searching for users on the
same shard should be unaffected. You can still locate messageable users
on other shards to insert into conversations by browsing the shared
contexts.
test-plan:
* create user A in shard X
* create user B in shard Y
* for situations where A could message B if on the same shard:
- setup the situation where the common tie is on shard X (e.g. course
on shard X and both A and B in it). run exercises below
- setup the situation where the common tie is on shard Y. run
exercises.
- if appropriate, setup the situation where the common tie is on
shard Z. run exercises.
* for each setup described above, login as A:
- A should see the "message this user" button on B's profile
- if the common tie is a course, section, or group, A should see B
under that context when the context is selected in the recipient
browser
- if a conversation exists involving both A and B, when A loads the
conversation they should see B tagged with the common contexts
* regression test searching for messageable users from the same shard
Change-Id: Ibba5551f8afc2435fd14a2e827a400bf95eae76a
Reviewed-on: https://gerrit.instructure.com/17569
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
2013-02-05 06:18:20 +08:00
|
|
|
end
|
|
|
|
end
|
|
|
|
|
2013-03-04 15:56:39 +08:00
|
|
|
@global_common_groups = {}
|
|
|
|
if common_groups = read_attribute(:common_groups)
|
|
|
|
common_groups.to_s.split(',').each do |group_id|
|
|
|
|
group_id = Shard.global_id_for(group_id.to_i)
|
|
|
|
@global_common_groups[group_id] ||= []
|
|
|
|
@global_common_groups[group_id] << 'Member'
|
MessageableUser refactor with sharding
Separates, streamlines, and makes shard-aware all use cases of
User#messageable_users *other* than searching (call site in
SearchController#matching_participants).
Produces three new methods that take the bulk of that responsibility:
* User#load_messageable_users -- given a set of users, filter out the
ones that aren't messageable, and load any common contexts for those
that are.
* User#load_messageable_user -- as User#load_messageable_users, but for
just one user.
* User#messageable_users_in_context -- given a context (a course,
section, or group), return the list of messageable users in that
context.
refs CNVS-2519
remaining on CNVS-2519 is to tackle the search application of
User#messageable_user. mostly there, but reconciling pagination
with ranking by number of shared contexts is proving problematic, so I'm
going to separate that into another commit.
meanwhile, I've renamed User#messageable_users to
User#deprecated_search_messageable_users to discourage any accidental
new uses and left it otherwise untouched. searching for users on the
same shard should be unaffected. You can still locate messageable users
on other shards to insert into conversations by browsing the shared
contexts.
test-plan:
* create user A in shard X
* create user B in shard Y
* for situations where A could message B if on the same shard:
- setup the situation where the common tie is on shard X (e.g. course
on shard X and both A and B in it). run exercises below
- setup the situation where the common tie is on shard Y. run
exercises.
- if appropriate, setup the situation where the common tie is on
shard Z. run exercises.
* for each setup described above, login as A:
- A should see the "message this user" button on B's profile
- if the common tie is a course, section, or group, A should see B
under that context when the context is selected in the recipient
browser
- if a conversation exists involving both A and B, when A loads the
conversation they should see B tagged with the common contexts
* regression test searching for messageable users from the same shard
Change-Id: Ibba5551f8afc2435fd14a2e827a400bf95eae76a
Reviewed-on: https://gerrit.instructure.com/17569
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
2013-02-05 06:18:20 +08:00
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
|
|
|
|
|
|
|
private
|
|
|
|
|
|
|
|
def common_contexts_on_current_shard(common_contexts)
|
|
|
|
local_common_contexts = {}
|
|
|
|
target_shard = Shard.current
|
|
|
|
return local_common_contexts if common_contexts.empty?
|
|
|
|
Shard.partition_by_shard(common_contexts.keys) do |sharded_ids|
|
|
|
|
sharded_ids.each do |id|
|
|
|
|
global_id = Shard.global_id_for(id)
|
|
|
|
id = global_id unless Shard.current == target_shard
|
|
|
|
local_common_contexts[id] = common_contexts[global_id]
|
|
|
|
end
|
|
|
|
end
|
|
|
|
local_common_contexts
|
|
|
|
end
|
2013-02-27 01:30:06 +08:00
|
|
|
|
|
|
|
# both bookmark_for and restrict_scope should always be executed on the
|
|
|
|
# same shard (not guaranteed, but we don't have to guarantee correctness if
|
|
|
|
# they aren't). so local ids here and local ids there have identical
|
|
|
|
# interpretation: local to Shard.current.
|
|
|
|
class MessageableUser::Bookmarker
|
|
|
|
def self.bookmark_for(user)
|
|
|
|
[(user.short_name || user.name).downcase, user.id]
|
|
|
|
end
|
|
|
|
|
|
|
|
def self.validate(bookmark)
|
|
|
|
bookmark.is_a?(Array) &&
|
|
|
|
bookmark.size == 2 &&
|
|
|
|
bookmark[0].is_a?(String) &&
|
|
|
|
bookmark[1].is_a?(Fixnum)
|
|
|
|
end
|
|
|
|
|
|
|
|
# ordering is already guaranteed
|
|
|
|
def self.restrict_scope(scope, pager)
|
|
|
|
if pager.current_bookmark
|
|
|
|
name, id = pager.current_bookmark
|
|
|
|
scope_shard = scope.scope(:find, :shard)
|
|
|
|
id = Shard.relative_id_for(id, scope_shard) if scope_shard
|
|
|
|
|
|
|
|
condition = [
|
|
|
|
<<-SQL,
|
|
|
|
LOWER(COALESCE(users.short_name, users.name)) > ? OR
|
|
|
|
LOWER(COALESCE(users.short_name, users.name)) = ? AND users.id > ?
|
|
|
|
SQL
|
|
|
|
name, name, id
|
|
|
|
]
|
|
|
|
|
|
|
|
if pager.include_bookmark
|
|
|
|
condition[0] << "OR LOWER(COALESCE(users.short_name, users.name)) = ? AND users.id = ?"
|
|
|
|
condition.concat([name, id])
|
|
|
|
end
|
|
|
|
|
|
|
|
scope.where(condition)
|
|
|
|
else
|
|
|
|
scope
|
|
|
|
end
|
|
|
|
end
|
|
|
|
end
|
MessageableUser refactor with sharding
Separates, streamlines, and makes shard-aware all use cases of
User#messageable_users *other* than searching (call site in
SearchController#matching_participants).
Produces three new methods that take the bulk of that responsibility:
* User#load_messageable_users -- given a set of users, filter out the
ones that aren't messageable, and load any common contexts for those
that are.
* User#load_messageable_user -- as User#load_messageable_users, but for
just one user.
* User#messageable_users_in_context -- given a context (a course,
section, or group), return the list of messageable users in that
context.
refs CNVS-2519
remaining on CNVS-2519 is to tackle the search application of
User#messageable_user. mostly there, but reconciling pagination
with ranking by number of shared contexts is proving problematic, so I'm
going to separate that into another commit.
meanwhile, I've renamed User#messageable_users to
User#deprecated_search_messageable_users to discourage any accidental
new uses and left it otherwise untouched. searching for users on the
same shard should be unaffected. You can still locate messageable users
on other shards to insert into conversations by browsing the shared
contexts.
test-plan:
* create user A in shard X
* create user B in shard Y
* for situations where A could message B if on the same shard:
- setup the situation where the common tie is on shard X (e.g. course
on shard X and both A and B in it). run exercises below
- setup the situation where the common tie is on shard Y. run
exercises.
- if appropriate, setup the situation where the common tie is on
shard Z. run exercises.
* for each setup described above, login as A:
- A should see the "message this user" button on B's profile
- if the common tie is a course, section, or group, A should see B
under that context when the context is selected in the recipient
browser
- if a conversation exists involving both A and B, when A loads the
conversation they should see B tagged with the common contexts
* regression test searching for messageable users from the same shard
Change-Id: Ibba5551f8afc2435fd14a2e827a400bf95eae76a
Reviewed-on: https://gerrit.instructure.com/17569
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
2013-02-05 06:18:20 +08:00
|
|
|
end
|