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
2014-01-15 07:34:59 +08:00
ATTRS = [ :feature , :display_name , :description , :applies_to , :state , :root_opt_in , :enable_at , :beta , :development , :release_notes_url , :custom_transition_proc , :after_state_change_proc ]
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
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
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:
= begin
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'
2014-10-28 05:48:36 +08:00
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
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
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
2014-09-23 03:52:19 +08:00
development : false , # whether the feature is restricted to development / test / beta instances
2014-01-15 04:20:02 +08:00
release_notes_url : 'http://example.com/' ,
2014-01-15 07:34:59 +08:00
2014-01-15 04:20:02 +08:00
# 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
2014-01-15 07:34:59 +08:00
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
}
= end
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
} ,
2014-06-11 07:16:06 +08:00
'use_new_styles' = >
2014-04-03 14:37:18 +08:00
{
display_name : - > { I18n . t ( 'features.new_styles' , 'Use New Styles' ) } ,
description : - > { I18n . t ( 'new_styles_description' , <<-END) },
We are working on a UI facelift to Canvas . Turn this on to opt - in to seeing the
2014-06-11 07:16:06 +08:00
updated , simplified look and feel of the Canvas interface . This is a very " Work in progress "
feature and should not be turned on in production for actual users yet .
2014-05-03 02:39:25 +08:00
END
applies_to : 'RootAccount' ,
2014-06-11 07:16:06 +08:00
state : 'hidden' ,
root_opt_in : true ,
2014-09-23 03:52:19 +08:00
beta : true
2014-05-03 02:39:25 +08:00
} ,
'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 .
2014-04-03 14:37:18 +08:00
END
applies_to : 'RootAccount' ,
2014-11-06 07:08:17 +08:00
state : 'on' ,
2014-12-13 05:44:37 +08:00
beta : false
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 .
2014-08-23 14:54:57 +08:00
This might be useful for people with impaired vision or difficulty reading .
2014-04-03 14:37:18 +08:00
END
applies_to : 'User' ,
state : 'allowed' ,
2014-09-23 03:52:19 +08:00
beta : true
2014-04-03 14:37:18 +08:00
} ,
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' = >
{
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 ,
2014-09-23 03:52:19 +08:00
beta : true
2014-07-22 02:38:27 +08:00
} ,
2014-05-20 04:20:17 +08:00
'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' ,
2014-12-18 06:30:34 +08:00
state : 'on'
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
2014-07-19 00:13:52 +08:00
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 .
2014-03-21 04:17:43 +08:00
END
applies_to : 'Course' ,
2014-11-06 03:26:06 +08:00
state : 'allowed' ,
2014-09-23 03:52:19 +08:00
beta : true
2014-04-09 05:03:02 +08:00
} ,
'modules_next' = >
{
display_name : - > { I18n . t ( 'features.ember_modules' , 'Ember Modules' ) } ,
description : - > { I18n . t ( 'ember_modules_description' , <<END) },
Modules rewritten in Ember . Uses the native drag and drop API to allow dragging from external locations .
END
applies_to : 'Course' ,
state : 'hidden' ,
root_opt_in : 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' ,
state : 'hidden' ,
2014-09-23 03:52:19 +08:00
beta : true
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' ,
state : 'hidden' ,
2014-09-23 03:52:19 +08:00
beta : true
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' ,
state : 'hidden_in_prod' ,
development : true ,
root_opt_in : true
2013-09-26 03:01:06 +08:00
} ,
'course_catalog' = >
{
display_name : - > { I18n . t ( 'features.course_catalog' , " Course Catalog " ) } ,
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
} ,
'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
2015-03-19 05:00:13 +08:00
} ,
'quizzes_lti' = >
{
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
2014-12-16 06:06:01 +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 }
2014-01-15 04:20:02 +08:00