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
|
|
|
|
|
2013-03-19 23:49:31 +08:00
|
|
|
scope = self.
|
|
|
|
select(MessageableUser.build_select(options)).
|
|
|
|
group(MessageableUser.connection.group_by(*columns)).
|
|
|
|
order("LOWER(COALESCE(users.short_name, users.name)), users.id")
|
2013-03-04 15:56:39 +08:00
|
|
|
|
|
|
|
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)
|
2013-03-22 04:49:35 +08:00
|
|
|
recipients.select{ |id|
|
|
|
|
!id.is_a?(String) ||
|
|
|
|
id =~ Calculator::INDIVIDUAL_RECIPIENT
|
|
|
|
}.map(&:to_i)
|
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
|
|
|
|
|
|
|
|
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
|
2014-01-18 03:06:22 +08:00
|
|
|
def populate_common_contexts
|
2013-03-04 15:56:39 +08:00
|
|
|
@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(':')
|
proper handling of cross-shard admin visibility
when querying common contexts between user A and messageable user B, "0"
is used as a special course id to indicate user B has at least one
enrollment in an account A admins -- no actual course involved.
to manage common contexts cross shard, they are stored with global ids.
this was "globalizing" 0 to no longer be zero, causing problems. fix
that edge case.
additionally, if there were multiple shards with accounts in which B has
and enrollment and A is an admin, it would overwrite (given corrected
handling of the 0) with the last queried shard's values, rather than
combining them.
fixes CNVS-6303
test-plan:
- have at least two shards
- create user A on shard 1, user B on shard 2
- enroll user B as a teacher in a course under account X on shard 2
- add user A as an admin of account X
- on shard 1, reload user B via user A's messageable users, e.g.:
userB = userA.load_messageable_user(userB)
- userB's common courses should include a key of 0 with
'TeacherEnrollment' as the only value
- repeat on shard 2
- enroll user B as a student in a course under account Y on shard 1
- add user A as an admin of account Y
- on shard 1, reload user B via user A's messageable users (again)
- userB's common courses should include a key of 0 with both
'TeacherEnrollment' and 'StudentEnrollment' as values
- repeat on shard 2
Change-Id: I014d1f0d7793889de512a4a0262e32027ee5702e
Reviewed-on: https://gerrit.instructure.com/21542
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
2013-06-18 04:13:43 +08:00
|
|
|
course_id = course_id.to_i
|
|
|
|
# a course id of 0 indicates admin visibility without an actual shared
|
|
|
|
# course; don't "globalize" it
|
|
|
|
course_id = Shard.global_id_for(course_id) unless course_id.zero?
|
2013-03-04 15:56:39 +08:00
|
|
|
@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
|
2014-01-18 03:06:22 +08:00
|
|
|
if CANVAS_RAILS2
|
|
|
|
alias_method :after_find, :populate_common_contexts
|
|
|
|
else
|
|
|
|
after_find :populate_common_contexts
|
|
|
|
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
|
|
|
|
proper handling of cross-shard admin visibility
when querying common contexts between user A and messageable user B, "0"
is used as a special course id to indicate user B has at least one
enrollment in an account A admins -- no actual course involved.
to manage common contexts cross shard, they are stored with global ids.
this was "globalizing" 0 to no longer be zero, causing problems. fix
that edge case.
additionally, if there were multiple shards with accounts in which B has
and enrollment and A is an admin, it would overwrite (given corrected
handling of the 0) with the last queried shard's values, rather than
combining them.
fixes CNVS-6303
test-plan:
- have at least two shards
- create user A on shard 1, user B on shard 2
- enroll user B as a teacher in a course under account X on shard 2
- add user A as an admin of account X
- on shard 1, reload user B via user A's messageable users, e.g.:
userB = userA.load_messageable_user(userB)
- userB's common courses should include a key of 0 with
'TeacherEnrollment' as the only value
- repeat on shard 2
- enroll user B as a student in a course under account Y on shard 1
- add user A as an admin of account Y
- on shard 1, reload user B via user A's messageable users (again)
- userB's common courses should include a key of 0 with both
'TeacherEnrollment' and 'StudentEnrollment' as values
- repeat on shard 2
Change-Id: I014d1f0d7793889de512a4a0262e32027ee5702e
Reviewed-on: https://gerrit.instructure.com/21542
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
2013-06-18 04:13:43 +08:00
|
|
|
def include_common_contexts_from(other)
|
|
|
|
combine_common_contexts(self.global_common_courses, other.global_common_courses)
|
|
|
|
combine_common_contexts(self.global_common_groups, other.global_common_groups)
|
|
|
|
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
|
|
|
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|
|
proper handling of cross-shard admin visibility
when querying common contexts between user A and messageable user B, "0"
is used as a special course id to indicate user B has at least one
enrollment in an account A admins -- no actual course involved.
to manage common contexts cross shard, they are stored with global ids.
this was "globalizing" 0 to no longer be zero, causing problems. fix
that edge case.
additionally, if there were multiple shards with accounts in which B has
and enrollment and A is an admin, it would overwrite (given corrected
handling of the 0) with the last queried shard's values, rather than
combining them.
fixes CNVS-6303
test-plan:
- have at least two shards
- create user A on shard 1, user B on shard 2
- enroll user B as a teacher in a course under account X on shard 2
- add user A as an admin of account X
- on shard 1, reload user B via user A's messageable users, e.g.:
userB = userA.load_messageable_user(userB)
- userB's common courses should include a key of 0 with
'TeacherEnrollment' as the only value
- repeat on shard 2
- enroll user B as a student in a course under account Y on shard 1
- add user A as an admin of account Y
- on shard 1, reload user B via user A's messageable users (again)
- userB's common courses should include a key of 0 with both
'TeacherEnrollment' and 'StudentEnrollment' as values
- repeat on shard 2
Change-Id: I014d1f0d7793889de512a4a0262e32027ee5702e
Reviewed-on: https://gerrit.instructure.com/21542
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
2013-06-18 04:13:43 +08:00
|
|
|
# a context id of 0 indicates admin visibility without an actual shared
|
|
|
|
# context; don't "globalize" it
|
|
|
|
global_id = id == 0 ? id : Shard.global_id_for(id)
|
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
|
|
|
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
|
|
|
|
proper handling of cross-shard admin visibility
when querying common contexts between user A and messageable user B, "0"
is used as a special course id to indicate user B has at least one
enrollment in an account A admins -- no actual course involved.
to manage common contexts cross shard, they are stored with global ids.
this was "globalizing" 0 to no longer be zero, causing problems. fix
that edge case.
additionally, if there were multiple shards with accounts in which B has
and enrollment and A is an admin, it would overwrite (given corrected
handling of the 0) with the last queried shard's values, rather than
combining them.
fixes CNVS-6303
test-plan:
- have at least two shards
- create user A on shard 1, user B on shard 2
- enroll user B as a teacher in a course under account X on shard 2
- add user A as an admin of account X
- on shard 1, reload user B via user A's messageable users, e.g.:
userB = userA.load_messageable_user(userB)
- userB's common courses should include a key of 0 with
'TeacherEnrollment' as the only value
- repeat on shard 2
- enroll user B as a student in a course under account Y on shard 1
- add user A as an admin of account Y
- on shard 1, reload user B via user A's messageable users (again)
- userB's common courses should include a key of 0 with both
'TeacherEnrollment' and 'StudentEnrollment' as values
- repeat on shard 2
Change-Id: I014d1f0d7793889de512a4a0262e32027ee5702e
Reviewed-on: https://gerrit.instructure.com/21542
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
2013-06-18 04:13:43 +08:00
|
|
|
def combine_common_contexts(left, right)
|
|
|
|
right.each{ |key,values| (left[key] ||= []).concat(values) }
|
|
|
|
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
|