explicitly have one copy per node in a ring (instead of relying
on hashing of a different to hopefully evenly spread copies around
the ring).
test plan:
* configure a ring of redis servers for cache
* canvas should still work
Change-Id: I17e086aac28c1c095c9717a7625ca51c86d0598f
Reviewed-on: https://gerrit.instructure.com/48069
Tested-by: Jenkins
Reviewed-by: Rob Orton <rob@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
also remove the 'development' tag on existing features, other
than those that manually made themselves invisible in prod.
we'll let 'beta' suffice for the purpose of informing the user
that a feature is not fully baked.
test plan:
- Deploy normally to your QA portal. The 'quiz stats'
feature flag should be available and operational.
- Remove the testcluster.yml file from your config/
directory (or move / back it up to a safe place)
- Restart your QA portal.
- The quiz stats feature flag should not be available
or visible.
fixes CNVS-15724
Change-Id: I9e4e46f8cc4f54ac62f5226dbca09ae4885c93a9
Reviewed-on: https://gerrit.instructure.com/41551
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Josh Simpson <jsimpson@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
Product-Review: Cosme Salazar <cosme@instructure.com>
test plan:
- as a user with site admin privileges, enable the "LOR External
Tools feature in /profile/settings.
fixes CNVS-15393
Change-Id: I918bdff059b4ef3b5590aa67b0991198699196fa
Reviewed-on: https://gerrit.instructure.com/40850
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Product-Review: Bracken Mosbacker <bracken@instructure.com>
QA-Review: Clare Strong <clare@instructure.com>
test plan:
- in an instance with redis caching enabled,
1. set draft state to "allowed" in a root account
2. in a console, make the cache think the feature flag doesn't exist
Rails.cache.write(account.feature_flag_cache_key('draft_state'), :nil)
3. reload the account settings page
4. you should be able to set draft state to "on" or "allowed"
with no AJAX error, and the change should stick
fixes CNVS-13484
Change-Id: I4a9664858f3dfcbd3d2d2999a9e1e62b1231bceb
Reviewed-on: https://gerrit.instructure.com/36123
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Nathan Rogowski <nathan@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
converting for:
favorites controller
feature flags controller
files controller
folders controller
grade change audit api controller
Contributed by github.com/mcgachey
Fixes SIS-146
Currently, some API objects are documented using the @object tag, and
others are documented using @model. The @model tag is preferred because
it provides more information in the machine-readable Swagger documents
generated by the API documentation build step. For example, the @object
notation does not give a way to specify that a model property contains
an instance of another type. This complete information is necessary in
order to build an SDK generator.
This change converts the @object notations into @model, adding missing
type information and correcting inaccurate data (for example, dates were
typed as "string" in the existing JSON documentation). Embedded types are
also separated out so that their format can also be documented - this
information was previously lost.
The change also makes two minor fixes to the HTML and JSON documentation
generators. The HTML generator is fixed so that a missing documentation
string is ignored rather than being shown as an empty comment, and the
JSON generator is modified so that the Model-level documentation and
required attributes are properly provided.
Note that the JSON generated here is not fully-complient to the Swagger
format. Swagger does not support a Map structure, but the Canvas API
uses (semi-)arbitrary key/value dictionaries in a few places. In those
instances the properties are typed as "map", but this is not a part of the
Swagger spec. Any cleaner alternative approaches here would be welcome.
Change-Id: I5d90bd33f393f5b55c6a4d50b7e92c87648b9ba3
Reviewed-on: https://gerrit.instructure.com/30000
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
to enable for your feature, in your feature definition, use
after_state_change_proc: ->(context, old_state, new_state) { ... }
test plan:
- specs pass
- a future commit will make use of this feature
and can be tested directly
fixes CNVS-10357
Change-Id: I5510545802fd181707bc217e179ba7102eec9d37
Reviewed-on: https://gerrit.instructure.com/28570
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Product-Review: Bracken Mosbacker <bracken@instructure.com>
QA-Review: Bracken Mosbacker <bracken@instructure.com>
test plan:
0. render and consult the API documentation on feature flags,
specifically looking at the 'transitions' member that
was added to FeatureFlag
1. enable draft state in a course
2. use the API to show the draft state feature flag for the
course (GET /courses/X/features/flags/draft_state)
- verify that transitions['off'] contains a warning
message about what happens to unpublished data
3. allow draft state in an account
4. as a non-site-admin user, use the API to show the
draft state feature flag for the account
(GET /accounts/X/features/flags/draft_state)
- verify that transitions['on']['locked'] is false
- verify that transitions['off']['locked'] is true
and is accompanied by an explanatory message
5. attempt to turn the feature off via the API
(still as a non-site-admin user)
- you should get a 403 Forbidden error
6. repeat step 4 as a site-admin user
- neither transition should be 'locked', but the
message should still accompany 'off'
7. repeat step 5 as a site-admin user
- it should succeed
fixes CNVS-10355
fixes CNVS-10356
Change-Id: I36b0d387ad09f98cdf3d4de9e4e351bfd6aa8c58
Reviewed-on: https://gerrit.instructure.com/28541
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Product-Review: Bracken Mosbacker <bracken@instructure.com>
QA-Review: Nathan Rogowski <nathan@instructure.com>
creating feature flags _on_ site admin still requires a
full-fledged site administrator, but creating feature flags
for hidden features on root accounts only requires a site
membership (and permissions on the root account, of course).
test plan:
- a user with a non-admin account membership on site admin:
* should be able to see hidden features on site admin and
root accounts
* should not be able to set feature flags on site admin
* should be able to enable hidden features on root accounts
(provided their site membership or root account membership
gives them this ability)
fixes CNVS-10205
Change-Id: I4463dd6e60b06b7428143412e902b9e0fa895f04
Reviewed-on: https://gerrit.instructure.com/27959
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Bracken Mosbacker <bracken@instructure.com>
QA-Review: Matt Fairbourn <mfairbourn@instructure.com>
Change-Id: I1b033218005807bbb44905ce8a6b33a7e809f742
Reviewed-on: https://gerrit.instructure.com/27543
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Steven Shepherd <sshepherd@instructure.com>
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>
Jeremy Stanley