canvas-lms/lib/address_book.rb

58 lines
2.0 KiB
Ruby
Raw Normal View History

AddressBook facade fixes CNVS-29824 refs CNVS-29862, CNVS-29867 test-plan: check for regressions around: * accessing profile#show endpoint, with profiles enabled, is authorized if and only if current user knows profile owner. * eportfolios#show, with profiles enabled, includes link to owner's profile if and only if current user knows owner. * conversations: - filtering of individual recipients when creating a conversation - expansion of context recipients when creating a conversation - restriction of individual recipients to those known via course when creating a conversation in a course - including as an admin over that course - filtering of individual recipients when adding a message to an existing conversation allows existing recipients * searching/browsing address book (conversation creation, link observer to students, due date overrides, etc.): - when loading info about single user (user_id parameter), including combinations of conversation_id and context parameters, returns user data if and only if the target is known to current user under those parameters - users matched: - excludes already listed users - restricts to users known via specified context, if any - including as an admin over that context - finds users with weak associations (e.g. invited student that hasn't logged in for first time yet) when linking observers - doesn't find users with weak associations otherwise - contexts matched: - limited to those known to current user - have count of known users - have counts of known users in synthetic contexts * data returned for known users in various API calls include common course and groups between current user and returned user Change-Id: I66bca0921b298be8d529a713fa982a6dfdcbcc8e Reviewed-on: https://gerrit.instructure.com/84045 Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com> Tested-by: Jenkins QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com>
2016-06-17 00:37:56 +08:00
# manually require since ::MessageableUser satisfies
# AddressBook::MessageableUser and prevents the autoload
require_relative 'address_book/messageable_user'
# see AddressBook::Base for primary documentation of the interface
module AddressBook
STRATEGIES = {
'messageable_user' => { implementation: AddressBook::MessageableUser, label: lambda{ I18n.t('MessageableUser library') } }.freeze,
# TODO CNVS-29869
#'microservice' => { implementation: AddressBook::Service, label: lambda{ I18n.t('AddressBook microservice') } }.freeze,
'empty' => { implementation: AddressBook::Empty, label: lambda{ I18n.t('Empty stub (for testing only)') } }.freeze
}.freeze
DEFAULT_STRATEGY = 'messageable_user'
AddressBook facade fixes CNVS-29824 refs CNVS-29862, CNVS-29867 test-plan: check for regressions around: * accessing profile#show endpoint, with profiles enabled, is authorized if and only if current user knows profile owner. * eportfolios#show, with profiles enabled, includes link to owner's profile if and only if current user knows owner. * conversations: - filtering of individual recipients when creating a conversation - expansion of context recipients when creating a conversation - restriction of individual recipients to those known via course when creating a conversation in a course - including as an admin over that course - filtering of individual recipients when adding a message to an existing conversation allows existing recipients * searching/browsing address book (conversation creation, link observer to students, due date overrides, etc.): - when loading info about single user (user_id parameter), including combinations of conversation_id and context parameters, returns user data if and only if the target is known to current user under those parameters - users matched: - excludes already listed users - restricts to users known via specified context, if any - including as an admin over that context - finds users with weak associations (e.g. invited student that hasn't logged in for first time yet) when linking observers - doesn't find users with weak associations otherwise - contexts matched: - limited to those known to current user - have count of known users - have counts of known users in synthetic contexts * data returned for known users in various API calls include common course and groups between current user and returned user Change-Id: I66bca0921b298be8d529a713fa982a6dfdcbcc8e Reviewed-on: https://gerrit.instructure.com/84045 Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com> Tested-by: Jenkins QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com>
2016-06-17 00:37:56 +08:00
def self.registry
RequestStore.store[:address_books] ||= {}
end
# choose the implementation of address book according to the plugin setting
def self.strategy
strategy = Canvas::Plugin.find('address_book').settings[:strategy]
unless STRATEGIES.has_key?(strategy)
# plugin setting specifies an invalid strategy. (TODO: logger.warn or
# something.) gracefully fall back on default
strategy = DEFAULT_STRATEGY
end
strategy
end
def self.implementation
return STRATEGIES[strategy][:implementation]
end
# instantiates an address book for the sender
AddressBook facade fixes CNVS-29824 refs CNVS-29862, CNVS-29867 test-plan: check for regressions around: * accessing profile#show endpoint, with profiles enabled, is authorized if and only if current user knows profile owner. * eportfolios#show, with profiles enabled, includes link to owner's profile if and only if current user knows owner. * conversations: - filtering of individual recipients when creating a conversation - expansion of context recipients when creating a conversation - restriction of individual recipients to those known via course when creating a conversation in a course - including as an admin over that course - filtering of individual recipients when adding a message to an existing conversation allows existing recipients * searching/browsing address book (conversation creation, link observer to students, due date overrides, etc.): - when loading info about single user (user_id parameter), including combinations of conversation_id and context parameters, returns user data if and only if the target is known to current user under those parameters - users matched: - excludes already listed users - restricts to users known via specified context, if any - including as an admin over that context - finds users with weak associations (e.g. invited student that hasn't logged in for first time yet) when linking observers - doesn't find users with weak associations otherwise - contexts matched: - limited to those known to current user - have count of known users - have counts of known users in synthetic contexts * data returned for known users in various API calls include common course and groups between current user and returned user Change-Id: I66bca0921b298be8d529a713fa982a6dfdcbcc8e Reviewed-on: https://gerrit.instructure.com/84045 Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com> Tested-by: Jenkins QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com>
2016-06-17 00:37:56 +08:00
def self.for(sender)
registry[sender] ||= implementation.new(sender)
AddressBook facade fixes CNVS-29824 refs CNVS-29862, CNVS-29867 test-plan: check for regressions around: * accessing profile#show endpoint, with profiles enabled, is authorized if and only if current user knows profile owner. * eportfolios#show, with profiles enabled, includes link to owner's profile if and only if current user knows owner. * conversations: - filtering of individual recipients when creating a conversation - expansion of context recipients when creating a conversation - restriction of individual recipients to those known via course when creating a conversation in a course - including as an admin over that course - filtering of individual recipients when adding a message to an existing conversation allows existing recipients * searching/browsing address book (conversation creation, link observer to students, due date overrides, etc.): - when loading info about single user (user_id parameter), including combinations of conversation_id and context parameters, returns user data if and only if the target is known to current user under those parameters - users matched: - excludes already listed users - restricts to users known via specified context, if any - including as an admin over that context - finds users with weak associations (e.g. invited student that hasn't logged in for first time yet) when linking observers - doesn't find users with weak associations otherwise - contexts matched: - limited to those known to current user - have count of known users - have counts of known users in synthetic contexts * data returned for known users in various API calls include common course and groups between current user and returned user Change-Id: I66bca0921b298be8d529a713fa982a6dfdcbcc8e Reviewed-on: https://gerrit.instructure.com/84045 Reviewed-by: Jonathan Featherstone <jfeatherstone@instructure.com> Tested-by: Jenkins QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com> Product-Review: Jacob Fugal <jacob@instructure.com>
2016-06-17 00:37:56 +08:00
end
# partitions the list of recipients into user ids and context asset strings
def self.partition_recipients(recipients)
users = ::MessageableUser.individual_recipients(recipients)
contexts = ::MessageableUser.context_recipients(recipients)
return users, contexts
end
# filters the list of users to only those that are "available" (but not
# necessarily known to any particular sender)
def self.available(users)
Shackles.activate(:slave) do
::MessageableUser.available.where(id: users).to_a
end
end
def self.valid_context?(context_code)
context_code =~ ::MessageableUser::Calculator::CONTEXT_RECIPIENT
end
end