test plan:
* create a role in site admin without access to developer keys
* add a user to that role
* login as that user, and go to site admin
* the Developer Keys tab should not be visible
* going to /developer_keys should give you access denied
Change-Id: I7ce3cbab13939067fb6d7e11c38dab3d48918442
Reviewed-on: https://gerrit.instructure.com/15775
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
test plan:
* migrate and confirm that the csv in
account.membership_types is now split into
Role objects with base_role_type of
'AccountMembership'
* also, roleoverrides that aren't referenced
in membership_types are assumed to have been deleted
so confirm that a Role is still made
but it is 'inactive'
Change-Id: Ic96c0ecdfd70e5678f74467686a9c9f385e53725
Reviewed-on: https://gerrit.instructure.com/15712
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
test plan:
* call the 'index' api call for roles
* confirm that 'StudentEnrollment', etc. have
a workflow state of 'active', not 'deleted'
Change-Id: Id8ae44b354ec989e20a31fcee6164dfc1195f5eb
Reviewed-on: https://gerrit.instructure.com/15656
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
test plan:
* specs (for now)
* (once able to check with the UI) test the api actions:
'activate', 'add_role', 'index', 'remove_role' and 'update'
for course roles (by setting the base_role_type argument)
closes#11743#11744
Change-Id: I1b8d54c37cf7dc32b6898349a1b6452349dac7c0
Reviewed-on: https://gerrit.instructure.com/15590
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
closes#11739
test plan: run specs (this is just infrastructure, no
functionality yet)
Change-Id: Icbe5a8db49665cede4371e023c6e37c32a1ad978
Reviewed-on: https://gerrit.instructure.com/15511
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan:
* log in to canvas with a normal user
* inspect the log file; there shouldn't be a query to load
each site admin user individually
Change-Id: I0164c4807446695be30b02fcbb5f40f19c80de7f
Reviewed-on: https://gerrit.instructure.com/15567
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#11764
test plan:
- as a site admin, go to the account settings and enable
calendar2 and the scheduler.
- go to calendar 2 and see the scheduler button is there.
- go back to the account settings and disable the scheduler.
- go back to calendar 2 and see the scheduler button is gone.
Change-Id: Iab1cb555216b9ce124588b86aa93955411e4f421
Reviewed-on: https://gerrit.instructure.com/15359
Reviewed-by: Marc LeGendre <marc@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Mark Ericksen <marke@instructure.com>
Testing Steps:
===========
* As an account admin, go to account settings
* Use new "Notifications" tab to change the setting
* Change the setting to 'Custom "From" Name' and give a name.
* When email notifications are sent out, the "From" name
should appear as this name.
Change-Id: I71dc9731b411f8f52a717ba83ce27f8bc43c476e
Reviewed-on: https://gerrit.instructure.com/14689
Reviewed-by: Zach Pendleton <zachp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#11504
Change-Id: If7c480bfac9b0339f9ce9f0ec6d5705dafbcb037
test-plan:
- global outcomes should be visible to:
- any logged in user
- outcomes defined in an account should be visible to:
- admins in subaccounts
- enrollees in the account's courses
- enrollees in the account's subaccounts' courses
- outcomes defined in a course should be visible to:
- any user that can view the course
- global outcomes should not be visible without being logged in
- managing outcomes should require the same permissions as before
Reviewed-on: https://gerrit.instructure.com/14910
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
in account settings, this checkbox wasn't wired up correctly.
fixes#11390
test plan:
- go to a root account settings page, as a site admin
- you should see the option, and checking it should stick
- as a regular account admin, the option should not be there
Change-Id: I2d7b67dea197f0990c5b2e8fbedf8aee0f72d79d
Reviewed-on: https://gerrit.instructure.com/14621
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
it's a common query, so reduce db dependency if possible
test plan:
* as a site admin, ensure you still have access to everything
* as a non-site admin, ensure you don't have access to any courses
or accounts that you shouldn't (even without links to them)
Change-Id: I56fb5063b16fe6a3ddc96bdf66586a9e48a79850
Reviewed-on: https://gerrit.instructure.com/13757
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
This can be used as a hint for proxies
test plan: for a root account that has ldap, the login form should still
post to /login. for accounts without ldap, it should post to
/login?nonldap=true
Change-Id: Ib22517acf4e2a11da2c6e0ff5569f31149d37c5c
Reviewed-on: https://gerrit.instructure.com/14611
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
simple keep-both resolutions for app/models/submission.rb and
config/routes.rb. spec/integration/learning_outcome_group_spec.rb stays
removed.
fixed path->url in outcome group api pagination to match master's new
rules.
Conflicts:
app/models/submission.rb
config/routes.rb
spec/integration/learning_outcome_group_spec.rb
Change-Id: I8dd31e1d3764970a8f683aef362f0cca06abe90e
Test Plan:
* Add a SAML config and a discovery url
* It should save
* Delete the url
* It should delete. :)
refs #10497
Change-Id: I244aa3a39ee04a6d0c83558da4962909510e9c15
Reviewed-on: https://gerrit.instructure.com/14295
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
An account can now have multiple SAML configurations, and
can set an auth discovery url.
The old AAC API has been deprecated and this adds a normal
resource API for AACs
Test Plan:
* Test the api be doing lots of things
* Create two saml configurations
* Test the individual login urls for each (/login/{id}) and verify they work
* Test that the new SAML AAC UI works.
* Test that the SAML configuration in position 1 is used as the default
closes#10497
Change-Id: Ibe35fcf788d9506542b1079cc7420912a1e9d9a2
Reviewed-on: https://gerrit.instructure.com/14042
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
closes#10292
Test plan:
1) enable calendar2 on an account
2) set up a user to prefer the old calendar
3) set the 'calendar2_only' setting to true on the account
4) go to the calendar as the user from step 2, you should be
redirected to calendar2
* there should be no way to get to the old calendar
Change-Id: I6280caf2878d04ef3f73efdbc61187906aeb5113
Reviewed-on: https://gerrit.instructure.com/13756
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Joe Tanner <joe@instructure.com>
This adds a migration tool that can import standards from
academic benchmarks, either by giving it a file, or by
using their API.
Test Plan:
* Run a migration for a specific authority
* It should import into the global group happily
refs #9866
Change-Id: If654681d60848e1233475f737dc2fadecacdbd98
Reviewed-on: https://gerrit.instructure.com/13421
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan:
* enable caching
* visit a few pages
* there should not be a db query with each request for
site admin and default accounts
Change-Id: I8bbd8026dea289d057edb7b22f8f5605ebc4b16f
Reviewed-on: https://gerrit.instructure.com/13438
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
fixes#7939
this change adds an account setting which tracks the sub-account responsible
for containing manually created courses. this was being tracked by name, which
caused duplication problems if the account was renamed or the locale was
changed.
test plan:
- in an account that already had a "Manually-Created Courses" sub-account
- create a new manual course and make sure it goes into that sub-account
- change the account locale to be non-english
- create another manual course and make sure it still goes there
- change back to english and rename the account to something else entirely
- create a final manual course and make sure it still goes to that sub-account
Change-Id: Iaa01eae15cf5e4c7707a049e704fb079f77e0a21
Reviewed-on: https://gerrit.instructure.com/13445
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
now that we also cache group permissions (in addition to course ones),
start grabbing the permissions in load_all_contexts. although we cache all
of them, only return ones that are requested (to keep js ENV etc. small)
slight refactor of conversations around permission stuff, and added the
ability to specify an :if check for a permission (i.e. the permission is
only on for a user if the policy says so *and* the :if method returns
true)
test plan:
n/a, see specs (new one, plus existing ones that exercise
load_all_contexts in its various capacities)
Change-Id: I82f4f71edf221c6c859a15156224d8e5b719edc5
Reviewed-on: https://gerrit.instructure.com/12983
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
This list is *NOT* complete, some items may have snuck in that I forgot
to note, and/or some of the noted items may not be completely functional
yet.
Specs need to be written around a lot of this, other specs will no doubt
need to be fixed.
Some things, particularly around LearningOutcomeGroups will need data
migrations that aren't there yet.
* remove LearningOutcome.non_rubric_outcomes? and replace with false
where invoked
* remove LearningOutcome.enabled? and replace with true where invoked
* remove never-taken branches
* remove the shared/aligned_outcomes partial and it's supporting
javascript, since it's now empty
* remove js handler for add_outcome_alignment_link and supporting
method since it only occurred in never-taken branches
* mix LearningOutcomeContext into Course and Account
* replace LearningOutcomeGroup.default_for(context) with
LearningOutcomeContext#root_outcome_group
* rename LearningOutcome#content_tags to LearningOutcome#alignments
* rename LearningOutcomeGroup#content_tags to
LearningOutcomeGroup#child_links, and properly restrict
* remove ContentTag[Alignment]#rubric_association_id, add
ContentTag[Alignment]#has_rubric_association? that looks at the
presence of the content's rubric_association_id
* condition off the assignment having a rubric_association rather than
filtering tags by has_rubric_association (which just looks back at
the assignment). all or none of the assignment's alignments are
forced to have the association (via the assignment). this was true in
practice before, is now codified (and more efficient)
* rename AssessmentQuestionBank#learning_outcome_tags to
AssessmentQuestionBank#learning_outcome_alignments
* rename Assignment#learning_outcome_tags to
Assignment#learning_outcome_alignments
* rename Rubric#learning_outcome_tags to
Rubric#learning_outcome_alignments
* move/rename (Course|Account)#learning_outcome_tags to
LearningOutcomeContext#learning_outcome_links
* move/rename Account#learning_outcomes (corrected) and
Course#learning_outcomes to
LearningOutcomeContext#linked_learning_outcomes
* move/rename Account#created_learning_outcomes and
Course#created_learning_outcomes to
LearningOutcomeContext#created_learning_outcomes
* clarify and correct usage of linked_learning_outcomes vs.
created_learning_outcomes
* move/rename (Account|Account)#learning_outcome_groups to
LearningOutcomeContext#learning_outcome_groups
* remove unused Account#associated_learning_outcomes
* just remove one link to a learning outcome when deleting
* merge Account#has_outcomes?, Course#has_outcomes? and
Course#has_outcomes into LearningOutcomeContext#has_outcomes?, add a
use in Context#active_record_types
* kill LearningOutcomeGroup#root_learning_outcome_group (unused)
* rename LearningOutcomeResult#content_tag to
LearningOutcomeResult#alignment
* kill unused (and broken) OutcomesController#add_outcome_group
* kill unused OutcomesController#update_outcomes_for_asset
* kill unused OutcomesController#outcomes_for_asset
* remove unused (outside specs, correct specs)
AssessmentQuestionBank#outcomes=
* remove unused ContentTag#learning_outcome_content
* replace ContentTag.learning_outcome_tags_for(asset) (only ever called
with asset=an assignment) with call to
Assignment#learning_outcome_alignments
* remove unused ContentTag.not_rubric
* remove (now) unused ContentTag.include_outcome
* remove unused LearningOutcome#learning_outcome_group_associations
* avoid explicit use of ContentTag in outcome-related specs
* replace LearningOutcomeGroup#learning_outcome_tags with
LearningOutcomeGroup#child_outcome_links (and only use for outcome
links; not tags for child groups)
* split ContentTag#create_outcome_result into
Submission#create_outcome_result,
QuizSubmission#create_outcome_result, and
RubricAssessment#create_outcome_result. fix some bugs along the way
* refactor ContentTag.outcome_tags_for_banks and some code from
QuizSubmission#(track_outcomes|update_outcomes_for_assessment_questions)
into QuizSubmission#questions_and_alignments
* refactor RubricAssociation#update_outcome_relations and
Rubric#update_alignments into LearningOutcome.update_alignments
* don't use ContentTag#rubric_association with outcome alignments; use
the tag's content's rubric_association in its place (they should have
been equal anyways)
* refactor LearningOutcome.available_in_context and
@context.root_outcome_group.sorted_all_outcomes (only time
sorted_all_outcomes is used) into
LearningOutcomeContext#available_outcomes and
LearningOutcomeContext#available_outcome
* overhaul LearningOutcomeGroup#sorted_content and rename to
LearningOutcomeGroup#sorted_children. it not returns ContentTags
(outcome links) and LearningOutcomeGroups, vs. LearningOutcomes and
LearningOutcomeGroups; fix usages appropriately
* fix UI for arranging/deleting outcome links and groups within a group
to refer to the outcome link rather than the outcome
Change-Id: I85d99f2634f7206332cb1f5d5ea575b428988d4b
Reviewed-on: https://gerrit.instructure.com/12590
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jacob Fugal <jacob@instructure.com>
fixes#9993; fixes#10034
we were caching the user's common account chain, but this was occasionally
caching all of the accounts loaded associations, which wasn't unmarshaling
properly.
the new strategy is to cache the global asset paths that should be used for
different contexts.
test plan:
- no visual changes in sub-account branding
- shouldn't generate any caching errors (these were intermittent and we never
had solid steps to reproduce)
Change-Id: I37cc58a609ed7f90d967d6ebde74e849c754c0e8
Reviewed-on: https://gerrit.instructure.com/13017
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
disabling canvas auth also force-disables open registration, and
makes LDAP auth act like full delegated auth (CAS or SAML)
test plan:
* configure LDAP, CAS, or SAML. MAKE SURE YOU CAN LOG IN.
* go to account settings, and disable "Canvas Authentication"
* open registration should no longer show up on account settings
page (after saving)
* ensure you can no longer log in with your Canvas credentials, but
you can with LDAP, CAS, or SAML credentials.
* remove LDAP, CAS, or SAML from the account
* "Canvas Authentication" should no longer show up on the account
settings page, open registration should
* your Canvas credentials should start working again
* add LDAP, CAS, or SAML back
* "Canvas Authentication" should be back on in account settings
Change-Id: Ic7475623e5139bb545a87d8e5b1014dabaf4e854
Reviewed-on: https://gerrit.instructure.com/12850
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan:
* enable optional MFA, and check the following:
* normal log in should not be affected
* you can enroll in MFA from your profile page
* you can re-enroll in MFA from your profile page
* you can disable MFA from your profile page
* MFA can be reset by an admin on your user page
* when enrolled, you are asked for verification code after
username/password when logging in
* you can't access any other part of the site directly until
until entering your verification code
* enable required MFA, and check the following
* when not enrolled in MFA, and you log in, you are forced to
enroll
* you cannot disable MFA from your profile page
* you can re-enroll in MFA from your profile page
* an admin (other than himself) can reset MFA from the user page
* for enrolling in MFA
* use Google Authenticator and scan the QR code; you should have
30-seconds or so of extra leeway to enter your code
* having no SMS communication channels on your profile, the
enrollment page should just have a form to add a new phone
* having one or more SMS communication channels on your profile,
the enrollment page should list them, or allow you to create
a new one (and switch back)
* having more than one SMS communication channel on your profile,
the enrollment page should remember which one you have selected
after you click "send"
* an unconfirmed SMS channel should go to confirmed when it's used
to enroll in MFA
* you should not be able to go directly to /login/otp to enroll
if you used "Remember me" token to log in
* MFA login flow
* if configured with SMS, it should send you an SMS after you
put in your username/password; you should have about 5 minutes
of leeway to put it in
* if you don't check "remember computer" checkbox, you should have
to enter a verification code each time you log in
* if you do check it, you shouldn't have to enter your code
anymore (for three days). it also shouldn't SMS you a
verification code each time you log in
* setting MFA to required for admins should make it required for
admins, optional for other users
* with MFA enabled, directly go to /login/otp after entering
username/password but before entering a verification code; it
should send you back to the main login page
* if you enrolled via SMS, you should not be able to remove that
SMS from your profile
* there should not be a reset MFA link on a user page if they
haven't enrolled
* test a login or required enrollment sequence with CAS and/or SAML
Change-Id: I692de7405bf7ca023183e717930ee940ccf0d5e6
Reviewed-on: https://gerrit.instructure.com/12700
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
fixes#9768
test plan:
* create two accounts via SIS that reference each other (you'll need
to add the first account two times, once valid, the second changing
its parent to the other account)
* one of the accounts should cause a warning about a loop
Change-Id: Ieb1710a1d0b7d11c652d8e000dcf33b63d2b187f
Reviewed-on: https://gerrit.instructure.com/12749
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
allow sub accounts to include their own global scripts and stylesheets. if
global includes are enabled on the root account, root account administrators
will have an option to enable them for immediate child accounts. those child
accounts can then choose to enable them for their sub-accounts, and so on down
the chain.
these includes are added to the page in order from highest to lowest account,
so sub-accounts are able to override styles added by their parents.
the logic for which styles to display on which pages is as follows:
- on account pages, include all styles in the chain from this account up to the
root account. this ensures that you can always see styles for account
X without any sub-account overrides on account X's page
- on course/group pages, include all styles in the chain from the account which
contains that course/group up to the root
- on the dashboard, calendar, user pages, and other pages that don't fall into
one of the above categories, we find the lowest account that contains all of
the current user's active classes + groups, and include styles from that
account up to the root
test plan:
- in a root account, create two sub-accounts, create courses in each of them,
and create 3 users, one enrolled only in the first course, one only in the
second course, and one enrolled in both courses.
- enable global includes on the root account (no sub-accounts yet) add files,
and make sure all three students see them.
- now enable sub-account includes, and add include files to each sub-account
- make sure both users in course 1 see include for sub-account 1
- make sure user 1 sees include for sub-account 1 on her dashboard, but user
3 does not.
Change-Id: I3d07d4bced39593f3084d5eac6ea3137666e319b
Reviewed-on: https://gerrit.instructure.com/12248
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Site admins can manage developer keys. This provides a
basic interface for allowing key management. Admins can
add new keys, edit existing keys, etc. Also adds an
icon url for each key. If keys have an icon url, then
the oauth screen will display this icon to end-users.
test plan:
- manually add a key from the "developer keys" page in
the site admin account
- confirm that the key is created correctly
- edit the key
- confirm that the changes persist
- delete the key
- confirm that the key is properly deleted
- create more than 15 developer keys
- confirm that the page properly paginates
- set an icon url for a key
- do the oauth dance
- confirm that the icon appears in the approval step
- do the oauth dance for a key without an icon url
- confirm that no icon appears in the approval step
Change-Id: I5d64d14974fdcef8be21c6aa84ab13f681217bd7
Reviewed-on: https://gerrit.instructure.com/10979
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
fixes#9386
Test plan:
* Click on the 'Profile' link in the header, you should go to the
profile settings page
- There should not be a 'Profile' tab in the left nav
* Enable the 'enable_profiles' account setting for your user's
account. Clicking on 'Profile' should now take you to the new-style
profile page
Change-Id: Ie2bcd41ae98ec93d6a423e00936d79fac291be0c
Reviewed-on: https://gerrit.instructure.com/12132
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
adds (root) account-level setting for (default) user file quotas. defaults
to 50 MB.
test plan:
1. on a root account, change the default user quota to something other
than 50 MB (e.g. 1 MB)
2. as a user in that account:
1. go to /users/self/files/quota . you should see the new quota
2. attempt to upload files. once you have hit/exceeded the quota, you
should not be able to upload additional files
3. as a user in multiple (root) accounts:
1. go to /users/self/files/quota . your quota should be the sum of the
root account user quotas
2. attempt to upload files. once you have hit/exceeded the quota, you
should not be able to upload additional files
note that the previous behavior does not change in that one file can exceed
your quota. e.g. if your quota is 1 MB, you can upload a 2 MB file. only
then will you be prevented from uploading additional files
Change-Id: If7f5903fb54eb2b62d80a2b4ee8adfcc48a63683
Reviewed-on: https://gerrit.instructure.com/12005
Reviewed-by: Joe Tanner <joe@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
refs #9130
Test plan:
Open the calendar in an account that hasn't had calendar2 enabled.
It should open up calendar2.
Change-Id: I2d6dac25fa5bc01892914f7a615a886d8d31a6eb
Reviewed-on: https://gerrit.instructure.com/12012
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
refs #9000
Also allow services to be specified as "service" or "setting" so that
they'll show up under the relevant heading in the account settings ui.
Sort the services by name, as well, so their ordering isn't random on
every page reload.
test plan: visit the account settings page, and verify you can still
change service settings as before (including the User Avatar service,
which should now be moved to the Features portion of the page).
Change-Id: Ib4542015659c34de719c5a2fd8d281696fa35cf8
Reviewed-on: https://gerrit.instructure.com/11603
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Brian Palmer <brianp@instructure.com>
adds button (and underlying pref/endpoint) so users can opt in to (or out
of) the new dashboard. button appears on old and new dashboard and group
pages.
test plan:
1. opt in to the new dashboard
2. you should see the new dashboard (and new group page)
3. opt out
4. you should see the old dashboard (and old group page)
Change-Id: I151f3a3979ddc3e18e7e0dbf97d271ace91b3235
affected pages:
- courses in this account /accounts/:id
- account users /accounts/:id/users/:id
- course home page /courses/:id
test plan:
- ensure there is a course with a term other than the default term
- look at the affected pages to verify that the term name is visible
Change-Id: I681bd20545a462643564899511adab0b8b71d3db
Reviewed-on: https://gerrit.instructure.com/9852
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
test plan: go to /accounts/X (where X is Account.site_admin), and verify
the Plugins and Jobs tabs show on the left if you have the correct
permissions. Go to both those pages and verify the breadcrumbs.
Change-Id: Id63492cf0cc753151750570106cc87b5af2d73f7
Reviewed-on: https://gerrit.instructure.com/8204
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
migrate most stuff to :manage_site_settings permissions, use the
already exist :view_error_reports permission as appropriate, and add
a :read_messages permission
also remove one-liner helpers whose only purpose was to default to
the now defunct permission
test plan:
* ensure site admins have no reduced functionality by default
Change-Id: I7e4d5f9a43fd12f96d76add451c7e8ffc03fd553
Reviewed-on: https://gerrit.instructure.com/9954
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
it's now useful to be able to create a user with a specific non-email
pseudonym to auth against an external IdP
test plan:
* go to /accounts/site_admin, and see the tab
Change-Id: I06475656a6244659a84193cdb277f7c0ebe14d0e
Reviewed-on: https://gerrit.instructure.com/9957
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
test plan:
* run all specs in spec/selenium/content_migrations_spec.rb serially
Change-Id: Ic23b718b296a8a205eed654a77c37723a8111329
Reviewed-on: https://gerrit.instructure.com/9851
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
allows course admins to view the course from a student perspective. this is
accessible from a button on the course/settings page. They should be able to
interact with the course as a student would, including submitting homework and
quizzes. Right now there is one student view student per course, so if the
course has multiple administrators, they will all share the same student view
student.
There are a few things that won't work in student view the way the
would for a normal student, most notably access to conversations is disabled.
Additionally, any publicly visible action that the teacher takes while in
student view will still be publicly visible -- for example if the teacher posts
a discussion topic/reply as the student view student, it will be visible to the
whole class.
test-plan:
- (the following should be tried both as a full teacher and as
a section-limited course admin)
- set up a few assignments, quizzes, discussions, and module progressions in
a course.
- enter student view from the coures settings page.
- work through the things you set up above.
- leave student view from the upper right corner of the page.
- as a teacher you should be able to grade the fake student so that they can
continue to progress.
- the student should not show up in the course users list
- the student should not show up at the account level at all:
* total user list
* statistics
Change-Id: I886a4663777f3ef2bdae594349ff6da6981e14ed
Reviewed-on: https://gerrit.instructure.com/9484
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Cody Cutrer