canvas-lms/lib/feature.rb

488 lines
19 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 Instructure, Inc.
#
# This file is part of Canvas.
#
# Canvas is free software: you can redistribute it and/or modify it under
# the terms of the GNU Affero General Public License as published by the Free
# Software Foundation, version 3 of the License.
#
# Canvas is distributed in the hope that it will be useful, but WITHOUT ANY
# WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR
# A PARTICULAR PURPOSE. See the GNU Affero General Public License for more
# details.
#
# You should have received a copy of the GNU Affero General Public License along
# with this program. If not, see <http://www.gnu.org/licenses/>.
#
class Feature
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]
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, current_user = nil)
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: {
# display_name: lambda { I18n.t('features.automatic_essay_grading', 'Automatic Essay Grading') },
# description: lambda { 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: ->(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
},
'use_new_styles' =>
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
{
display_name: -> { I18n.t('New UI') },
description: -> { I18n.t(<<END) },
This enables an updated navigation, new dashboard and a simpler, more modern look and feel.
END
applies_to: 'RootAccount',
state: 'allowed',
root_opt_in: true,
beta: 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: 'hidden',
root_opt_in: true,
beta: true
},
'html5_first_videos' =>
{
display_name: -> { I18n.t('features.html5_first_videos', 'Prefer HTML5 for video playback') },
description: -> { I18n.t('html5_first_videos_description', <<-END) },
By default, Canvas will try to use Flash first to play videos. Turn this on to try using HTML5 first,
then fall back to Flash.
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: 'RootAccount',
state: 'on',
beta: false
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', 'Use High Contrast Styles') },
description: -> { I18n.t('high_contrast_description', <<-END) },
If you would prefer a higher-contrast version of the Canvas user interface, enable this.
This might be useful for people with impaired vision or difficulty reading.
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',
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
},
'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
},
'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
},
'student_groups_next' =>
{
display_name: -> { I18n.t('features.student_groups', 'New Student Groups Page') },
description: -> { I18n.t('student_groups_desc', <<-END) },
This enables the new student group page for an account. The new page was build to provide a more dynamic group signup
experience.
END
applies_to: 'RootAccount',
state: 'on'
A work in progress version of the new ember files app this commit is meant to be a way to commit some of the progress I have been making on this. everything new is behind a hidden feature flag so it should not do anything any different for any existing users if you want to test it out, open a console and do: Course.find(<your course id>).enable_feature! :better_file_browsing then browse to the 'files' part of your course. the main thing to QA right now is that we did not break anything for people that don't have that feature flag turned on. I know there are a ton of things that are either broken or still need to be implemented on the new app. this is a few commits squashed into one and closes multiple tickets: create rails routes for new files UI closes: CNVS-12140 for the new files UI we are going to use pushState urls so we had to find a url namespace that we could completely take over. the thing we chose was /(courses|groups)/<course_id>/files/folder/foo/bar/baz (assuming you were looking at the foo/bar/baz folder) example urls: /course/1/files/folder/foo/bar/baz /groups/2/files/folder/lectures/1 Cell Mitosis/handouts/takehome work/ /files /course/1/files acceptance criteria: the following NEW urls SHOULD be routed to new ember files page: /(courses|groups|accounts|users)/:id/files/folder*full_path /dashboard/files/folder*full_path /files/folder*full_path the following urls already exist and if the :new_files feature is enabled SHOULD be routed also to the new ember files page instead of where they go now (but if the :new_files feature is not enabled, they should still go where they go now): /files /(courses|groups|accounts|users)/:id/files /dashboard/files style mockups for the new files page fixes CNVS-11216 Enable feature flag for new files page, closes #CNVS-11215 closes: CNVS-12730 closes: CNVS-12659 closes: CNVS-12663 Change-Id: I3868fcf8efd6b517f38f56e88c7bb1e56cf564e8 Reviewed-on: https://gerrit.instructure.com/36005 QA-Review: Clare Strong <clare@instructure.com> Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Jeremy Stanley <jeremy@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2014-03-21 04:17:43 +08:00
},
'better_file_browsing' =>
{
display_name: -> { I18n.t('features.better_file_browsing', 'Better File Browsing') },
description: -> { I18n.t('better_file_browsing_description', <<-END) },
A new, simpler, more user friendly file browsing interface. If you turn this on at the course level,
then all of the users in that course will see the new interface. To get it to show up when someone
goes to the personal files page for a user ('/files') then you need to turn it on for the account they are a member of.
A work in progress version of the new ember files app this commit is meant to be a way to commit some of the progress I have been making on this. everything new is behind a hidden feature flag so it should not do anything any different for any existing users if you want to test it out, open a console and do: Course.find(<your course id>).enable_feature! :better_file_browsing then browse to the 'files' part of your course. the main thing to QA right now is that we did not break anything for people that don't have that feature flag turned on. I know there are a ton of things that are either broken or still need to be implemented on the new app. this is a few commits squashed into one and closes multiple tickets: create rails routes for new files UI closes: CNVS-12140 for the new files UI we are going to use pushState urls so we had to find a url namespace that we could completely take over. the thing we chose was /(courses|groups)/<course_id>/files/folder/foo/bar/baz (assuming you were looking at the foo/bar/baz folder) example urls: /course/1/files/folder/foo/bar/baz /groups/2/files/folder/lectures/1 Cell Mitosis/handouts/takehome work/ /files /course/1/files acceptance criteria: the following NEW urls SHOULD be routed to new ember files page: /(courses|groups|accounts|users)/:id/files/folder*full_path /dashboard/files/folder*full_path /files/folder*full_path the following urls already exist and if the :new_files feature is enabled SHOULD be routed also to the new ember files page instead of where they go now (but if the :new_files feature is not enabled, they should still go where they go now): /files /(courses|groups|accounts|users)/:id/files /dashboard/files style mockups for the new files page fixes CNVS-11216 Enable feature flag for new files page, closes #CNVS-11215 closes: CNVS-12730 closes: CNVS-12659 closes: CNVS-12663 Change-Id: I3868fcf8efd6b517f38f56e88c7bb1e56cf564e8 Reviewed-on: https://gerrit.instructure.com/36005 QA-Review: Clare Strong <clare@instructure.com> Tested-by: Jenkins <jenkins@instructure.com> Reviewed-by: Jeremy Stanley <jeremy@instructure.com> Product-Review: Ryan Shaw <ryan@instructure.com>
2014-03-21 04:17:43 +08:00
END
applies_to: 'Course',
state: 'on'
},
'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',
beta: true
},
'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',
beta: true
},
'multiple_grading_periods' =>
{
display_name: -> { I18n.t('features.multiple_grading_periods', 'Multiple Grading Periods') },
description: -> { I18n.t('enable_multiple_grading_periods', <<-END) },
make grading periods feature flag a course level flag make the grading periods feature flag a course level flag, and also 'unlock' the account level grading periods. now, a teacher can edit account level periods, but when they click 'save' it will create a new course-level grading period instead of altering the original account-level period. also added a link to the feature flag settings page if there is only one grading period on the page. in addition, if only template periods are being shown on the page and you're logged in as a teacher, added a message that notifies the user that the periods were created by an administrator for them. closes CNVS-18741 closes CNVS-19692 test plan: this commit makes substantial changes to the way grading periods are being displayed, deleted, and saved on the 'accounts/:account_id/grading_standards' page and the 'courses/:course_id/grading_standards' page. users should still be able to create/update/delete grading periods without problems on those pages. in addition, this commit makes changes to the feature flag settings pages for admins and teachers. make sure the feature flags are working correctly (try setting the MGP flag to 'on', 'off', and 'allow' as an admin and see how it affects the feature flag options for sub-accounts and teachers). Change-Id: I0b442e708a8049180b55a86098e30a2c64673eda Reviewed-on: https://gerrit.instructure.com/51594 Tested-by: Jenkins Reviewed-by: Josh Simpson <jsimpson@instructure.com> QA-Review: Robert Lamb <rlamb@instructure.com> Product-Review: Spencer Olson <solson@instructure.com>
2015-04-01 02:04:09 +08:00
Multiple Grading Periods allows teachers and admins to create grading periods with set
cutoff dates. Assignments can be filtered by these grading periods in the gradebook.
END
make grading periods feature flag a course level flag make the grading periods feature flag a course level flag, and also 'unlock' the account level grading periods. now, a teacher can edit account level periods, but when they click 'save' it will create a new course-level grading period instead of altering the original account-level period. also added a link to the feature flag settings page if there is only one grading period on the page. in addition, if only template periods are being shown on the page and you're logged in as a teacher, added a message that notifies the user that the periods were created by an administrator for them. closes CNVS-18741 closes CNVS-19692 test plan: this commit makes substantial changes to the way grading periods are being displayed, deleted, and saved on the 'accounts/:account_id/grading_standards' page and the 'courses/:course_id/grading_standards' page. users should still be able to create/update/delete grading periods without problems on those pages. in addition, this commit makes changes to the feature flag settings pages for admins and teachers. make sure the feature flags are working correctly (try setting the MGP flag to 'on', 'off', and 'allow' as an admin and see how it affects the feature flag options for sub-accounts and teachers). Change-Id: I0b442e708a8049180b55a86098e30a2c64673eda Reviewed-on: https://gerrit.instructure.com/51594 Tested-by: Jenkins Reviewed-by: Josh Simpson <jsimpson@instructure.com> QA-Review: Robert Lamb <rlamb@instructure.com> Product-Review: Spencer Olson <solson@instructure.com>
2015-04-01 02:04:09 +08:00
applies_to: 'Course',
state: 'allowed',
make grading periods feature flag a course level flag make the grading periods feature flag a course level flag, and also 'unlock' the account level grading periods. now, a teacher can edit account level periods, but when they click 'save' it will create a new course-level grading period instead of altering the original account-level period. also added a link to the feature flag settings page if there is only one grading period on the page. in addition, if only template periods are being shown on the page and you're logged in as a teacher, added a message that notifies the user that the periods were created by an administrator for them. closes CNVS-18741 closes CNVS-19692 test plan: this commit makes substantial changes to the way grading periods are being displayed, deleted, and saved on the 'accounts/:account_id/grading_standards' page and the 'courses/:course_id/grading_standards' page. users should still be able to create/update/delete grading periods without problems on those pages. in addition, this commit makes changes to the feature flag settings pages for admins and teachers. make sure the feature flags are working correctly (try setting the MGP flag to 'on', 'off', and 'allow' as an admin and see how it affects the feature flag options for sub-accounts and teachers). Change-Id: I0b442e708a8049180b55a86098e30a2c64673eda Reviewed-on: https://gerrit.instructure.com/51594 Tested-by: Jenkins Reviewed-by: Josh Simpson <jsimpson@instructure.com> QA-Review: Robert Lamb <rlamb@instructure.com> Product-Review: Spencer Olson <solson@instructure.com>
2015-04-01 02:04:09 +08:00
root_opt_in: true
},
'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_ui' =>
{
display_name: -> { I18n.t('Show LTI 2 Configuration UI') },
description: -> { I18n.t('If enabled, users will be able to configure LTI 2 tools.') },
applies_to: 'RootAccount',
state: 'hidden',
beta: true
},
'lti2_rereg' =>
{
display_name: -> {I18n.t('LTI 2 Reregistration')},
description: -> { I18n.t('Enable reregistration for LTI 2 ')},
applies_to:'RootAccount',
state: 'hidden',
beta: true
},
'quizzes_lti' =>
{
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('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' =>
{
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('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
},
'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
},
'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
},
'moderated_grading' => {
display_name: -> { I18n.t('Moderated Grading') },
description: -> { I18n.t('Moderated Grading allows multiple graders to grade selected assignments independently, with a moderator providing the final grade.') },
applies_to: 'Course',
state: 'hidden',
development: true,
root_opt_in: true
},
'gradebook_performance' => {
display_name: -> { I18n.t('Gradebook Performance') },
description: -> { I18n.t('Performance enhancements for the Gradebook') },
applies_to: 'Course',
state: 'hidden',
hidden_in_production: true,
root_opt_in: true
},
'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: 'hidden',
development: true,
root_opt_in: true,
},
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
},
'all_grading_periods_totals' =>
{
display_name: -> { I18n.t('Display Totals for "All Grading Periods"') },
description: -> { I18n.t('Display total grades when the "All Grading Periods" dropdown option is selected (Multiple Grading Periods must be enabled).') },
applies_to: 'Course',
state: 'allowed',
root_opt_in: true
},
'course_user_search' => {
display_name: -> { I18n.t('Course and User Search') },
description: -> { I18n.t('Updated UI for searching and displaying users and courses within an account.') },
applies_to: 'Account',
state: 'hidden',
development: true,
root_opt_in: true
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
}
)
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
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
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 }