canvas-lms/lib/feature.rb

656 lines
24 KiB
Ruby
Raw Normal View History

feature flags infrastructure and API test plan: - install the test_features plugin (since no real features exist yet) - render and consult the feature flags documentation - have a test environment with a root account, sub-account, course in sub-account, and user - Use the "list features" endpoint as a root account admin (with no site admin privileges), on the root account context, and confirm that hidden features do not show up - Use the "list features" endpoint as a site admin user, on the root account context, and confirm that hidden features show up - Use the "list features" endpoint on the site admin account and confirm the hidden features show up - Use the "set feature flag" endpoint on a hidden feature on site admin and ensure the feature becomes visible in all root accounts - Use the "set feature flag endpoint" on a hidden feature on a single root account, and ensure the feature becomes visible to that root account and not others - Confirm that root_opt_in features appear "Off" by default in root accounts, after being "Allowed" in code or site admin - Confirm a feature flag that is set to "on" or "off" (vs. "allowed") cannot be overridden in a lower context (and the API returns locked=true for them) - Confirm that setting locking_account_id requires admin rights in the locking account - Confirm that a feature flag with locking_account_id cannot be changed without admin rights in the locking account (e.g., set a feature flag on a course, locked with the root account's id, and make sure a teacher who is not an account admin can't change it) - Confirm feature flags can be deleted with the "remove feature flag" endpoint (and they are only deleted where they are defined, not when called on an object that inherits a flag) Change-Id: I3e12e23b4454889b6e8b263f1315e82d8f2ada52 Reviewed-on: https://gerrit.instructure.com/25502 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Matt Fairbourn <mfairbourn@instructure.com> Product-Review: Matt Goodwin <mattg@instructure.com> Reviewed-by: Zach Pendleton <zachp@instructure.com>
2013-10-22 23:28:26 +08:00
#
# Copyright (C) 2013 - present Instructure, Inc.
feature flags infrastructure and API test plan: - install the test_features plugin (since no real features exist yet) - render and consult the feature flags documentation - have a test environment with a root account, sub-account, course in sub-account, and user - Use the "list features" endpoint as a root account admin (with no site admin privileges), on the root account context, and confirm that hidden features do not show up - Use the "list features" endpoint as a site admin user, on the root account context, and confirm that hidden features show up - Use the "list features" endpoint on the site admin account and confirm the hidden features show up - Use the "set feature flag" endpoint on a hidden feature on site admin and ensure the feature becomes visible in all root accounts - Use the "set feature flag endpoint" on a hidden feature on a single root account, and ensure the feature becomes visible to that root account and not others - Confirm that root_opt_in features appear "Off" by default in root accounts, after being "Allowed" in code or site admin - Confirm a feature flag that is set to "on" or "off" (vs. "allowed") cannot be overridden in a lower context (and the API returns locked=true for them) - Confirm that setting locking_account_id requires admin rights in the locking account - Confirm that a feature flag with locking_account_id cannot be changed without admin rights in the locking account (e.g., set a feature flag on a course, locked with the root account's id, and make sure a teacher who is not an account admin can't change it) - Confirm feature flags can be deleted with the "remove feature flag" endpoint (and they are only deleted where they are defined, not when called on an object that inherits a flag) Change-Id: I3e12e23b4454889b6e8b263f1315e82d8f2ada52 Reviewed-on: https://gerrit.instructure.com/25502 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Matt Fairbourn <mfairbourn@instructure.com> Product-Review: Matt Goodwin <mattg@instructure.com> Reviewed-by: Zach Pendleton <zachp@instructure.com>
2013-10-22 23:28:26 +08:00
#
# 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 Feature
duplicate gradebook view hierarchy This patchset duplicates the gradebook view hierarchy so that we can develop gradebook enhancements side by side with the current gradebook. A feature flag has been created called "Gradezilla" (this name is for internal purposes only and should never be used in production) that is only allowed in development and defaults to on. With this feature flage enabled a button now appears next to the "individual view" button in gradebook to navigate to Gradezilla. The page also has a header of "Gradezilla" as to further distinguish the page since they look identical at the start of this project. In the future, we'll replace Gradezilla with something else but while in development we wanted an easy term to search for to know which part of the gradebook we were in. closes: CNVS-33684 Listed below are the paths for which a corresponding gradezilla file was created. See the git diff for full details. app/coffeescripts/bundles/gradebook.coffee app/coffeescripts/gradebook/*.coffee app/coffeescripts/views/gradebook/*.coffee app/jsx/gradebook/*.jsx app/stylesheets/bundles/gradebook.scss app/stylesheets/pages/gradebook/*.scss app/views/gradebooks/gradezilla.html.erb app/views/jst/gradebook/*.handlebars spec/coffeescripts/gradebook/*.coffee spec/coffeescripts/jsx/gradebook/*.coffee spec/javascripts/jsx/gradebook/*.jsx spec/selenium/grades/gradebook/*.rb spec/selenium/outcomes/outcome_gradebook_spec.rb spec/selenium/helpers/gradebook_common.rb spec/selenium/grades/page_objects/gradebook_page.rb spec/selenium/grades/setup/gradebook_setup.rb spec/views/gradebooks/gradebook.html.erb_spec.rb Test plan: - Ensure that the feature flag for Gradezilla is enabled - On the Gradebook page, there is now a button to take you to Gradezilla - Once selected, Gradezilla should become your default Gradebook until the "Gradebook" button is clicked. - Everything in Gradezilla should appear just as it does in Gradebook. - Having selected Gradezilla, disabled the feature flag - Ensure that upon returning to /gradebook, that the current Gradebook is selected - If the feature is disabled, you should not see the Gradezilla button. Change-Id: I6f1391a4264a8d0e6016a9a91f8055010f1c36d1 Reviewed-on: https://gerrit.instructure.com/98498 Tested-by: Jenkins Reviewed-by: Keith T. Garner <kgarner@instructure.com> Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com> QA-Review: KC Naegle <knaegle@instructure.com> Product-Review: Keith T. Garner <kgarner@instructure.com>
2016-12-19 22:38:49 +08:00
ATTRS = [:feature, :display_name, :description, :applies_to, :state,
:root_opt_in, :enable_at, :beta, :development,
:release_notes_url, :custom_transition_proc,
:after_state_change_proc, :autoexpand, :touch_context].freeze
feature flags infrastructure and API test plan: - install the test_features plugin (since no real features exist yet) - render and consult the feature flags documentation - have a test environment with a root account, sub-account, course in sub-account, and user - Use the "list features" endpoint as a root account admin (with no site admin privileges), on the root account context, and confirm that hidden features do not show up - Use the "list features" endpoint as a site admin user, on the root account context, and confirm that hidden features show up - Use the "list features" endpoint on the site admin account and confirm the hidden features show up - Use the "set feature flag" endpoint on a hidden feature on site admin and ensure the feature becomes visible in all root accounts - Use the "set feature flag endpoint" on a hidden feature on a single root account, and ensure the feature becomes visible to that root account and not others - Confirm that root_opt_in features appear "Off" by default in root accounts, after being "Allowed" in code or site admin - Confirm a feature flag that is set to "on" or "off" (vs. "allowed") cannot be overridden in a lower context (and the API returns locked=true for them) - Confirm that setting locking_account_id requires admin rights in the locking account - Confirm that a feature flag with locking_account_id cannot be changed without admin rights in the locking account (e.g., set a feature flag on a course, locked with the root account's id, and make sure a teacher who is not an account admin can't change it) - Confirm feature flags can be deleted with the "remove feature flag" endpoint (and they are only deleted where they are defined, not when called on an object that inherits a flag) Change-Id: I3e12e23b4454889b6e8b263f1315e82d8f2ada52 Reviewed-on: https://gerrit.instructure.com/25502 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Matt Fairbourn <mfairbourn@instructure.com> Product-Review: Matt Goodwin <mattg@instructure.com> Reviewed-by: Zach Pendleton <zachp@instructure.com>
2013-10-22 23:28:26 +08:00
attr_reader *ATTRS
def initialize(opts = {})
@state = 'allowed'
opts.each do |key, val|
next unless ATTRS.include?(key)
val = (Feature.production_environment? ? 'hidden' : 'allowed') if key == :state && val == 'hidden_in_prod'
feature flags infrastructure and API test plan: - install the test_features plugin (since no real features exist yet) - render and consult the feature flags documentation - have a test environment with a root account, sub-account, course in sub-account, and user - Use the "list features" endpoint as a root account admin (with no site admin privileges), on the root account context, and confirm that hidden features do not show up - Use the "list features" endpoint as a site admin user, on the root account context, and confirm that hidden features show up - Use the "list features" endpoint on the site admin account and confirm the hidden features show up - Use the "set feature flag" endpoint on a hidden feature on site admin and ensure the feature becomes visible in all root accounts - Use the "set feature flag endpoint" on a hidden feature on a single root account, and ensure the feature becomes visible to that root account and not others - Confirm that root_opt_in features appear "Off" by default in root accounts, after being "Allowed" in code or site admin - Confirm a feature flag that is set to "on" or "off" (vs. "allowed") cannot be overridden in a lower context (and the API returns locked=true for them) - Confirm that setting locking_account_id requires admin rights in the locking account - Confirm that a feature flag with locking_account_id cannot be changed without admin rights in the locking account (e.g., set a feature flag on a course, locked with the root account's id, and make sure a teacher who is not an account admin can't change it) - Confirm feature flags can be deleted with the "remove feature flag" endpoint (and they are only deleted where they are defined, not when called on an object that inherits a flag) Change-Id: I3e12e23b4454889b6e8b263f1315e82d8f2ada52 Reviewed-on: https://gerrit.instructure.com/25502 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Matt Fairbourn <mfairbourn@instructure.com> Product-Review: Matt Goodwin <mattg@instructure.com> Reviewed-by: Zach Pendleton <zachp@instructure.com>
2013-10-22 23:28:26 +08:00
next if key == :state && !%w(hidden off allowed on).include?(val)
instance_variable_set "@#{key}", val
end
remove "Allowed" state for RootAccount features on root accounts the "Allowed" state means a feature is off in an account, but sub-accounts or courses below it are allowed to enable it. the 'allowed' state does not, however, make a lot of sense for features that apply to RootAccount. since the feature cannot be controlled in sub-accounts or courses, the 'allowed' state is equivalent to 'off' here. so to make this less confusing, remove the "allowed" state for RootAccount features. (specifically, lock the transition in the API, and make the UI hide buttons for locked transitions that don't have messages to display when the user tries to perform them) test plan: - set the Use New Styles feature to "Allowed" in Site Admin account settings - in a root account settings page, ensure the 'Allowed' option is not selectable for this feature - ensure that the API reports the new_styles feature is "off" and its "allowed" transition is locked i.e., GET /api/v1/accounts/1/features/flags/new_styles includes state: 'off' and transitions: {allowed: {locked: true}} - ensure the API refuses to set the new_styles feature to "allowed" in the root account i.e., PUT /api/v1/accounts/1/features/flags/new_styles?state=allowed should return a 403 error and not change the state - regression test: in a sub-account, ensure the 'Use New Styles' feature does not appear - regression test: verify that when a (non-site-admin) root account admin attempts to disable Draft State in an account, the Off button is still there, and a message appears when you click it, and the feature remains enabled fixes CNVS-13220 Change-Id: I4d41076c10696b02d0c482a778d2555714487f17 Reviewed-on: https://gerrit.instructure.com/35473 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Bracken Mosbacker <bracken@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Bracken Mosbacker <bracken@instructure.com> Product-Review: Hilary Scharton <hilary@instructure.com>
2014-05-28 06:11:56 +08:00
# for RootAccount features, "allowed" state is redundant; show "off" instead
@root_opt_in = true if @applies_to == 'RootAccount'
feature flags infrastructure and API test plan: - install the test_features plugin (since no real features exist yet) - render and consult the feature flags documentation - have a test environment with a root account, sub-account, course in sub-account, and user - Use the "list features" endpoint as a root account admin (with no site admin privileges), on the root account context, and confirm that hidden features do not show up - Use the "list features" endpoint as a site admin user, on the root account context, and confirm that hidden features show up - Use the "list features" endpoint on the site admin account and confirm the hidden features show up - Use the "set feature flag" endpoint on a hidden feature on site admin and ensure the feature becomes visible in all root accounts - Use the "set feature flag endpoint" on a hidden feature on a single root account, and ensure the feature becomes visible to that root account and not others - Confirm that root_opt_in features appear "Off" by default in root accounts, after being "Allowed" in code or site admin - Confirm a feature flag that is set to "on" or "off" (vs. "allowed") cannot be overridden in a lower context (and the API returns locked=true for them) - Confirm that setting locking_account_id requires admin rights in the locking account - Confirm that a feature flag with locking_account_id cannot be changed without admin rights in the locking account (e.g., set a feature flag on a course, locked with the root account's id, and make sure a teacher who is not an account admin can't change it) - Confirm feature flags can be deleted with the "remove feature flag" endpoint (and they are only deleted where they are defined, not when called on an object that inherits a flag) Change-Id: I3e12e23b4454889b6e8b263f1315e82d8f2ada52 Reviewed-on: https://gerrit.instructure.com/25502 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Matt Fairbourn <mfairbourn@instructure.com> Product-Review: Matt Goodwin <mattg@instructure.com> Reviewed-by: Zach Pendleton <zachp@instructure.com>
2013-10-22 23:28:26 +08:00
end
def clone_for_cache
Feature.new(feature: @feature, state: @state)
end
feature flags infrastructure and API test plan: - install the test_features plugin (since no real features exist yet) - render and consult the feature flags documentation - have a test environment with a root account, sub-account, course in sub-account, and user - Use the "list features" endpoint as a root account admin (with no site admin privileges), on the root account context, and confirm that hidden features do not show up - Use the "list features" endpoint as a site admin user, on the root account context, and confirm that hidden features show up - Use the "list features" endpoint on the site admin account and confirm the hidden features show up - Use the "set feature flag" endpoint on a hidden feature on site admin and ensure the feature becomes visible in all root accounts - Use the "set feature flag endpoint" on a hidden feature on a single root account, and ensure the feature becomes visible to that root account and not others - Confirm that root_opt_in features appear "Off" by default in root accounts, after being "Allowed" in code or site admin - Confirm a feature flag that is set to "on" or "off" (vs. "allowed") cannot be overridden in a lower context (and the API returns locked=true for them) - Confirm that setting locking_account_id requires admin rights in the locking account - Confirm that a feature flag with locking_account_id cannot be changed without admin rights in the locking account (e.g., set a feature flag on a course, locked with the root account's id, and make sure a teacher who is not an account admin can't change it) - Confirm feature flags can be deleted with the "remove feature flag" endpoint (and they are only deleted where they are defined, not when called on an object that inherits a flag) Change-Id: I3e12e23b4454889b6e8b263f1315e82d8f2ada52 Reviewed-on: https://gerrit.instructure.com/25502 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Matt Fairbourn <mfairbourn@instructure.com> Product-Review: Matt Goodwin <mattg@instructure.com> Reviewed-by: Zach Pendleton <zachp@instructure.com>
2013-10-22 23:28:26 +08:00
def default?
true
end
def locked?(query_context)
feature flags infrastructure and API test plan: - install the test_features plugin (since no real features exist yet) - render and consult the feature flags documentation - have a test environment with a root account, sub-account, course in sub-account, and user - Use the "list features" endpoint as a root account admin (with no site admin privileges), on the root account context, and confirm that hidden features do not show up - Use the "list features" endpoint as a site admin user, on the root account context, and confirm that hidden features show up - Use the "list features" endpoint on the site admin account and confirm the hidden features show up - Use the "set feature flag" endpoint on a hidden feature on site admin and ensure the feature becomes visible in all root accounts - Use the "set feature flag endpoint" on a hidden feature on a single root account, and ensure the feature becomes visible to that root account and not others - Confirm that root_opt_in features appear "Off" by default in root accounts, after being "Allowed" in code or site admin - Confirm a feature flag that is set to "on" or "off" (vs. "allowed") cannot be overridden in a lower context (and the API returns locked=true for them) - Confirm that setting locking_account_id requires admin rights in the locking account - Confirm that a feature flag with locking_account_id cannot be changed without admin rights in the locking account (e.g., set a feature flag on a course, locked with the root account's id, and make sure a teacher who is not an account admin can't change it) - Confirm feature flags can be deleted with the "remove feature flag" endpoint (and they are only deleted where they are defined, not when called on an object that inherits a flag) Change-Id: I3e12e23b4454889b6e8b263f1315e82d8f2ada52 Reviewed-on: https://gerrit.instructure.com/25502 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Matt Fairbourn <mfairbourn@instructure.com> Product-Review: Matt Goodwin <mattg@instructure.com> Reviewed-by: Zach Pendleton <zachp@instructure.com>
2013-10-22 23:28:26 +08:00
query_context.blank? || !allowed? && !hidden?
end
def enabled?
@state == 'on'
end
def allowed?
@state == 'allowed'
end
def hidden?
@state == 'hidden'
end
def self.production_environment?
Rails.env.production? && !(ApplicationController.respond_to?(:test_cluster?) && ApplicationController.test_cluster?)
end
feature flags infrastructure and API test plan: - install the test_features plugin (since no real features exist yet) - render and consult the feature flags documentation - have a test environment with a root account, sub-account, course in sub-account, and user - Use the "list features" endpoint as a root account admin (with no site admin privileges), on the root account context, and confirm that hidden features do not show up - Use the "list features" endpoint as a site admin user, on the root account context, and confirm that hidden features show up - Use the "list features" endpoint on the site admin account and confirm the hidden features show up - Use the "set feature flag" endpoint on a hidden feature on site admin and ensure the feature becomes visible in all root accounts - Use the "set feature flag endpoint" on a hidden feature on a single root account, and ensure the feature becomes visible to that root account and not others - Confirm that root_opt_in features appear "Off" by default in root accounts, after being "Allowed" in code or site admin - Confirm a feature flag that is set to "on" or "off" (vs. "allowed") cannot be overridden in a lower context (and the API returns locked=true for them) - Confirm that setting locking_account_id requires admin rights in the locking account - Confirm that a feature flag with locking_account_id cannot be changed without admin rights in the locking account (e.g., set a feature flag on a course, locked with the root account's id, and make sure a teacher who is not an account admin can't change it) - Confirm feature flags can be deleted with the "remove feature flag" endpoint (and they are only deleted where they are defined, not when called on an object that inherits a flag) Change-Id: I3e12e23b4454889b6e8b263f1315e82d8f2ada52 Reviewed-on: https://gerrit.instructure.com/25502 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Matt Fairbourn <mfairbourn@instructure.com> Product-Review: Matt Goodwin <mattg@instructure.com> Reviewed-by: Zach Pendleton <zachp@instructure.com>
2013-10-22 23:28:26 +08:00
# Register one or more features. Must be done during application initialization.
# The feature_hash is as follows:
# automatic_essay_grading: {
duplicate gradebook view hierarchy This patchset duplicates the gradebook view hierarchy so that we can develop gradebook enhancements side by side with the current gradebook. A feature flag has been created called "Gradezilla" (this name is for internal purposes only and should never be used in production) that is only allowed in development and defaults to on. With this feature flage enabled a button now appears next to the "individual view" button in gradebook to navigate to Gradezilla. The page also has a header of "Gradezilla" as to further distinguish the page since they look identical at the start of this project. In the future, we'll replace Gradezilla with something else but while in development we wanted an easy term to search for to know which part of the gradebook we were in. closes: CNVS-33684 Listed below are the paths for which a corresponding gradezilla file was created. See the git diff for full details. app/coffeescripts/bundles/gradebook.coffee app/coffeescripts/gradebook/*.coffee app/coffeescripts/views/gradebook/*.coffee app/jsx/gradebook/*.jsx app/stylesheets/bundles/gradebook.scss app/stylesheets/pages/gradebook/*.scss app/views/gradebooks/gradezilla.html.erb app/views/jst/gradebook/*.handlebars spec/coffeescripts/gradebook/*.coffee spec/coffeescripts/jsx/gradebook/*.coffee spec/javascripts/jsx/gradebook/*.jsx spec/selenium/grades/gradebook/*.rb spec/selenium/outcomes/outcome_gradebook_spec.rb spec/selenium/helpers/gradebook_common.rb spec/selenium/grades/page_objects/gradebook_page.rb spec/selenium/grades/setup/gradebook_setup.rb spec/views/gradebooks/gradebook.html.erb_spec.rb Test plan: - Ensure that the feature flag for Gradezilla is enabled - On the Gradebook page, there is now a button to take you to Gradezilla - Once selected, Gradezilla should become your default Gradebook until the "Gradebook" button is clicked. - Everything in Gradezilla should appear just as it does in Gradebook. - Having selected Gradezilla, disabled the feature flag - Ensure that upon returning to /gradebook, that the current Gradebook is selected - If the feature is disabled, you should not see the Gradezilla button. Change-Id: I6f1391a4264a8d0e6016a9a91f8055010f1c36d1 Reviewed-on: https://gerrit.instructure.com/98498 Tested-by: Jenkins Reviewed-by: Keith T. Garner <kgarner@instructure.com> Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com> QA-Review: KC Naegle <knaegle@instructure.com> Product-Review: Keith T. Garner <kgarner@instructure.com>
2016-12-19 22:38:49 +08:00
# display_name: -> { I18n.t('features.automatic_essay_grading', 'Automatic Essay Grading') },
# description: -> { I18n.t('features.automatic_essay_grading_description, 'Popup text describing the feature goes here') },
# applies_to: 'Course', # or 'RootAccount' or 'Account' or 'User'
# state: 'allowed', # or 'off', 'on', 'hidden', or 'hidden_in_prod'
# # - 'hidden' means the feature must be set by a site admin before it will be visible
# # (in that context and below) to other users
# # - 'hidden_in_prod' registers 'hidden' in production environments or 'allowed' elsewhere
# root_opt_in: false, # if true, 'allowed' features in source or site admin
# # will be inherited in "off" state by root accounts
# enable_at: Date.new(2014, 1, 1), # estimated release date shown in UI
# beta: false, # 'beta' tag shown in UI
# development: false, # whether the feature is restricted to development / test / beta instances
# # setting `development: true` prevents the flag from being registered on production,
# # which means `context.feature_enabled?` calls for the feature will always return false.
# release_notes_url: 'http://example.com/',
#
# # optional: you can supply a Proc to attach warning messages to and/or forbid certain transitions
# # see lib/feature/draft_state.rb for example usage
# custom_transition_proc: ->(user, context, from_state, transitions) do
# if from_state == 'off' && context.is_a?(Course) && context.has_submitted_essays?
# transitions['on']['warning'] = I18n.t('features.automatic_essay_grading.enable_warning',
# 'Enabling this feature after some students have submitted essays may yield inconsistent grades.')
# end
# end,
#
# # optional hook to be called before after a feature flag change
# # queue a delayed_job to perform any nontrivial processing
# after_state_change_proc: ->(user, context, old_state, new_state) { ... }
# }
feature flags infrastructure and API test plan: - install the test_features plugin (since no real features exist yet) - render and consult the feature flags documentation - have a test environment with a root account, sub-account, course in sub-account, and user - Use the "list features" endpoint as a root account admin (with no site admin privileges), on the root account context, and confirm that hidden features do not show up - Use the "list features" endpoint as a site admin user, on the root account context, and confirm that hidden features show up - Use the "list features" endpoint on the site admin account and confirm the hidden features show up - Use the "set feature flag" endpoint on a hidden feature on site admin and ensure the feature becomes visible in all root accounts - Use the "set feature flag endpoint" on a hidden feature on a single root account, and ensure the feature becomes visible to that root account and not others - Confirm that root_opt_in features appear "Off" by default in root accounts, after being "Allowed" in code or site admin - Confirm a feature flag that is set to "on" or "off" (vs. "allowed") cannot be overridden in a lower context (and the API returns locked=true for them) - Confirm that setting locking_account_id requires admin rights in the locking account - Confirm that a feature flag with locking_account_id cannot be changed without admin rights in the locking account (e.g., set a feature flag on a course, locked with the root account's id, and make sure a teacher who is not an account admin can't change it) - Confirm feature flags can be deleted with the "remove feature flag" endpoint (and they are only deleted where they are defined, not when called on an object that inherits a flag) Change-Id: I3e12e23b4454889b6e8b263f1315e82d8f2ada52 Reviewed-on: https://gerrit.instructure.com/25502 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Matt Fairbourn <mfairbourn@instructure.com> Product-Review: Matt Goodwin <mattg@instructure.com> Reviewed-by: Zach Pendleton <zachp@instructure.com>
2013-10-22 23:28:26 +08:00
def self.register(feature_hash)
@features ||= {}
feature_hash.each do |feature_name, attrs|
next if attrs[:development] && production_environment?
feature = feature_name.to_s
@features[feature] = Feature.new({feature: feature}.merge(attrs))
feature flags infrastructure and API test plan: - install the test_features plugin (since no real features exist yet) - render and consult the feature flags documentation - have a test environment with a root account, sub-account, course in sub-account, and user - Use the "list features" endpoint as a root account admin (with no site admin privileges), on the root account context, and confirm that hidden features do not show up - Use the "list features" endpoint as a site admin user, on the root account context, and confirm that hidden features show up - Use the "list features" endpoint on the site admin account and confirm the hidden features show up - Use the "set feature flag" endpoint on a hidden feature on site admin and ensure the feature becomes visible in all root accounts - Use the "set feature flag endpoint" on a hidden feature on a single root account, and ensure the feature becomes visible to that root account and not others - Confirm that root_opt_in features appear "Off" by default in root accounts, after being "Allowed" in code or site admin - Confirm a feature flag that is set to "on" or "off" (vs. "allowed") cannot be overridden in a lower context (and the API returns locked=true for them) - Confirm that setting locking_account_id requires admin rights in the locking account - Confirm that a feature flag with locking_account_id cannot be changed without admin rights in the locking account (e.g., set a feature flag on a course, locked with the root account's id, and make sure a teacher who is not an account admin can't change it) - Confirm feature flags can be deleted with the "remove feature flag" endpoint (and they are only deleted where they are defined, not when called on an object that inherits a flag) Change-Id: I3e12e23b4454889b6e8b263f1315e82d8f2ada52 Reviewed-on: https://gerrit.instructure.com/25502 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Matt Fairbourn <mfairbourn@instructure.com> Product-Review: Matt Goodwin <mattg@instructure.com> Reviewed-by: Zach Pendleton <zachp@instructure.com>
2013-10-22 23:28:26 +08:00
end
end
# TODO: register built-in features here
# (plugins may register additional features during application initialization)
register(
'google_docs_domain_restriction' =>
{
display_name: -> { I18n.t('features.google_docs_domain_restriction', 'Google Docs Domain Restriction') },
description: -> { I18n.t('google_docs_domain_restriction_description', <<END) },
Google Docs Domain Restriction allows Google Docs submissions and collaborations
to be restricted to a single domain. Students attempting to submit assignments or
join collaborations on an unapproved domain will receive an error message notifying them
that they will need to update their Google Docs integration.
END
applies_to: 'RootAccount',
state: 'hidden',
root_opt_in: true
},
'epub_export' =>
{
display_name: -> { I18n.t('ePub Exporting') },
description: -> { I18n.t(<<END) },
This enables users to generate and download course ePub.
END
applies_to: 'Course',
state: 'allowed',
root_opt_in: true,
beta: true
},
a way for accounts to opt-in to new styles and users to high-contrast fixes CNVS-11426 The UI/UX team *really* wants to start doing some major style changes to the canvas interface. Because it is a very visual change and especially because we've let people hack the crap out of canvas styles with their own css override file, any changes we do need to be behind a feature flag so an institution can opt-in when they are ready. This commit does some trickery so we actually create 4 different versions of every stylesheet. one for each variant in: legacy_normal_contrast legacy_high_contrast new_styles_normal_contrast new_styles_high_contrast and then sets the $use_new_styles and $use_high_contrast sass variables accordingly in each. now, in any sass file, you can do things like: @if $use_new_styles { background-color: red; } @else { background-color: blue; } @if not $use_high_contrast{ font-size: 12px; } test plan: * in a production (minified assets) environment, ensure you see: <link href="/assets/common_legacy_normal_contrast.css... in the <head> of the page * go to the account settings page for the domain_root_account you are on * turn on the "Use New Styles" feature * now verify that <link href="/assets/common_new_styles_normal_contrast.css... is in the <head>. There should not be any visible differences because we do not have any styles that target specifically $use_new_styles yet. * now, go to /settings and turn on the user feature for "Use High Contrast Styles" * verify that <link href="/assets/common_new_styles_high_contrast.css.. is in the <head> * again, turning that on will not actually change the way anything looks, the next commit (g/32863) will take care of that Change-Id: I45ba4ddfe780c5c819fb995b61ebfc0a5325d418 Reviewed-on: https://gerrit.instructure.com/31881 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
2014-04-03 14:37:18 +08:00
'high_contrast' =>
{
display_name: -> { I18n.t('features.high_contrast', 'High Contrast UI') },
a way for accounts to opt-in to new styles and users to high-contrast fixes CNVS-11426 The UI/UX team *really* wants to start doing some major style changes to the canvas interface. Because it is a very visual change and especially because we've let people hack the crap out of canvas styles with their own css override file, any changes we do need to be behind a feature flag so an institution can opt-in when they are ready. This commit does some trickery so we actually create 4 different versions of every stylesheet. one for each variant in: legacy_normal_contrast legacy_high_contrast new_styles_normal_contrast new_styles_high_contrast and then sets the $use_new_styles and $use_high_contrast sass variables accordingly in each. now, in any sass file, you can do things like: @if $use_new_styles { background-color: red; } @else { background-color: blue; } @if not $use_high_contrast{ font-size: 12px; } test plan: * in a production (minified assets) environment, ensure you see: <link href="/assets/common_legacy_normal_contrast.css... in the <head> of the page * go to the account settings page for the domain_root_account you are on * turn on the "Use New Styles" feature * now verify that <link href="/assets/common_new_styles_normal_contrast.css... is in the <head>. There should not be any visible differences because we do not have any styles that target specifically $use_new_styles yet. * now, go to /settings and turn on the user feature for "Use High Contrast Styles" * verify that <link href="/assets/common_new_styles_high_contrast.css.. is in the <head> * again, turning that on will not actually change the way anything looks, the next commit (g/32863) will take care of that Change-Id: I45ba4ddfe780c5c819fb995b61ebfc0a5325d418 Reviewed-on: https://gerrit.instructure.com/31881 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
2014-04-03 14:37:18 +08:00
description: -> { I18n.t('high_contrast_description', <<-END) },
High Contrast enhances the color contrast of the UI (text, buttons, etc.), making those items more
distinct and easier to identify. Note: Institution branding will be disabled.
a way for accounts to opt-in to new styles and users to high-contrast fixes CNVS-11426 The UI/UX team *really* wants to start doing some major style changes to the canvas interface. Because it is a very visual change and especially because we've let people hack the crap out of canvas styles with their own css override file, any changes we do need to be behind a feature flag so an institution can opt-in when they are ready. This commit does some trickery so we actually create 4 different versions of every stylesheet. one for each variant in: legacy_normal_contrast legacy_high_contrast new_styles_normal_contrast new_styles_high_contrast and then sets the $use_new_styles and $use_high_contrast sass variables accordingly in each. now, in any sass file, you can do things like: @if $use_new_styles { background-color: red; } @else { background-color: blue; } @if not $use_high_contrast{ font-size: 12px; } test plan: * in a production (minified assets) environment, ensure you see: <link href="/assets/common_legacy_normal_contrast.css... in the <head> of the page * go to the account settings page for the domain_root_account you are on * turn on the "Use New Styles" feature * now verify that <link href="/assets/common_new_styles_normal_contrast.css... is in the <head>. There should not be any visible differences because we do not have any styles that target specifically $use_new_styles yet. * now, go to /settings and turn on the user feature for "Use High Contrast Styles" * verify that <link href="/assets/common_new_styles_high_contrast.css.. is in the <head> * again, turning that on will not actually change the way anything looks, the next commit (g/32863) will take care of that Change-Id: I45ba4ddfe780c5c819fb995b61ebfc0a5325d418 Reviewed-on: https://gerrit.instructure.com/31881 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
2014-04-03 14:37:18 +08:00
END
applies_to: 'User',
state: 'allowed',
autoexpand: true
a way for accounts to opt-in to new styles and users to high-contrast fixes CNVS-11426 The UI/UX team *really* wants to start doing some major style changes to the canvas interface. Because it is a very visual change and especially because we've let people hack the crap out of canvas styles with their own css override file, any changes we do need to be behind a feature flag so an institution can opt-in when they are ready. This commit does some trickery so we actually create 4 different versions of every stylesheet. one for each variant in: legacy_normal_contrast legacy_high_contrast new_styles_normal_contrast new_styles_high_contrast and then sets the $use_new_styles and $use_high_contrast sass variables accordingly in each. now, in any sass file, you can do things like: @if $use_new_styles { background-color: red; } @else { background-color: blue; } @if not $use_high_contrast{ font-size: 12px; } test plan: * in a production (minified assets) environment, ensure you see: <link href="/assets/common_legacy_normal_contrast.css... in the <head> of the page * go to the account settings page for the domain_root_account you are on * turn on the "Use New Styles" feature * now verify that <link href="/assets/common_new_styles_normal_contrast.css... is in the <head>. There should not be any visible differences because we do not have any styles that target specifically $use_new_styles yet. * now, go to /settings and turn on the user feature for "Use High Contrast Styles" * verify that <link href="/assets/common_new_styles_high_contrast.css.. is in the <head> * again, turning that on will not actually change the way anything looks, the next commit (g/32863) will take care of that Change-Id: I45ba4ddfe780c5c819fb995b61ebfc0a5325d418 Reviewed-on: https://gerrit.instructure.com/31881 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Ryan Shaw <ryan@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com> QA-Review: Ryan Shaw <ryan@instructure.com> Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
2014-04-03 14:37:18 +08:00
},
'underline_all_links' =>
{
display_name: -> { I18n.t('Underline Links') },
description: -> { I18n.t('underline_all_links_description', <<-END, wrapper: { '*' => '<span class="feature-detail-underline">\1</span>' })},
Underline Links displays hyperlinks in navigation menus, the Dashboard, and page sidebars as
*underlined text*. This feature option does not apply to user-generated content links in the
Rich Content Editor, which always underlines links for all users.
END
applies_to: 'User',
state: 'allowed',
beta: true
},
'new_user_tutorial_on_off' =>
{
display_name: -> { I18n.t('Course Set-up Tutorial') },
description: -> { I18n.t('Course set-up tutorial provides tips on how to leverage the feature opportunities on each page in Canvas. It is especially useful when you are new to Canvas or are setting up a new course for the first time in a long time.') },
applies_to: 'User',
state: 'allowed',
},
'outcome_gradebook' =>
{
display_name: -> { I18n.t('features.learning_mastery_gradebook', 'Learning Mastery Gradebook') },
description: -> { I18n.t('learning_mastery_gradebook_description', <<-END) },
Learning Mastery Gradebook provides a way for teachers to quickly view student and course
progress on course learning outcomes. Outcomes are presented in a Gradebook-like
format and student progress is displayed both as a numerical score and as mastered/near
mastery/remedial.
END
applies_to: 'Course',
state: 'allowed',
root_opt_in: false
},
'student_outcome_gradebook' =>
{
display_name: -> { I18n.t('features.student_outcome_gradebook', 'Student Learning Mastery Gradebook') },
description: -> { I18n.t('student_outcome_gradebook_description', <<-END) },
Student Learning Mastery Gradebook provides a way for students to quickly view progress
on course learning outcomes. Outcomes are presented in a Gradebook-like
format and progress is displayed both as a numerical score and as mastered/near
mastery/remedial.
END
applies_to: 'Course',
state: 'allowed',
root_opt_in: false
},
'post_grades' =>
{
display_name: -> { I18n.t('features.post_grades', 'Post Grades to SIS') },
description: -> { I18n.t('post_grades_description', <<-END) },
Post Grades allows teachers to post grades back to enabled SIS systems: Powerschool,
Aspire (SIS2000), JMC, and any other SIF-enabled SIS that accepts the SIF elements GradingCategory,
GradingAssignment, GradingAssignmentScore.
END
applies_to: 'Course',
state: 'hidden',
root_opt_in: true,
beta: true
},
allow gradezilla to be default gradebook at a course level fixes CNVS-36920 fixes CNVS-36919 Rename the :gradezilla feature flag to :new_gradebook, with the following attributes display_name: t('New Gradebook') No longer display the "Gradezilla" code name in the UI or URLs Many internal code objects still keep gradezilla names for now applies_to: 'Course' The feature must be enabled at a course level to be used state: 'hidden' The feature flag is hidden and cannot be enabled until an Instructure site admin allows it root_opt_in: false Root account admins cannot turn the feature ON at once for all the courses they control beta: true The "beta: label is displayed next to the feature toggle element development: true The feature cannot be enabled in production. Beta is allowed admin_only: true Only site, account or subaccount admins can enable the feature for a course. Teachers cannot enable the feature. The admin_only attribute is new, added here as an experiment. It is false by default, and the code supporting it is kept as localized as possible in case it is later decided this functionality is not desired in Canvas version query parameter is now development-only Test Plan: 1. Before enabling "New Gradebook" feature as site admin a. non-INST admin does not see the flag at account level b. teacher does not see the feature flag at course level c. site admin sees it at account level, but can only choose "Off" or "Allow" d. site admin does not see the flag at course level 2. After enabling feature as site admin at account level a. non-INST admin can modify the flag at account level to "Off" or "Allow" but not to "On" b. non-INST admin can modify the flag at course level to "Off" or "On" c. teacher can see but not modify the flag at course level 3. After enabling feature as non-INST admin at course level a. "Gradezilla" is replaced with "New Gradebook" in both standard and individual views of the UI b. teacher sees "New Gradebook" feature as "On" 4. As Developer a. Use the version query parameter to override feature flag b. Use the version query parameter to override user preference Change-Id: I20a03832544a8e60d3b9b726694d3e88f01381fb Reviewed-on: https://gerrit.instructure.com/112457 Tested-by: Jenkins Reviewed-by: Derek Bender <djbender@instructure.com> Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com> QA-Review: KC Naegle <knaegle@instructure.com> Product-Review: Keith T. Garner <kgarner@instructure.com>
2017-05-19 23:52:29 +08:00
'new_gradebook' =>
{
display_name: -> { I18n.t('New Gradebook') },
description: -> { I18n.t(<<-END) },
New Gradebook enables an early release of new Gradebook enhancements.
END
applies_to: 'Course',
state: 'hidden',
root_opt_in: true,
beta: true,
development: true,
custom_transition_proc: ->(user, context, _from_state, transitions) do
if context.is_a?(Course)
user_may_change_flag = context.account.grants_right?(user, :manage_account_settings)
transitions['on']['locked'] = !user_may_change_flag if transitions&.dig('on')
transitions['off']['locked'] = !user_may_change_flag if transitions&.dig('off')
elsif context.is_a?(Account)
transitions['on']['locked'] = true if transitions&.dig('on')
end
end
},
'k12' =>
{
feature flag for 'All Grading Periods' totals Add grading period dropdowns on the 'grades' page, and add a "Display Totals for 'All Grading Periods'" feature flag. By default, the feature will be turned 'off'. When the feature is 'off': - Totals will not display in the gradebook or the 'student grades' page when the 'All Grading Periods' option is selected. - The grading period dropdowns on the 'grades' page will not have an 'All Grading Periods' option. When the feature is 'on': - Totals will display in the gradebook and the 'student grades' page when the 'All Grading Periods' option is selected. - The grading period dropdowns on the 'grades' page will have an 'All Grading Periods' option. closes CNVS-23995 test plan: 1) as a teacher, enable the 'multiple grading periods' feature (do not enable the 'display totals for all grading periods' feature yet). a) verify the gradebook does not show totals when the 'All Grading Periods' option is selected. b) verify the 'student grades page' (courses/4/grades/9#tab-assignments) does not show totals, and the calculation of 'what-if' grades is disabled when the 'All Grading Periods' option is selected. c) turn on the 'display totals for all grading periods' feature. repeat steps a & b and verify that the totals now show up (and you can calculate what-if grades on the student grades page when 'All Grading Periods is selected') 2) sign in as a student that is enrolled in 3 courses: 1 course with MGP disabled, 1 course with MGP enabled and 'display all grading periods totals' (DAGPT) disabled, and 1 course with MGP enabled and DAGPT enabled. go the the 'grades' page (/grades). a) verify there is a grading period dropdown next to the totals for courses that have MGP enabled. verify there is not a grading period dropdown next to the total for the course with MGP disabled. b) verify that the current grading period is selected by default, if one exists. if a current grading period does not exist, then: - the dropdown next to the total for the course with DAGPT disabled should show 'Select a grading period' and the total grade should show as '--'. - the dropdown next to the total for the course with DAGPT enabled should show 'All Grading Periods' and the total grade should be displayed. c) verify clicking a grading period in the dropdown changes the total, and shows the correct total for that grading period. 3) repeat steps 2a-c, but sign in as an observer that is observing at least 3 students in 3 different courses(1 course with MGP disabled, 1 with MGP enabled and DAGPT disabled, and 1 course with MGP enabled + DAGPT enabled). 4) verify that the grading period dropdowns that were added are accessible. Note: The 'grades' page (/grades) will _always_ display the total for 'All Grading Periods' when signed in as a teacher. We are aware of this existing bug and we're working on a solution. Change-Id: If501b47aa57121d17d4e6629d1dcdbc8676971a2 Reviewed-on: https://gerrit.instructure.com/65847 Tested-by: Jenkins Reviewed-by: Strand McCutchen <smccutchen@instructure.com> Reviewed-by: Dylan Ross <dross@instructure.com> Reviewed-by: Derek Bender <djbender@instructure.com> QA-Review: Jason Carter <jcarter@instructure.com> Product-Review: Spencer Olson <solson@instructure.com>
2015-10-14 03:20:03 +08:00
display_name: -> { I18n.t('features.k12', 'K-12 Specific Features') },
description: -> { I18n.t('k12_description', <<-END) },
Features, settings and styles that make more sense specifically in a K-12 environment. For now, this only
applies some style changes, but more K-12 specific things may be added in the future.
END
applies_to: 'RootAccount',
state: 'hidden',
root_opt_in: true,
beta: true
},
'recurring_calendar_events' =>
{
display_name: -> { I18n.t('Recurring Calendar Events') },
description: -> { I18n.t("Allows the scheduling of recurring calendar events") },
applies_to: 'Course',
state: 'hidden',
root_opt_in: true,
beta: true
},
'duplicate_objects' =>
{
display_name: -> { I18n.t('Duplicate Objects') },
description: -> { I18n.t("Allows the duplicating of objects in Canvas") },
applies_to: 'Account',
state: 'hidden',
root_opt_in: true,
beta: true
},
'allow_opt_out_of_inbox' =>
{
display_name: -> { I18n.t('features.allow_opt_out_of_inbox', "Allow Users to Opt-out of the Inbox") },
description: -> { I18n.t('allow_opt_out_of_inbox', <<-END) },
Allow users to opt out of the Conversation's Inbox. This will cause all conversation messages and notifications to be sent as ASAP notifications to the user's primary email, hide the Conversation's Inbox unread messages badge on the Inbox, and hide the Conversation's notification preferences.
END
applies_to: 'RootAccount',
state: 'hidden',
root_opt_in: true
},
'lor_for_user' =>
{
display_name: -> { I18n.t('features.lor', "LOR External Tools") },
description: -> { I18n.t('allow_lor_tools', <<-END) },
Allow users to view and use external tools configured for LOR.
END
applies_to: 'User',
state: 'hidden'
},
'lor_for_account' =>
{
display_name: -> { I18n.t('features.lor', "LOR External Tools") },
description: -> { I18n.t('allow_lor_tools', <<-END) },
Allow users to view and use external tools configured for LOR.
END
applies_to: 'RootAccount',
state: 'hidden'
},
'course_catalog' =>
{
display_name: -> { I18n.t("Public Course Index") },
description: -> { I18n.t('display_course_catalog', <<-END) },
Show a searchable list of courses in this root account with the "Include this course in the public course index" flag enabled.
END
applies_to: 'RootAccount',
state: 'allowed',
beta: true,
root_opt_in: true
add option to display students by sortable name in gradebook when the feature flag is turned on, student names will be displayed as their sortable name in the Gradebook. The default sortable name is 'Last, First' - so 99% of the time this change will flip the displayed names from 'First, Last' to 'Last, First' in the Gradebook (unless the sortable name has been explicitly changed in settings). test plan: 1. As a teacher, view the Gradebook for a course that has at least 2-3 students in it. 2. Notice the student names are displayed as 'First-Name Last-Name' 3. Go into the course's Settings --> Feature Options, and turn the 'Gradebook - List Students by Sortable Name' feature on. 4. Visit the Default Gradebook, and notice the student names are displayed as their sortable names (sortable name is "Last-Name, First-Name" by default) 5. Visit the Individual View Gradebook, and click the dropdown to select a student in the 'Content Selection' section. Notice the student names are displayed by their sortable names ('Last-Name, First-Name' by default). Note: In the Individual View Gradebook, in the 'Student Information' section, the student name will always appear as 'First-Name Last-Name'. I figured we would only want to show 'Last, First' when the name appears in a list. If we want to display the name as 'Last, First' in the 'Student Information' section when the feature is toggled on, I can certainly make that change. closes CNVS-8947 Change-Id: Ia3c6ae39b53d3762a8847445c90c9c16195bf336 Reviewed-on: https://gerrit.instructure.com/44121 Product-Review: Hilary Scharton <hilary@instructure.com> Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Josh Simpson <jsimpson@instructure.com> QA-Review: Amber Taniuchi <amber@instructure.com>
2014-11-08 03:22:03 +08:00
},
'gradebook_list_students_by_sortable_name' =>
{
display_name: -> { I18n.t('features.gradebook_list_students_by_sortable_name', "Gradebook - List Students by Sortable Name") },
description: -> { I18n.t('enable_gradebook_list_students_by_sortable_name', <<-END) },
List students by their sortable names in the Gradebook. Sortable name defaults to 'Last Name, First Name' and can be changed in settings.
END
applies_to: 'Course',
state: 'allowed'
},
'usage_rights_required' =>
{
display_name: -> { I18n.t('Require Usage Rights for Uploaded Files') },
description: -> { I18n.t('If enabled, content designers must provide copyright and license information for files before they are published. Only applies if Better File Browsing is also enabled.') },
applies_to: 'Course',
state: 'hidden',
root_opt_in: true
},
'lti2_rereg' =>
{
duplicate gradebook view hierarchy This patchset duplicates the gradebook view hierarchy so that we can develop gradebook enhancements side by side with the current gradebook. A feature flag has been created called "Gradezilla" (this name is for internal purposes only and should never be used in production) that is only allowed in development and defaults to on. With this feature flage enabled a button now appears next to the "individual view" button in gradebook to navigate to Gradezilla. The page also has a header of "Gradezilla" as to further distinguish the page since they look identical at the start of this project. In the future, we'll replace Gradezilla with something else but while in development we wanted an easy term to search for to know which part of the gradebook we were in. closes: CNVS-33684 Listed below are the paths for which a corresponding gradezilla file was created. See the git diff for full details. app/coffeescripts/bundles/gradebook.coffee app/coffeescripts/gradebook/*.coffee app/coffeescripts/views/gradebook/*.coffee app/jsx/gradebook/*.jsx app/stylesheets/bundles/gradebook.scss app/stylesheets/pages/gradebook/*.scss app/views/gradebooks/gradezilla.html.erb app/views/jst/gradebook/*.handlebars spec/coffeescripts/gradebook/*.coffee spec/coffeescripts/jsx/gradebook/*.coffee spec/javascripts/jsx/gradebook/*.jsx spec/selenium/grades/gradebook/*.rb spec/selenium/outcomes/outcome_gradebook_spec.rb spec/selenium/helpers/gradebook_common.rb spec/selenium/grades/page_objects/gradebook_page.rb spec/selenium/grades/setup/gradebook_setup.rb spec/views/gradebooks/gradebook.html.erb_spec.rb Test plan: - Ensure that the feature flag for Gradezilla is enabled - On the Gradebook page, there is now a button to take you to Gradezilla - Once selected, Gradezilla should become your default Gradebook until the "Gradebook" button is clicked. - Everything in Gradezilla should appear just as it does in Gradebook. - Having selected Gradezilla, disabled the feature flag - Ensure that upon returning to /gradebook, that the current Gradebook is selected - If the feature is disabled, you should not see the Gradezilla button. Change-Id: I6f1391a4264a8d0e6016a9a91f8055010f1c36d1 Reviewed-on: https://gerrit.instructure.com/98498 Tested-by: Jenkins Reviewed-by: Keith T. Garner <kgarner@instructure.com> Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com> QA-Review: KC Naegle <knaegle@instructure.com> Product-Review: Keith T. Garner <kgarner@instructure.com>
2016-12-19 22:38:49 +08:00
display_name: -> {I18n.t('LTI 2 Reregistration')},
description: -> { I18n.t('Enable reregistration for LTI 2 ')},
applies_to:'RootAccount',
state: 'hidden',
beta: true
},
'quizzes_lti' =>
duplicate gradebook view hierarchy This patchset duplicates the gradebook view hierarchy so that we can develop gradebook enhancements side by side with the current gradebook. A feature flag has been created called "Gradezilla" (this name is for internal purposes only and should never be used in production) that is only allowed in development and defaults to on. With this feature flage enabled a button now appears next to the "individual view" button in gradebook to navigate to Gradezilla. The page also has a header of "Gradezilla" as to further distinguish the page since they look identical at the start of this project. In the future, we'll replace Gradezilla with something else but while in development we wanted an easy term to search for to know which part of the gradebook we were in. closes: CNVS-33684 Listed below are the paths for which a corresponding gradezilla file was created. See the git diff for full details. app/coffeescripts/bundles/gradebook.coffee app/coffeescripts/gradebook/*.coffee app/coffeescripts/views/gradebook/*.coffee app/jsx/gradebook/*.jsx app/stylesheets/bundles/gradebook.scss app/stylesheets/pages/gradebook/*.scss app/views/gradebooks/gradezilla.html.erb app/views/jst/gradebook/*.handlebars spec/coffeescripts/gradebook/*.coffee spec/coffeescripts/jsx/gradebook/*.coffee spec/javascripts/jsx/gradebook/*.jsx spec/selenium/grades/gradebook/*.rb spec/selenium/outcomes/outcome_gradebook_spec.rb spec/selenium/helpers/gradebook_common.rb spec/selenium/grades/page_objects/gradebook_page.rb spec/selenium/grades/setup/gradebook_setup.rb spec/views/gradebooks/gradebook.html.erb_spec.rb Test plan: - Ensure that the feature flag for Gradezilla is enabled - On the Gradebook page, there is now a button to take you to Gradezilla - Once selected, Gradezilla should become your default Gradebook until the "Gradebook" button is clicked. - Everything in Gradezilla should appear just as it does in Gradebook. - Having selected Gradezilla, disabled the feature flag - Ensure that upon returning to /gradebook, that the current Gradebook is selected - If the feature is disabled, you should not see the Gradezilla button. Change-Id: I6f1391a4264a8d0e6016a9a91f8055010f1c36d1 Reviewed-on: https://gerrit.instructure.com/98498 Tested-by: Jenkins Reviewed-by: Keith T. Garner <kgarner@instructure.com> Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com> QA-Review: KC Naegle <knaegle@instructure.com> Product-Review: Keith T. Garner <kgarner@instructure.com>
2016-12-19 22:38:49 +08:00
{
display_name: -> { I18n.t('Quiz LTI Plugin') },
description: -> { I18n.t('Use the new quiz LTI tool in place of regular canvas quizzes') },
applies_to: 'Course',
state: 'hidden',
beta: true,
root_opt_in: true
},
'disable_lti_post_only' =>
duplicate gradebook view hierarchy This patchset duplicates the gradebook view hierarchy so that we can develop gradebook enhancements side by side with the current gradebook. A feature flag has been created called "Gradezilla" (this name is for internal purposes only and should never be used in production) that is only allowed in development and defaults to on. With this feature flage enabled a button now appears next to the "individual view" button in gradebook to navigate to Gradezilla. The page also has a header of "Gradezilla" as to further distinguish the page since they look identical at the start of this project. In the future, we'll replace Gradezilla with something else but while in development we wanted an easy term to search for to know which part of the gradebook we were in. closes: CNVS-33684 Listed below are the paths for which a corresponding gradezilla file was created. See the git diff for full details. app/coffeescripts/bundles/gradebook.coffee app/coffeescripts/gradebook/*.coffee app/coffeescripts/views/gradebook/*.coffee app/jsx/gradebook/*.jsx app/stylesheets/bundles/gradebook.scss app/stylesheets/pages/gradebook/*.scss app/views/gradebooks/gradezilla.html.erb app/views/jst/gradebook/*.handlebars spec/coffeescripts/gradebook/*.coffee spec/coffeescripts/jsx/gradebook/*.coffee spec/javascripts/jsx/gradebook/*.jsx spec/selenium/grades/gradebook/*.rb spec/selenium/outcomes/outcome_gradebook_spec.rb spec/selenium/helpers/gradebook_common.rb spec/selenium/grades/page_objects/gradebook_page.rb spec/selenium/grades/setup/gradebook_setup.rb spec/views/gradebooks/gradebook.html.erb_spec.rb Test plan: - Ensure that the feature flag for Gradezilla is enabled - On the Gradebook page, there is now a button to take you to Gradezilla - Once selected, Gradezilla should become your default Gradebook until the "Gradebook" button is clicked. - Everything in Gradezilla should appear just as it does in Gradebook. - Having selected Gradezilla, disabled the feature flag - Ensure that upon returning to /gradebook, that the current Gradebook is selected - If the feature is disabled, you should not see the Gradezilla button. Change-Id: I6f1391a4264a8d0e6016a9a91f8055010f1c36d1 Reviewed-on: https://gerrit.instructure.com/98498 Tested-by: Jenkins Reviewed-by: Keith T. Garner <kgarner@instructure.com> Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com> QA-Review: KC Naegle <knaegle@instructure.com> Product-Review: Keith T. Garner <kgarner@instructure.com>
2016-12-19 22:38:49 +08:00
{
display_name: -> { I18n.t('Don\'t Move LTI Query Params to POST Body') },
description: -> { I18n.t('If enabled, query parameters will not be copied to the POST body during an LTI launch.') },
applies_to: 'RootAccount',
state: 'hidden',
beta: true,
root_opt_in: true
},
'new_sis_integrations' =>
duplicate gradebook view hierarchy This patchset duplicates the gradebook view hierarchy so that we can develop gradebook enhancements side by side with the current gradebook. A feature flag has been created called "Gradezilla" (this name is for internal purposes only and should never be used in production) that is only allowed in development and defaults to on. With this feature flage enabled a button now appears next to the "individual view" button in gradebook to navigate to Gradezilla. The page also has a header of "Gradezilla" as to further distinguish the page since they look identical at the start of this project. In the future, we'll replace Gradezilla with something else but while in development we wanted an easy term to search for to know which part of the gradebook we were in. closes: CNVS-33684 Listed below are the paths for which a corresponding gradezilla file was created. See the git diff for full details. app/coffeescripts/bundles/gradebook.coffee app/coffeescripts/gradebook/*.coffee app/coffeescripts/views/gradebook/*.coffee app/jsx/gradebook/*.jsx app/stylesheets/bundles/gradebook.scss app/stylesheets/pages/gradebook/*.scss app/views/gradebooks/gradezilla.html.erb app/views/jst/gradebook/*.handlebars spec/coffeescripts/gradebook/*.coffee spec/coffeescripts/jsx/gradebook/*.coffee spec/javascripts/jsx/gradebook/*.jsx spec/selenium/grades/gradebook/*.rb spec/selenium/outcomes/outcome_gradebook_spec.rb spec/selenium/helpers/gradebook_common.rb spec/selenium/grades/page_objects/gradebook_page.rb spec/selenium/grades/setup/gradebook_setup.rb spec/views/gradebooks/gradebook.html.erb_spec.rb Test plan: - Ensure that the feature flag for Gradezilla is enabled - On the Gradebook page, there is now a button to take you to Gradezilla - Once selected, Gradezilla should become your default Gradebook until the "Gradebook" button is clicked. - Everything in Gradezilla should appear just as it does in Gradebook. - Having selected Gradezilla, disabled the feature flag - Ensure that upon returning to /gradebook, that the current Gradebook is selected - If the feature is disabled, you should not see the Gradezilla button. Change-Id: I6f1391a4264a8d0e6016a9a91f8055010f1c36d1 Reviewed-on: https://gerrit.instructure.com/98498 Tested-by: Jenkins Reviewed-by: Keith T. Garner <kgarner@instructure.com> Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com> QA-Review: KC Naegle <knaegle@instructure.com> Product-Review: Keith T. Garner <kgarner@instructure.com>
2016-12-19 22:38:49 +08:00
{
display_name: -> { I18n.t('Enable new SIS integration settings') },
description: -> { I18n.t('Make new settings for SIS integrations visible and active') },
applies_to: 'Account',
state: 'hidden',
root_opt_in: true,
beta: true
duplicate gradebook view hierarchy This patchset duplicates the gradebook view hierarchy so that we can develop gradebook enhancements side by side with the current gradebook. A feature flag has been created called "Gradezilla" (this name is for internal purposes only and should never be used in production) that is only allowed in development and defaults to on. With this feature flage enabled a button now appears next to the "individual view" button in gradebook to navigate to Gradezilla. The page also has a header of "Gradezilla" as to further distinguish the page since they look identical at the start of this project. In the future, we'll replace Gradezilla with something else but while in development we wanted an easy term to search for to know which part of the gradebook we were in. closes: CNVS-33684 Listed below are the paths for which a corresponding gradezilla file was created. See the git diff for full details. app/coffeescripts/bundles/gradebook.coffee app/coffeescripts/gradebook/*.coffee app/coffeescripts/views/gradebook/*.coffee app/jsx/gradebook/*.jsx app/stylesheets/bundles/gradebook.scss app/stylesheets/pages/gradebook/*.scss app/views/gradebooks/gradezilla.html.erb app/views/jst/gradebook/*.handlebars spec/coffeescripts/gradebook/*.coffee spec/coffeescripts/jsx/gradebook/*.coffee spec/javascripts/jsx/gradebook/*.jsx spec/selenium/grades/gradebook/*.rb spec/selenium/outcomes/outcome_gradebook_spec.rb spec/selenium/helpers/gradebook_common.rb spec/selenium/grades/page_objects/gradebook_page.rb spec/selenium/grades/setup/gradebook_setup.rb spec/views/gradebooks/gradebook.html.erb_spec.rb Test plan: - Ensure that the feature flag for Gradezilla is enabled - On the Gradebook page, there is now a button to take you to Gradezilla - Once selected, Gradezilla should become your default Gradebook until the "Gradebook" button is clicked. - Everything in Gradezilla should appear just as it does in Gradebook. - Having selected Gradezilla, disabled the feature flag - Ensure that upon returning to /gradebook, that the current Gradebook is selected - If the feature is disabled, you should not see the Gradezilla button. Change-Id: I6f1391a4264a8d0e6016a9a91f8055010f1c36d1 Reviewed-on: https://gerrit.instructure.com/98498 Tested-by: Jenkins Reviewed-by: Keith T. Garner <kgarner@instructure.com> Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com> QA-Review: KC Naegle <knaegle@instructure.com> Product-Review: Keith T. Garner <kgarner@instructure.com>
2016-12-19 22:38:49 +08:00
},
'bulk_sis_grade_export' =>
{
display_name: -> { I18n.t('Allow Bulk Grade Export to SIS') },
description: -> { I18n.t('Allows teachers to mark grade data to be exported in bulk to SIS integrations.') },
applies_to: 'RootAccount',
state: 'hidden',
root_opt_in: true,
beta: true
},
'notification_service' =>
{
display_name: -> { I18n.t('Use remote service for notifications') },
description: -> { I18n.t('Allow the ability to send notifications through our dispatch queue') },
applies_to: 'RootAccount',
state: 'hidden',
beta: true,
development: false,
root_opt_in: false
},
'better_scheduler' =>
{
display_name: -> { I18n.t('Use the new scheduler') },
description: -> { I18n.t('Uses the new scheduler and its functionality') },
applies_to: 'RootAccount',
state: 'hidden',
beta: true,
development: false,
root_opt_in: false
},
'use_new_tree' =>
{
feature flag for 'All Grading Periods' totals Add grading period dropdowns on the 'grades' page, and add a "Display Totals for 'All Grading Periods'" feature flag. By default, the feature will be turned 'off'. When the feature is 'off': - Totals will not display in the gradebook or the 'student grades' page when the 'All Grading Periods' option is selected. - The grading period dropdowns on the 'grades' page will not have an 'All Grading Periods' option. When the feature is 'on': - Totals will display in the gradebook and the 'student grades' page when the 'All Grading Periods' option is selected. - The grading period dropdowns on the 'grades' page will have an 'All Grading Periods' option. closes CNVS-23995 test plan: 1) as a teacher, enable the 'multiple grading periods' feature (do not enable the 'display totals for all grading periods' feature yet). a) verify the gradebook does not show totals when the 'All Grading Periods' option is selected. b) verify the 'student grades page' (courses/4/grades/9#tab-assignments) does not show totals, and the calculation of 'what-if' grades is disabled when the 'All Grading Periods' option is selected. c) turn on the 'display totals for all grading periods' feature. repeat steps a & b and verify that the totals now show up (and you can calculate what-if grades on the student grades page when 'All Grading Periods is selected') 2) sign in as a student that is enrolled in 3 courses: 1 course with MGP disabled, 1 course with MGP enabled and 'display all grading periods totals' (DAGPT) disabled, and 1 course with MGP enabled and DAGPT enabled. go the the 'grades' page (/grades). a) verify there is a grading period dropdown next to the totals for courses that have MGP enabled. verify there is not a grading period dropdown next to the total for the course with MGP disabled. b) verify that the current grading period is selected by default, if one exists. if a current grading period does not exist, then: - the dropdown next to the total for the course with DAGPT disabled should show 'Select a grading period' and the total grade should show as '--'. - the dropdown next to the total for the course with DAGPT enabled should show 'All Grading Periods' and the total grade should be displayed. c) verify clicking a grading period in the dropdown changes the total, and shows the correct total for that grading period. 3) repeat steps 2a-c, but sign in as an observer that is observing at least 3 students in 3 different courses(1 course with MGP disabled, 1 with MGP enabled and DAGPT disabled, and 1 course with MGP enabled + DAGPT enabled). 4) verify that the grading period dropdowns that were added are accessible. Note: The 'grades' page (/grades) will _always_ display the total for 'All Grading Periods' when signed in as a teacher. We are aware of this existing bug and we're working on a solution. Change-Id: If501b47aa57121d17d4e6629d1dcdbc8676971a2 Reviewed-on: https://gerrit.instructure.com/65847 Tested-by: Jenkins Reviewed-by: Strand McCutchen <smccutchen@instructure.com> Reviewed-by: Dylan Ross <dross@instructure.com> Reviewed-by: Derek Bender <djbender@instructure.com> QA-Review: Jason Carter <jcarter@instructure.com> Product-Review: Spencer Olson <solson@instructure.com>
2015-10-14 03:20:03 +08:00
display_name: -> { I18n.t('Use New Folder Tree in Files')},
description: -> {I18n.t('Replaces the current folder tree with a new accessible and more feature rich folder tree.')},
applies_to: 'Course',
state: 'hidden',
development: true,
root_opt_in: true
},
'course_card_images' =>
{
display_name: -> { I18n.t('Enable Dashboard Images for Courses')},
description: -> {I18n.t('Allow course images to be assigned to a course and used on the dashboard cards.')},
applies_to: 'Course',
state: 'allowed',
root_opt_in: true,
beta: true
},
'dashcard_reordering' =>
{
display_name: -> { I18n.t('Allow Reorder Dashboard Cards') },
description: -> { I18n.t('Allow dashboard cards to be reordered for each user.') },
applies_to: 'RootAccount',
state: 'hidden',
beta: true,
development: true,
root_opt_in: false
},
'anonymous_grading' => {
display_name: -> { I18n.t('Anonymous Grading') },
description: -> { I18n.t("Anonymous grading forces student names to be hidden in SpeedGrader™") },
applies_to: 'Course',
state: 'allowed'
},
Allow entry of international phone numbers Fixes CNVS-20605 Test plan: - Enable the international SMS feature flag - You can do this from a console with this, assuming your root account's id is 1: Account.find(1).enable_feature!(:international_sms) - As a test user, pull up your settings page - Under "Other Contacts", click "Add Contact Method" - Verify that you see two fields, "Country" and "Cell Number" - Verify that the country names and country codes presented in the "Country" dropdown are as given in the AC of CNVS-20605 - Click "Reigster SMS" and verify you get a popup saying that "Country is required" - Select "Belgium (+32)" from the dropdown - Verify that no extra fields show up - Click "Register SMS" and verify that you get a popup saying that "Cell Number is required" - Enter "12345", then click "Register SMS" - Ensure that a box pops up saying that "We sent a four-character confirmation code to +3212345". - Close the dialog, then click "Add Contact Method" again - This time, select "United States (+1)" - Regression test this part of the dialog - it should work as it always has - Regression test adding email addresses via the "Email" tab as well - Disable the international SMS feature flag - You can do this with: Account.find(1).disable_feature!(:international_sms) - Regression test both adding email addresses and adding phone numbers and verify that they work as they did before, with no mention of the ability to select different countries Change-Id: I83982d1ee1fc3e22dced29fd28a714333e531899 Reviewed-on: https://gerrit.instructure.com/59811 Reviewed-by: Joel Hough <joel@instructure.com> Reviewed-by: Steven Burnett <sburnett@instructure.com> Tested-by: Jenkins QA-Review: Heath Hales <hhales@instructure.com> Product-Review: Matthew Wheeler <mwheeler@instructure.com>
2015-08-03 12:36:39 +08:00
'international_sms' => {
display_name: -> { I18n.t('International SMS') },
description: -> { I18n.t('Allows users with international phone numbers to receive text messages from Canvas.') },
applies_to: 'RootAccount',
state: 'hidden',
root_opt_in: true
feature flag for 'All Grading Periods' totals Add grading period dropdowns on the 'grades' page, and add a "Display Totals for 'All Grading Periods'" feature flag. By default, the feature will be turned 'off'. When the feature is 'off': - Totals will not display in the gradebook or the 'student grades' page when the 'All Grading Periods' option is selected. - The grading period dropdowns on the 'grades' page will not have an 'All Grading Periods' option. When the feature is 'on': - Totals will display in the gradebook and the 'student grades' page when the 'All Grading Periods' option is selected. - The grading period dropdowns on the 'grades' page will have an 'All Grading Periods' option. closes CNVS-23995 test plan: 1) as a teacher, enable the 'multiple grading periods' feature (do not enable the 'display totals for all grading periods' feature yet). a) verify the gradebook does not show totals when the 'All Grading Periods' option is selected. b) verify the 'student grades page' (courses/4/grades/9#tab-assignments) does not show totals, and the calculation of 'what-if' grades is disabled when the 'All Grading Periods' option is selected. c) turn on the 'display totals for all grading periods' feature. repeat steps a & b and verify that the totals now show up (and you can calculate what-if grades on the student grades page when 'All Grading Periods is selected') 2) sign in as a student that is enrolled in 3 courses: 1 course with MGP disabled, 1 course with MGP enabled and 'display all grading periods totals' (DAGPT) disabled, and 1 course with MGP enabled and DAGPT enabled. go the the 'grades' page (/grades). a) verify there is a grading period dropdown next to the totals for courses that have MGP enabled. verify there is not a grading period dropdown next to the total for the course with MGP disabled. b) verify that the current grading period is selected by default, if one exists. if a current grading period does not exist, then: - the dropdown next to the total for the course with DAGPT disabled should show 'Select a grading period' and the total grade should show as '--'. - the dropdown next to the total for the course with DAGPT enabled should show 'All Grading Periods' and the total grade should be displayed. c) verify clicking a grading period in the dropdown changes the total, and shows the correct total for that grading period. 3) repeat steps 2a-c, but sign in as an observer that is observing at least 3 students in 3 different courses(1 course with MGP disabled, 1 with MGP enabled and DAGPT disabled, and 1 course with MGP enabled + DAGPT enabled). 4) verify that the grading period dropdowns that were added are accessible. Note: The 'grades' page (/grades) will _always_ display the total for 'All Grading Periods' when signed in as a teacher. We are aware of this existing bug and we're working on a solution. Change-Id: If501b47aa57121d17d4e6629d1dcdbc8676971a2 Reviewed-on: https://gerrit.instructure.com/65847 Tested-by: Jenkins Reviewed-by: Strand McCutchen <smccutchen@instructure.com> Reviewed-by: Dylan Ross <dross@instructure.com> Reviewed-by: Derek Bender <djbender@instructure.com> QA-Review: Jason Carter <jcarter@instructure.com> Product-Review: Spencer Olson <solson@instructure.com>
2015-10-14 03:20:03 +08:00
},
'course_user_search' => {
display_name: -> { I18n.t('Account Course and User Search') },
description: -> { I18n.t('Updated UI for searching and displaying users and courses within an account.') },
applies_to: 'Account',
state: 'hidden',
beta: true,
development: true,
root_opt_in: true,
touch_context: true
},
'rich_content_service' =>
{
display_name: -> { I18n.t('Use remote version of Rich Content Editor') },
description: -> { I18n.t('In cases where it is available, load the RCE from a canvas rich content service') },
applies_to: 'RootAccount',
state: 'allowed',
beta: true,
development: false,
root_opt_in: false
},
'rich_content_service_with_sidebar' =>
{
display_name: -> { I18n.t('Use remote version of Rich Content Editor AND sidebar') },
description: -> { I18n.t('In cases where it is available, load the RCE and the wiki sidebar from a canvas rich content service') },
applies_to: 'RootAccount',
state: 'hidden',
beta: true,
development: false,
root_opt_in: false
},
'rich_content_service_high_risk' =>
{
display_name: -> { I18n.t('Use remote version of Rich Content Editor AND sidebar in high-risk areas like quizzes') },
description: -> { I18n.t('Always load the RCE and Sidebar from a canvas rich content service everywhere') },
applies_to: 'RootAccount',
state: 'hidden',
beta: true,
development: false,
root_opt_in: false
},
'conditional_release' =>
{
display_name: -> { I18n.t('Mastery Paths') },
description: -> { I18n.t('Configure individual learning paths for students based on assessment results.') },
applies_to: 'Course',
state: 'allowed',
beta: true,
development: false,
root_opt_in: true,
after_state_change_proc: ->(user, context, _old_state, new_state) {
if %w(on allowed).include?(new_state) && context.is_a?(Account)
@service_account = ConditionalRelease::Setup.new(context.id, user.id)
@service_account.activate!
end
}
},
'wrap_calendar_event_titles' =>
{
display_name: -> { I18n.t('Wrap event titles in Calendar month view') },
description: -> { I18n.t("Show calendar events in the month view on multiple lines if the title doesn't fit on a single line") },
applies_to: 'RootAccount',
state: 'allowed',
root_opt_in: true
},
'new_collaborations' =>
{
display_name: -> { I18n.t("External Collaborations Tool") },
description: -> { I18n.t("Use the new Collaborations external tool enabling more options for tools to use to collaborate") },
applies_to: 'Course',
state: 'hidden',
development: false,
root_opt_in: true,
touch_context: true
Add feature flag for canvadocs preferred plugin When the new canvadocs annotation stuff is ready, we want to be able to selectively turn it on to slowly roll it out. This adds a feature flag to the course that allows the new annotations to be enabled by course. There is also an account-level flag that allows the feature to be turned off globally per account, turned on, or simply "allowed" which delegates to the course. Refs CNVS-26668 Test Plan: - Open up the account settings and observe that there is a feature flag called 'New Annotations' - See that the feature flag can be either Off, Allowed, or On - Inside a course belonging to the account, see that there is a feature flag for New Annotations that can be toggled on/off when the account level setting is 'Allowed', or is Off when the account is off or On when the account is on. If you have rails console access: - Submit an attachment to an assignment in the course with the new annotations flag turned off - Observe that the preferred_plugin on the associated Canvadoc object is 'nil' - canvadoc_obj = Canvadoc.last # or whatever - # send has to be used cause #preferred_plugin is a private - # method. Returns nil or 'pdfjs' - canvadoc_obj.send(:preferred_plugin) - Turn the feature flag on for the course (either through the course settings or through the account) - you should not need to resubmit, and shoudl see that the preferred_plugin gets set to 'pdfjs'. It should toggle from pdfjs to nil and back when turning the feature flag on and off, whether at the account level or the course level Change-Id: I6dd70fa2b379d527315dd7e14ee6ff8cceda024e Reviewed-on: https://gerrit.instructure.com/84956 Tested-by: Jenkins QA-Review: Caleb Guanzon <cguanzon@instructure.com> Reviewed-by: Spencer Olson <solson@instructure.com> Reviewed-by: Keith T. Garner <kgarner@instructure.com> Product-Review: Benjamin Porter <bporter@instructure.com>
2016-07-07 02:44:45 +08:00
},
'new_annotations' =>
{
display_name: -> { I18n.t('New Annotations') },
description: -> { I18n.t('Use the new document annotation tool') },
applies_to: 'Account',
state: 'hidden',
Add feature flag for canvadocs preferred plugin When the new canvadocs annotation stuff is ready, we want to be able to selectively turn it on to slowly roll it out. This adds a feature flag to the course that allows the new annotations to be enabled by course. There is also an account-level flag that allows the feature to be turned off globally per account, turned on, or simply "allowed" which delegates to the course. Refs CNVS-26668 Test Plan: - Open up the account settings and observe that there is a feature flag called 'New Annotations' - See that the feature flag can be either Off, Allowed, or On - Inside a course belonging to the account, see that there is a feature flag for New Annotations that can be toggled on/off when the account level setting is 'Allowed', or is Off when the account is off or On when the account is on. If you have rails console access: - Submit an attachment to an assignment in the course with the new annotations flag turned off - Observe that the preferred_plugin on the associated Canvadoc object is 'nil' - canvadoc_obj = Canvadoc.last # or whatever - # send has to be used cause #preferred_plugin is a private - # method. Returns nil or 'pdfjs' - canvadoc_obj.send(:preferred_plugin) - Turn the feature flag on for the course (either through the course settings or through the account) - you should not need to resubmit, and shoudl see that the preferred_plugin gets set to 'pdfjs'. It should toggle from pdfjs to nil and back when turning the feature flag on and off, whether at the account level or the course level Change-Id: I6dd70fa2b379d527315dd7e14ee6ff8cceda024e Reviewed-on: https://gerrit.instructure.com/84956 Tested-by: Jenkins QA-Review: Caleb Guanzon <cguanzon@instructure.com> Reviewed-by: Spencer Olson <solson@instructure.com> Reviewed-by: Keith T. Garner <kgarner@instructure.com> Product-Review: Benjamin Porter <bporter@instructure.com>
2016-07-07 02:44:45 +08:00
beta: true,
root_opt_in: true
},
'plagiarism_detection_platform' =>
{
display_name: -> { I18n.t('Plagiarism Detection Platform') },
description: -> { I18n.t('Enable the plagiarism detection platform') },
applies_to: 'RootAccount',
state: 'hidden',
beta: true,
root_opt_in: true
},
'master_courses' =>
{
display_name: -> { I18n.t('Blueprint Courses') }, # this won't be confusing at all
description: -> { I18n.t('Enable the creation of Blueprint Courses') },
applies_to: 'RootAccount',
state: 'hidden',
beta: true,
},
duplicate gradebook view hierarchy This patchset duplicates the gradebook view hierarchy so that we can develop gradebook enhancements side by side with the current gradebook. A feature flag has been created called "Gradezilla" (this name is for internal purposes only and should never be used in production) that is only allowed in development and defaults to on. With this feature flage enabled a button now appears next to the "individual view" button in gradebook to navigate to Gradezilla. The page also has a header of "Gradezilla" as to further distinguish the page since they look identical at the start of this project. In the future, we'll replace Gradezilla with something else but while in development we wanted an easy term to search for to know which part of the gradebook we were in. closes: CNVS-33684 Listed below are the paths for which a corresponding gradezilla file was created. See the git diff for full details. app/coffeescripts/bundles/gradebook.coffee app/coffeescripts/gradebook/*.coffee app/coffeescripts/views/gradebook/*.coffee app/jsx/gradebook/*.jsx app/stylesheets/bundles/gradebook.scss app/stylesheets/pages/gradebook/*.scss app/views/gradebooks/gradezilla.html.erb app/views/jst/gradebook/*.handlebars spec/coffeescripts/gradebook/*.coffee spec/coffeescripts/jsx/gradebook/*.coffee spec/javascripts/jsx/gradebook/*.jsx spec/selenium/grades/gradebook/*.rb spec/selenium/outcomes/outcome_gradebook_spec.rb spec/selenium/helpers/gradebook_common.rb spec/selenium/grades/page_objects/gradebook_page.rb spec/selenium/grades/setup/gradebook_setup.rb spec/views/gradebooks/gradebook.html.erb_spec.rb Test plan: - Ensure that the feature flag for Gradezilla is enabled - On the Gradebook page, there is now a button to take you to Gradezilla - Once selected, Gradezilla should become your default Gradebook until the "Gradebook" button is clicked. - Everything in Gradezilla should appear just as it does in Gradebook. - Having selected Gradezilla, disabled the feature flag - Ensure that upon returning to /gradebook, that the current Gradebook is selected - If the feature is disabled, you should not see the Gradezilla button. Change-Id: I6f1391a4264a8d0e6016a9a91f8055010f1c36d1 Reviewed-on: https://gerrit.instructure.com/98498 Tested-by: Jenkins Reviewed-by: Keith T. Garner <kgarner@instructure.com> Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com> QA-Review: KC Naegle <knaegle@instructure.com> Product-Review: Keith T. Garner <kgarner@instructure.com>
2016-12-19 22:38:49 +08:00
'student_context_cards' =>
{
display_name: -> { I18n.t('Student Context Card') },
description: -> { I18n.t('Enable student context card links') },
applies_to: "RootAccount",
state: "allowed",
beta: true
duplicate gradebook view hierarchy This patchset duplicates the gradebook view hierarchy so that we can develop gradebook enhancements side by side with the current gradebook. A feature flag has been created called "Gradezilla" (this name is for internal purposes only and should never be used in production) that is only allowed in development and defaults to on. With this feature flage enabled a button now appears next to the "individual view" button in gradebook to navigate to Gradezilla. The page also has a header of "Gradezilla" as to further distinguish the page since they look identical at the start of this project. In the future, we'll replace Gradezilla with something else but while in development we wanted an easy term to search for to know which part of the gradebook we were in. closes: CNVS-33684 Listed below are the paths for which a corresponding gradezilla file was created. See the git diff for full details. app/coffeescripts/bundles/gradebook.coffee app/coffeescripts/gradebook/*.coffee app/coffeescripts/views/gradebook/*.coffee app/jsx/gradebook/*.jsx app/stylesheets/bundles/gradebook.scss app/stylesheets/pages/gradebook/*.scss app/views/gradebooks/gradezilla.html.erb app/views/jst/gradebook/*.handlebars spec/coffeescripts/gradebook/*.coffee spec/coffeescripts/jsx/gradebook/*.coffee spec/javascripts/jsx/gradebook/*.jsx spec/selenium/grades/gradebook/*.rb spec/selenium/outcomes/outcome_gradebook_spec.rb spec/selenium/helpers/gradebook_common.rb spec/selenium/grades/page_objects/gradebook_page.rb spec/selenium/grades/setup/gradebook_setup.rb spec/views/gradebooks/gradebook.html.erb_spec.rb Test plan: - Ensure that the feature flag for Gradezilla is enabled - On the Gradebook page, there is now a button to take you to Gradezilla - Once selected, Gradezilla should become your default Gradebook until the "Gradebook" button is clicked. - Everything in Gradezilla should appear just as it does in Gradebook. - Having selected Gradezilla, disabled the feature flag - Ensure that upon returning to /gradebook, that the current Gradebook is selected - If the feature is disabled, you should not see the Gradezilla button. Change-Id: I6f1391a4264a8d0e6016a9a91f8055010f1c36d1 Reviewed-on: https://gerrit.instructure.com/98498 Tested-by: Jenkins Reviewed-by: Keith T. Garner <kgarner@instructure.com> Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com> QA-Review: KC Naegle <knaegle@instructure.com> Product-Review: Keith T. Garner <kgarner@instructure.com>
2016-12-19 22:38:49 +08:00
},
'new_gradebook_history' =>
{
display_name: -> { I18n.t('New Gradebook History') },
description: -> { I18n.t('Enable New Gradebook History page.') },
applies_to: "RootAccount",
state: "hidden",
beta: true,
development: true,
},
'modules_home_page' =>
{
display_name: -> { I18n.t('Modules Home Page') },
description: -> { I18n.t('Default to modules for the course home page') },
applies_to: "RootAccount",
state: "allowed",
},
'new_user_tutorial' =>
{
display_name: -> { I18n.t('New User Tutorial')},
description: -> { I18n.t('Provide tutorial information for new users in a flyout tray.')},
applies_to: "RootAccount",
state: "allowed",
},
'student_planner' =>
{
display_name: -> { I18n.t('Student Planner')},
description: -> { I18n.t('Provides users with a planner dashboard option.')},
applies_to: "RootAccount",
state: "hidden",
beta: true,
development: true
},
'quizzes2_exporter' =>
{
display_name: -> { I18n.t('Export to Quizzes 2 format') },
description: -> { I18n.t('Export an existing quiz to new Quizzes 2 format') },
applies_to: "RootAccount",
state: "hidden",
beta: false,
development: true,
},
'lti_2_auth_url_registration' =>
{
display_name: -> { I18n.t('Send Authorization URL in LTI2 Registration') },
description: -> { I18n.t("If enabled, 'oauth2_access_token_url' will be sent in LTI2 registration launch") },
applies_to: 'RootAccount',
state: 'hidden',
beta: false,
root_opt_in: true
},
'graphql' =>
{
display_name: -> { I18n.t("GraphQL API") },
description: -> { I18n.t("EXPERIMENTAL GraphQL API.") },
applies_to: "RootAccount",
state: "hidden",
beta: true,
development: true,
},
)
feature flags infrastructure and API test plan: - install the test_features plugin (since no real features exist yet) - render and consult the feature flags documentation - have a test environment with a root account, sub-account, course in sub-account, and user - Use the "list features" endpoint as a root account admin (with no site admin privileges), on the root account context, and confirm that hidden features do not show up - Use the "list features" endpoint as a site admin user, on the root account context, and confirm that hidden features show up - Use the "list features" endpoint on the site admin account and confirm the hidden features show up - Use the "set feature flag" endpoint on a hidden feature on site admin and ensure the feature becomes visible in all root accounts - Use the "set feature flag endpoint" on a hidden feature on a single root account, and ensure the feature becomes visible to that root account and not others - Confirm that root_opt_in features appear "Off" by default in root accounts, after being "Allowed" in code or site admin - Confirm a feature flag that is set to "on" or "off" (vs. "allowed") cannot be overridden in a lower context (and the API returns locked=true for them) - Confirm that setting locking_account_id requires admin rights in the locking account - Confirm that a feature flag with locking_account_id cannot be changed without admin rights in the locking account (e.g., set a feature flag on a course, locked with the root account's id, and make sure a teacher who is not an account admin can't change it) - Confirm feature flags can be deleted with the "remove feature flag" endpoint (and they are only deleted where they are defined, not when called on an object that inherits a flag) Change-Id: I3e12e23b4454889b6e8b263f1315e82d8f2ada52 Reviewed-on: https://gerrit.instructure.com/25502 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Matt Fairbourn <mfairbourn@instructure.com> Product-Review: Matt Goodwin <mattg@instructure.com> Reviewed-by: Zach Pendleton <zachp@instructure.com>
2013-10-22 23:28:26 +08:00
def self.definitions
@features ||= {}
@features.freeze unless @features.frozen?
@features
end
def applies_to_object(object)
case @applies_to
duplicate gradebook view hierarchy This patchset duplicates the gradebook view hierarchy so that we can develop gradebook enhancements side by side with the current gradebook. A feature flag has been created called "Gradezilla" (this name is for internal purposes only and should never be used in production) that is only allowed in development and defaults to on. With this feature flage enabled a button now appears next to the "individual view" button in gradebook to navigate to Gradezilla. The page also has a header of "Gradezilla" as to further distinguish the page since they look identical at the start of this project. In the future, we'll replace Gradezilla with something else but while in development we wanted an easy term to search for to know which part of the gradebook we were in. closes: CNVS-33684 Listed below are the paths for which a corresponding gradezilla file was created. See the git diff for full details. app/coffeescripts/bundles/gradebook.coffee app/coffeescripts/gradebook/*.coffee app/coffeescripts/views/gradebook/*.coffee app/jsx/gradebook/*.jsx app/stylesheets/bundles/gradebook.scss app/stylesheets/pages/gradebook/*.scss app/views/gradebooks/gradezilla.html.erb app/views/jst/gradebook/*.handlebars spec/coffeescripts/gradebook/*.coffee spec/coffeescripts/jsx/gradebook/*.coffee spec/javascripts/jsx/gradebook/*.jsx spec/selenium/grades/gradebook/*.rb spec/selenium/outcomes/outcome_gradebook_spec.rb spec/selenium/helpers/gradebook_common.rb spec/selenium/grades/page_objects/gradebook_page.rb spec/selenium/grades/setup/gradebook_setup.rb spec/views/gradebooks/gradebook.html.erb_spec.rb Test plan: - Ensure that the feature flag for Gradezilla is enabled - On the Gradebook page, there is now a button to take you to Gradezilla - Once selected, Gradezilla should become your default Gradebook until the "Gradebook" button is clicked. - Everything in Gradezilla should appear just as it does in Gradebook. - Having selected Gradezilla, disabled the feature flag - Ensure that upon returning to /gradebook, that the current Gradebook is selected - If the feature is disabled, you should not see the Gradezilla button. Change-Id: I6f1391a4264a8d0e6016a9a91f8055010f1c36d1 Reviewed-on: https://gerrit.instructure.com/98498 Tested-by: Jenkins Reviewed-by: Keith T. Garner <kgarner@instructure.com> Reviewed-by: Shahbaz Javeed <sjaveed@instructure.com> QA-Review: KC Naegle <knaegle@instructure.com> Product-Review: Keith T. Garner <kgarner@instructure.com>
2016-12-19 22:38:49 +08:00
when 'RootAccount'
object.is_a?(Account) && object.root_account?
when 'Account'
object.is_a?(Account)
when 'Course'
object.is_a?(Course) || object.is_a?(Account)
when 'User'
object.is_a?(User) || object.is_a?(Account) && object.site_admin?
else
false
feature flags infrastructure and API test plan: - install the test_features plugin (since no real features exist yet) - render and consult the feature flags documentation - have a test environment with a root account, sub-account, course in sub-account, and user - Use the "list features" endpoint as a root account admin (with no site admin privileges), on the root account context, and confirm that hidden features do not show up - Use the "list features" endpoint as a site admin user, on the root account context, and confirm that hidden features show up - Use the "list features" endpoint on the site admin account and confirm the hidden features show up - Use the "set feature flag" endpoint on a hidden feature on site admin and ensure the feature becomes visible in all root accounts - Use the "set feature flag endpoint" on a hidden feature on a single root account, and ensure the feature becomes visible to that root account and not others - Confirm that root_opt_in features appear "Off" by default in root accounts, after being "Allowed" in code or site admin - Confirm a feature flag that is set to "on" or "off" (vs. "allowed") cannot be overridden in a lower context (and the API returns locked=true for them) - Confirm that setting locking_account_id requires admin rights in the locking account - Confirm that a feature flag with locking_account_id cannot be changed without admin rights in the locking account (e.g., set a feature flag on a course, locked with the root account's id, and make sure a teacher who is not an account admin can't change it) - Confirm feature flags can be deleted with the "remove feature flag" endpoint (and they are only deleted where they are defined, not when called on an object that inherits a flag) Change-Id: I3e12e23b4454889b6e8b263f1315e82d8f2ada52 Reviewed-on: https://gerrit.instructure.com/25502 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Matt Fairbourn <mfairbourn@instructure.com> Product-Review: Matt Goodwin <mattg@instructure.com> Reviewed-by: Zach Pendleton <zachp@instructure.com>
2013-10-22 23:28:26 +08:00
end
end
def self.feature_applies_to_object(feature, object)
feature_def = definitions[feature.to_s]
return false unless feature_def
feature_def.applies_to_object(object)
end
def self.applicable_features(object)
applicable_types = []
if object.is_a?(Account)
applicable_types << 'Account'
applicable_types << 'Course'
applicable_types << 'RootAccount' if object.root_account?
applicable_types << 'User' if object.site_admin?
elsif object.is_a?(Course)
applicable_types << 'Course'
elsif object.is_a?(User)
applicable_types << 'User'
end
definitions.values.select{ |fd| applicable_types.include?(fd.applies_to) }
end
remove "Allowed" state for RootAccount features on root accounts the "Allowed" state means a feature is off in an account, but sub-accounts or courses below it are allowed to enable it. the 'allowed' state does not, however, make a lot of sense for features that apply to RootAccount. since the feature cannot be controlled in sub-accounts or courses, the 'allowed' state is equivalent to 'off' here. so to make this less confusing, remove the "allowed" state for RootAccount features. (specifically, lock the transition in the API, and make the UI hide buttons for locked transitions that don't have messages to display when the user tries to perform them) test plan: - set the Use New Styles feature to "Allowed" in Site Admin account settings - in a root account settings page, ensure the 'Allowed' option is not selectable for this feature - ensure that the API reports the new_styles feature is "off" and its "allowed" transition is locked i.e., GET /api/v1/accounts/1/features/flags/new_styles includes state: 'off' and transitions: {allowed: {locked: true}} - ensure the API refuses to set the new_styles feature to "allowed" in the root account i.e., PUT /api/v1/accounts/1/features/flags/new_styles?state=allowed should return a 403 error and not change the state - regression test: in a sub-account, ensure the 'Use New Styles' feature does not appear - regression test: verify that when a (non-site-admin) root account admin attempts to disable Draft State in an account, the Off button is still there, and a message appears when you click it, and the feature remains enabled fixes CNVS-13220 Change-Id: I4d41076c10696b02d0c482a778d2555714487f17 Reviewed-on: https://gerrit.instructure.com/35473 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Bracken Mosbacker <bracken@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Bracken Mosbacker <bracken@instructure.com> Product-Review: Hilary Scharton <hilary@instructure.com>
2014-05-28 06:11:56 +08:00
def default_transitions(context, orig_state)
valid_states = %w(off on)
valid_states << 'allowed' if context.is_a?(Account)
(valid_states - [orig_state]).inject({}) do |transitions, state|
remove "Allowed" state for RootAccount features on root accounts the "Allowed" state means a feature is off in an account, but sub-accounts or courses below it are allowed to enable it. the 'allowed' state does not, however, make a lot of sense for features that apply to RootAccount. since the feature cannot be controlled in sub-accounts or courses, the 'allowed' state is equivalent to 'off' here. so to make this less confusing, remove the "allowed" state for RootAccount features. (specifically, lock the transition in the API, and make the UI hide buttons for locked transitions that don't have messages to display when the user tries to perform them) test plan: - set the Use New Styles feature to "Allowed" in Site Admin account settings - in a root account settings page, ensure the 'Allowed' option is not selectable for this feature - ensure that the API reports the new_styles feature is "off" and its "allowed" transition is locked i.e., GET /api/v1/accounts/1/features/flags/new_styles includes state: 'off' and transitions: {allowed: {locked: true}} - ensure the API refuses to set the new_styles feature to "allowed" in the root account i.e., PUT /api/v1/accounts/1/features/flags/new_styles?state=allowed should return a 403 error and not change the state - regression test: in a sub-account, ensure the 'Use New Styles' feature does not appear - regression test: verify that when a (non-site-admin) root account admin attempts to disable Draft State in an account, the Off button is still there, and a message appears when you click it, and the feature remains enabled fixes CNVS-13220 Change-Id: I4d41076c10696b02d0c482a778d2555714487f17 Reviewed-on: https://gerrit.instructure.com/35473 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Bracken Mosbacker <bracken@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Bracken Mosbacker <bracken@instructure.com> Product-Review: Hilary Scharton <hilary@instructure.com>
2014-05-28 06:11:56 +08:00
transitions[state] = { 'locked' => (state == 'allowed' && @applies_to == 'RootAccount' &&
context.is_a?(Account) && context.root_account? && !context.site_admin?) }
transitions
end
end
remove "Allowed" state for RootAccount features on root accounts the "Allowed" state means a feature is off in an account, but sub-accounts or courses below it are allowed to enable it. the 'allowed' state does not, however, make a lot of sense for features that apply to RootAccount. since the feature cannot be controlled in sub-accounts or courses, the 'allowed' state is equivalent to 'off' here. so to make this less confusing, remove the "allowed" state for RootAccount features. (specifically, lock the transition in the API, and make the UI hide buttons for locked transitions that don't have messages to display when the user tries to perform them) test plan: - set the Use New Styles feature to "Allowed" in Site Admin account settings - in a root account settings page, ensure the 'Allowed' option is not selectable for this feature - ensure that the API reports the new_styles feature is "off" and its "allowed" transition is locked i.e., GET /api/v1/accounts/1/features/flags/new_styles includes state: 'off' and transitions: {allowed: {locked: true}} - ensure the API refuses to set the new_styles feature to "allowed" in the root account i.e., PUT /api/v1/accounts/1/features/flags/new_styles?state=allowed should return a 403 error and not change the state - regression test: in a sub-account, ensure the 'Use New Styles' feature does not appear - regression test: verify that when a (non-site-admin) root account admin attempts to disable Draft State in an account, the Off button is still there, and a message appears when you click it, and the feature remains enabled fixes CNVS-13220 Change-Id: I4d41076c10696b02d0c482a778d2555714487f17 Reviewed-on: https://gerrit.instructure.com/35473 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Bracken Mosbacker <bracken@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Bracken Mosbacker <bracken@instructure.com> Product-Review: Hilary Scharton <hilary@instructure.com>
2014-05-28 06:11:56 +08:00
def transitions(user, context, orig_state)
h = default_transitions(context, orig_state)
if @custom_transition_proc.is_a?(Proc)
@custom_transition_proc.call(user, context, orig_state, h)
end
h
end
remove "Allowed" state for RootAccount features on root accounts the "Allowed" state means a feature is off in an account, but sub-accounts or courses below it are allowed to enable it. the 'allowed' state does not, however, make a lot of sense for features that apply to RootAccount. since the feature cannot be controlled in sub-accounts or courses, the 'allowed' state is equivalent to 'off' here. so to make this less confusing, remove the "allowed" state for RootAccount features. (specifically, lock the transition in the API, and make the UI hide buttons for locked transitions that don't have messages to display when the user tries to perform them) test plan: - set the Use New Styles feature to "Allowed" in Site Admin account settings - in a root account settings page, ensure the 'Allowed' option is not selectable for this feature - ensure that the API reports the new_styles feature is "off" and its "allowed" transition is locked i.e., GET /api/v1/accounts/1/features/flags/new_styles includes state: 'off' and transitions: {allowed: {locked: true}} - ensure the API refuses to set the new_styles feature to "allowed" in the root account i.e., PUT /api/v1/accounts/1/features/flags/new_styles?state=allowed should return a 403 error and not change the state - regression test: in a sub-account, ensure the 'Use New Styles' feature does not appear - regression test: verify that when a (non-site-admin) root account admin attempts to disable Draft State in an account, the Off button is still there, and a message appears when you click it, and the feature remains enabled fixes CNVS-13220 Change-Id: I4d41076c10696b02d0c482a778d2555714487f17 Reviewed-on: https://gerrit.instructure.com/35473 Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Bracken Mosbacker <bracken@instructure.com> QA-Review: Clare Strong <clare@instructure.com> Product-Review: Bracken Mosbacker <bracken@instructure.com> Product-Review: Hilary Scharton <hilary@instructure.com>
2014-05-28 06:11:56 +08:00
def self.transitions(feature_name, user, context, orig_state)
fd = definitions[feature_name.to_s]
return nil unless fd
fd.transitions(user, context, orig_state)
end
feature flags infrastructure and API test plan: - install the test_features plugin (since no real features exist yet) - render and consult the feature flags documentation - have a test environment with a root account, sub-account, course in sub-account, and user - Use the "list features" endpoint as a root account admin (with no site admin privileges), on the root account context, and confirm that hidden features do not show up - Use the "list features" endpoint as a site admin user, on the root account context, and confirm that hidden features show up - Use the "list features" endpoint on the site admin account and confirm the hidden features show up - Use the "set feature flag" endpoint on a hidden feature on site admin and ensure the feature becomes visible in all root accounts - Use the "set feature flag endpoint" on a hidden feature on a single root account, and ensure the feature becomes visible to that root account and not others - Confirm that root_opt_in features appear "Off" by default in root accounts, after being "Allowed" in code or site admin - Confirm a feature flag that is set to "on" or "off" (vs. "allowed") cannot be overridden in a lower context (and the API returns locked=true for them) - Confirm that setting locking_account_id requires admin rights in the locking account - Confirm that a feature flag with locking_account_id cannot be changed without admin rights in the locking account (e.g., set a feature flag on a course, locked with the root account's id, and make sure a teacher who is not an account admin can't change it) - Confirm feature flags can be deleted with the "remove feature flag" endpoint (and they are only deleted where they are defined, not when called on an object that inherits a flag) Change-Id: I3e12e23b4454889b6e8b263f1315e82d8f2ada52 Reviewed-on: https://gerrit.instructure.com/25502 Tested-by: Jenkins <jenkins@instructure.com> QA-Review: Matt Fairbourn <mfairbourn@instructure.com> Product-Review: Matt Goodwin <mattg@instructure.com> Reviewed-by: Zach Pendleton <zachp@instructure.com>
2013-10-22 23:28:26 +08:00
end
# load feature definitions
Dir.glob("#{Rails.root}/lib/features/*.rb").each { |file| require_dependency file }