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
2015-11-10 05:51:25 +08:00
ATTRS = [ :feature , :display_name , :description , :applies_to , :state , :root_opt_in , :enable_at , :beta , :development ,
2016-07-20 22:04:41 +08:00
:release_notes_url , :custom_transition_proc , :after_state_change_proc , :autoexpand , :touch_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
attr_reader * ATTRS
def initialize ( opts = { } )
@state = 'allowed'
opts . each do | key , val |
next unless ATTRS . include? ( key )
2014-10-22 02:40:02 +08:00
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
2015-04-18 04:04:52 +08:00
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
2016-01-16 07:45:39 +08:00
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
2014-09-23 03:52:19 +08:00
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:
2015-04-28 01:24:10 +08:00
# 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
2015-08-28 02:45:27 +08:00
# # setting `development: true` prevents the flag from being registered on production,
# # which means `context.feature_enabled?` calls for the feature will always return false.
2015-04-28 01:24:10 +08:00
# 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
2016-04-20 07:06:16 +08:00
# after_state_change_proc: ->(user, context, old_state, new_state) { ... }
2015-04-28 01:24:10 +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 . register ( feature_hash )
@features || = { }
2014-09-23 03:52:19 +08:00
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)
2013-11-26 01:47:06 +08:00
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
2013-12-31 00:44:18 +08:00
} ,
2015-07-21 05:19:44 +08:00
'epub_export' = >
{
2015-10-31 00:34:35 +08:00
display_name : - > { I18n . t ( 'ePub Exporting' ) } ,
2015-07-21 05:19:44 +08:00
description : - > { I18n . t ( <<END) },
This enables users to generate and download course ePub .
END
2015-10-31 00:34:35 +08:00
applies_to : 'Course' ,
2015-12-01 03:15:26 +08:00
state : 'allowed' ,
2015-10-31 00:34:35 +08:00
root_opt_in : true ,
beta : true
2015-07-21 05:19:44 +08:00
} ,
2014-04-03 14:37:18 +08:00
'high_contrast' = >
{
2015-11-10 05:51:25 +08:00
display_name : - > { I18n . t ( 'features.high_contrast' , 'High Contrast UI' ) } ,
2014-04-03 14:37:18 +08:00
description : - > { I18n . t ( 'high_contrast_description' , <<-END) },
2015-11-10 05:51:25 +08:00
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 .
2014-04-03 14:37:18 +08:00
END
applies_to : 'User' ,
state : 'allowed' ,
2015-11-10 05:51:25 +08:00
autoexpand : true
2014-04-03 14:37:18 +08:00
} ,
2016-07-14 06:04:22 +08:00
'underline_all_links' = >
{
display_name : - > { I18n . t ( 'Underline Links' ) } ,
description : - > { I18n . t ( 'Display all text links in Canvas as *underlined text*.' ,
wrapper : {
'*' = > '<span class="feature-detail-underline">\1</span>'
}
)
} ,
applies_to : 'User' ,
state : 'allowed' ,
beta : true
} ,
2013-12-31 00:44:18 +08:00
'outcome_gradebook' = >
{
2014-04-30 23:51:53 +08:00
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
2013-12-31 00:44:18 +08:00
progress on course learning outcomes . Outcomes are presented in a Gradebook - like
2014-02-21 07:12:04 +08:00
format and student progress is displayed both as a numerical score and as mastered / near
mastery / remedial .
2014-06-12 01:38:59 +08:00
END
applies_to : 'Course' ,
state : 'allowed' ,
2014-09-23 03:52:19 +08:00
root_opt_in : false
2014-06-12 01:38:59 +08:00
} ,
'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 .
2014-01-11 07:43:55 +08:00
END
applies_to : 'Course' ,
2014-02-20 01:36:09 +08:00
state : 'allowed' ,
2014-09-23 03:52:19 +08:00
root_opt_in : false
2014-01-11 07:43:55 +08:00
} ,
2014-09-23 03:52:19 +08:00
'post_grades' = >
{
display_name : - > { I18n . t ( 'features.post_grades' , 'Post Grades to SIS' ) } ,
description : - > { I18n . t ( 'post_grades_description' , <<-END) },
2014-04-16 06:32:46 +08:00
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 ,
2014-09-23 03:52:19 +08:00
GradingAssignment , GradingAssignmentScore .
END
applies_to : 'Course' ,
state : 'hidden' ,
root_opt_in : true ,
beta : true
} ,
2014-07-22 02:38:27 +08:00
'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' ) } ,
2014-07-22 02:38:27 +08:00
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 ,
2014-09-23 03:52:19 +08:00
beta : true
2014-07-22 02:38:27 +08:00
} ,
2015-04-10 06:59:52 +08:00
'recurring_calendar_events' = >
{
display_name : - > { I18n . t ( 'Recurring Calendar Events' ) } ,
description : - > { I18n . t ( " Allows the scheduling of recurring calendar events " ) } ,
applies_to : 'Course' ,
2015-09-16 23:40:37 +08:00
state : 'hidden' ,
root_opt_in : true ,
2015-04-10 06:59:52 +08:00
beta : true
} ,
2014-07-29 02:38:48 +08:00
'allow_opt_out_of_inbox' = >
{
2014-12-17 07:01:21 +08:00
display_name : - > { I18n . t ( 'features.allow_opt_out_of_inbox' , " Allow Users to Opt-out of the Inbox " ) } ,
2014-07-29 02:38:48 +08:00
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
2014-08-12 23:06:01 +08:00
} ,
'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' ,
2016-08-02 06:25:04 +08:00
state : 'hidden'
2014-08-12 23:06:01 +08:00
} ,
'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' ,
2016-08-02 06:25:04 +08:00
state : 'hidden'
2014-08-12 23:06:01 +08:00
} ,
2014-10-02 04:19:05 +08:00
'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 .
2014-10-02 04:19:05 +08:00
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' ,
2015-06-24 05:08:51 +08:00
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
2013-09-26 03:01:06 +08:00
} ,
'course_catalog' = >
{
2015-06-24 03:24:02 +08:00
display_name : - > { I18n . t ( " Public Course Index " ) } ,
2013-09-26 03:01:06 +08:00
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' ,
2014-12-23 00:58:16 +08:00
state : 'allowed'
2014-11-18 07:12:53 +08:00
} ,
'usage_rights_required' = >
{
2014-12-17 07:01:21 +08:00
display_name : - > { I18n . t ( 'Require Usage Rights for Uploaded Files' ) } ,
2015-03-04 05:00:31 +08:00
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.' ) } ,
2014-11-18 07:12:53 +08:00
applies_to : 'Course' ,
state : 'hidden' ,
root_opt_in : true
2014-12-16 06:06:01 +08:00
} ,
2015-10-24 00:32:18 +08:00
'lti2_rereg' = >
{
display_name : - > { I18n . t ( 'LTI 2 Reregistration' ) } ,
description : - > { I18n . t ( 'Enable reregistration for LTI 2 ' ) } ,
applies_to : 'RootAccount' ,
state : 'hidden' ,
beta : true
} ,
2015-03-19 05:00:13 +08:00
'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' ) } ,
2015-03-19 05:00:13 +08:00
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
2015-05-16 01:04:26 +08:00
} ,
'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' ) } ,
2015-05-16 01:04:26 +08:00
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
2015-05-16 04:43:16 +08:00
} ,
'bulk_sis_grade_export' = >
{
2015-06-16 05:06:56 +08:00
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
} ,
2015-11-21 05:30:54 +08:00
'notification_service' = >
{
display_name : - > { I18n . t ( 'Use remote service for notifications' ) } ,
2016-01-27 02:34:35 +08:00
description : - > { I18n . t ( 'Allow the ability to send notifications through our dispatch queue' ) } ,
2015-11-21 05:30:54 +08:00
applies_to : 'RootAccount' ,
state : 'hidden' ,
beta : true ,
2016-03-24 00:25:40 +08:00
development : false ,
2015-11-21 05:30:54 +08:00
root_opt_in : false
} ,
2016-08-24 22:15:42 +08:00
'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 : true ,
root_opt_in : false
} ,
2015-06-16 03:10:35 +08:00
'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' ) } ,
2015-06-16 03:10:35 +08:00
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
2015-07-29 00:25:30 +08:00
} ,
2016-04-12 06:47:13 +08:00
'course_card_images' = >
{
display_name : - > { I18n . t ( 'Enable Dashboard Images for Courses' ) } ,
2016-05-07 02:06:53 +08:00
description : - > { I18n . t ( 'Allow course images to be assigned to a course and used on the dashboard cards.' ) } ,
2016-04-12 06:47:13 +08:00
applies_to : 'Course' ,
2016-08-12 03:35:33 +08:00
state : 'allowed' ,
2016-04-12 06:47:13 +08:00
root_opt_in : true ,
beta : true
} ,
2015-11-17 06:46:59 +08:00
'gradebook_performance' = > {
2015-09-11 02:35:07 +08:00
display_name : - > { I18n . t ( 'Gradebook Performance' ) } ,
description : - > { I18n . t ( 'Performance enhancements for the Gradebook' ) } ,
applies_to : 'Course' ,
state : 'hidden' ,
2015-12-01 05:21:53 +08:00
development : true ,
2015-09-11 02:35:07 +08:00
root_opt_in : true
2015-08-14 07:16:14 +08:00
} ,
2015-11-17 07:04:02 +08:00
'anonymous_grading' = > {
2015-08-14 07:16:14 +08:00
display_name : - > { I18n . t ( 'Anonymous Grading' ) } ,
description : - > { I18n . t ( " Anonymous grading forces student names to be hidden in SpeedGrader™ " ) } ,
applies_to : 'Course' ,
2015-11-17 07:04:02 +08:00
state : 'allowed'
2015-08-14 07:16:14 +08:00
} ,
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' ,
2016-01-07 07:25:27 +08:00
state : 'hidden' ,
2015-10-14 05:34:23 +08:00
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
2015-10-16 13:03:08 +08:00
} ,
'course_user_search' = > {
2016-07-20 04:05:13 +08:00
display_name : - > { I18n . t ( 'Account Course and User Search' ) } ,
2015-10-16 13:03:08 +08:00
description : - > { I18n . t ( 'Updated UI for searching and displaying users and courses within an account.' ) } ,
2016-07-20 23:50:55 +08:00
applies_to : 'Account' ,
2016-07-26 02:50:32 +08:00
state : 'hidden' ,
2016-07-20 04:05:13 +08:00
beta : true ,
2016-07-26 00:42:32 +08:00
development : true ,
2016-07-20 23:50:55 +08:00
root_opt_in : true
2015-11-06 05:22:30 +08:00
} ,
'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' ,
2016-03-30 01:28:55 +08:00
state : 'allowed' ,
2015-11-06 05:22:30 +08:00
beta : true ,
2016-03-15 05:40:16 +08:00
development : false ,
2015-11-06 05:22:30 +08:00
root_opt_in : false
2016-02-19 04:15:30 +08:00
} ,
2016-02-26 04:59:36 +08:00
'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 ,
2016-03-30 01:28:55 +08:00
development : false ,
2016-02-26 04:59:36 +08:00
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 ,
2016-03-30 01:28:55 +08:00
development : false ,
2016-02-26 04:59:36 +08:00
root_opt_in : false
} ,
2016-02-19 04:15:30 +08:00
'conditional_release' = >
{
2016-07-16 05:57:11 +08:00
display_name : - > { I18n . t ( 'Mastery Paths' ) } ,
2016-02-19 04:15:30 +08:00
description : - > { I18n . t ( 'Configure individual learning paths for students based on assessment results.' ) } ,
applies_to : 'Course' ,
state : 'hidden' ,
beta : true ,
2016-06-21 06:40:14 +08:00
development : false ,
2016-02-19 04:15:30 +08:00
root_opt_in : false ,
2016-04-20 07:06:16 +08:00
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
}
2016-02-19 04:15:30 +08:00
} ,
2016-03-17 07:41:23 +08:00
'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
2016-05-19 02:20:53 +08:00
} ,
'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 " ) } ,
2016-06-16 01:54:54 +08:00
applies_to : 'Course' ,
2016-05-19 02:20:53 +08:00
state : 'hidden' ,
2016-08-10 00:54:50 +08:00
development : false ,
2016-05-19 02:20:53 +08:00
root_opt_in : true
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 : 'Course' ,
2016-08-09 00:38:20 +08:00
state : 'hidden' ,
2016-07-07 02:44:45 +08:00
beta : true ,
root_opt_in : true
2016-03-17 07:41:23 +08:00
}
2013-11-26 01:47:06 +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 )
2014-01-15 04:20:02 +08:00
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? ) }
2014-01-15 04:20:02 +08:00
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 )
2014-01-15 04:20:02 +08:00
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
2014-01-15 04:20:02 +08:00
# load feature definitions
2014-09-05 02:04:20 +08:00
Dir . glob ( " #{ Rails . root } /lib/features/*.rb " ) . each { | file | require_dependency file }