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>
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>
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>
test plan:
* set "teachers can create courses" but *not* "users with no
enrollments can create courses" on an account
* as a site admin, ensure you can masquerade as a teacher in that
account
Change-Id: Id63ac979aafc42b70b3303dc4cbe9c924582f448
Reviewed-on: https://gerrit.instructure.com/9731
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
basically for detailed reports, have a row per account, instead of
stuffing everything into one massive hash with every account
test plan:
* ensure that the account statistics page still works
* ensure that the statistics update when the delayed job runs
Change-Id: I2d4c9ff5a86c8df6d82097aa4f0203a0f55ddb2d
Reviewed-on: https://gerrit.instructure.com/9565
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Cody Cutrer <cody@instructure.com>
Removes unused methods and associations from models, and removes the
PageViewRange model completely, which is no longer used.
test plan:
* run the specs
* verify that no active page-view-related functionality was inadvertently removed
Change-Id: I8522d151555db64a0ad2548334ae642f9fefd54e
Reviewed-on: https://gerrit.instructure.com/9324
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
also clean things up a bit
test plan:
* create an announcement in site admin
* verify it's in your dashboard
* go to a different shard
* verify you still see the announcement
* close it
* refresh, and make sure it's still gone
* go back to the default shard
* verify the announcement is not on your dashboard there, either
Change-Id: Id3f95ea41d4187b5995c98e059b3ac08b0735e69
Reviewed-on: https://gerrit.instructure.com/8942
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
change requirements from needing :become permission in all accounts
associated with the user, to only needing become in @domain_root_account.
also relax the masquerade-as-other-admin requirements to allow masquerading
as an admin that has less than or equal access as you
test plan:
* ensure that an account admin can masquerade as a user that belongs to
multiple accounts (but only within the account the admin has permission
to)
* ensure that an account admin can masquerade as another account admin
* ensure that an admin in a restricted role but is allowed to masquerade
cannot masquerade as a full admin
Change-Id: Id2e1c4bc33d94be3b10f524fbb1633a7478749a0
Reviewed-on: https://gerrit.instructure.com/8844
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
and adjust all places we expose SIS IDs to check this permission
instead of manage_users. Adjust permissions UI to show the account
permissions section even for course level roles.
closes#7112
test plan:
* grant teacher read sis, but not manage students. ensure secondary ID
is populated in gradebook2
Change-Id: I6293a91971aa2bc13425839ad52dd59b90bfd3c2
Reviewed-on: https://gerrit.instructure.com/9052
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Cody Cutrer <cody@instructure.com>
closes#7059, #7411
preferred is a compromise between open registration and closed
registration. if a single user is found, that user is found without
introducing any temporary user to allow user disambiguation. if no
users are found, or multiple users are found, it's the same behavior
as open registration.
as part of this, the "only search existing users" checkbox has been
removed. instead, preferred searching will be used in the following
cases:
* adding an admin, and open registration is enabled
* adding an admin, open registration is disabled, and the user
has permission to create new users
* adding a user to a course, open registration is enabled, and
delegated authentication is in use
* adding a user to a course, open registration is disabled, and
the user has permission to create new users
the notable case that preferred searching is not used, and the
user would want to use search existing users is open registration
enabled, and adding a user to a course. in this case, a temporary
user will be created instead of sending the invitation to the
existing user. however, the end user experience is identical
(invitation sent to e-mail, invitation visible in the same locations
in the UI), with the small exception that the end user gets the
opportunity to create a separate account if desired (but not
preferred).
test plan:
* go through each of the cases above for a user that doesn't exist
yet, a single matching user exists, or multiple users exist.
it should behave as described above
Change-Id: Idbc7fe23bfc7430b4cd25f7981f5dc08b9e4ffda
Reviewed-on: https://gerrit.instructure.com/8966
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
test plan:
* access a non-default shard as site admin
* should not have any troubles
Change-Id: Idcc10ee6bd177a7aae9a100bd2bc91ad1f0a759f
Reviewed-on: https://gerrit.instructure.com/8837
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
fixes#7166
test plan:
* create a user in another account
* login with that user at the default account
* should get a warning about needing to log in
at the correct account
Change-Id: I976d51f0e3f18f0b4a9c7303bf9f71668c8c1f2b
Reviewed-on: https://gerrit.instructure.com/8745
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
test plan:
* set a custom css for site admin
* other root accounts should pick up that custom css
immediately without restarting the server
Change-Id: Ief1356f7a67b3ea461656bc8f6a9bf1938566b91
Reviewed-on: https://gerrit.instructure.com/8522
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
still turn open registration off when you enable delegated
authentication, and display an extra warning by the open registration
checkbox to show them why it's a bad idea
test plan:
* enable open registration for an account
* enable cas for the account
* open registration should be disabled, and have a warning icon
next to it, but you can still enable it
Change-Id: I65d54c867da5b6afbd7038b5d7ca33e0079c5726
Reviewed-on: https://gerrit.instructure.com/8406
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
fixes#6769, #6939
Test plan:
- enable caching with redis or memcached
- log in to a course page
- use the api to add an external tool with course navigation (see the
redmine bug)
- refresh (you should see the external tool in the navigation)
- delete the external tool
- refresh (nav item should be gone)
Change-Id: I734bd726818ea84ffe333597eb0197db2200c235
Reviewed-on: https://gerrit.instructure.com/8141
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
test plan:
* log in with site admin credentials at an account on a different shard
Change-Id: Ibdb26b345b409cbbd61cfdb45af563e8cdd0c138
Reviewed-on: https://gerrit.instructure.com/8075
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Tom Metge <tom@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
we were showing outcomes for associated accounts for course contexts but not
sub-account contexts. now we are.
test plan:
- create an account level outcome
- create a sub-account level rubric
- click find outcome criteria
- ensure that the account level outcome is available
Change-Id: I64a8feacadecd3bbc12eedc3c1c5ccea9b16360c
Reviewed-on: https://gerrit.instructure.com/8125
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
added a domain-account-level setting controlling whether or not the
scheduler is enabled. when it is turned on,
1. /calendar requests redirect to /calendar2 by default
2. both the new and old calendar pages include a link to the other
calendar (sets a user preference so that it redirects correctly in
the future)
Change-Id: I1817c7f8e9075282ab1988088f5c0ef8d63325f6
Reviewed-on: https://gerrit.instructure.com/7840
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
does a few things: consolidate the help
and support links at the bottom of the page
into 1 and calls them "help"
allows a school to set their own custom
help links to show in the help dialog so
they can link to their campus LMS support
in addition to our help options.
also cleans up the flow for teacher feedback and
submitting a ticket.
test plan:
* go to the account settings page of a root account
* you should see an option there to set up "custom
help links", create a couple
* click the help link in the footer and the top left,
a dialog should appear with the old options as well
as the ones you set up.
* as a student, click the help link, click the teacher
feedback option, fill out the form, the teacher AND TA's
in that class should have got a canvasation.
* click the file a ticket option, fill out the form,
zendesk should have a new issue with the
* and of course the specs in helpDialogSpec.coffee and
help_dialog_spec.rb should pass
Change-Id: If2d841c00b28ece55eb118085ee8728b0de96c08
Reviewed-on: https://gerrit.instructure.com/7153
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
just make Account#root_account return self if it is a root account
test plan:
* run existing specs
Change-Id: Iff3f621bb722e0f5e90659c4b711d48d8d3c510f
Reviewed-on: https://gerrit.instructure.com/7700
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
in preparation for having Account#root_account return self if it is a root account
also remove some unused named scopes
test plan:
* run specs
Change-Id: I8c78c45f0d2f6002021bc2bba594de8bcbaa086b
Reviewed-on: https://gerrit.instructure.com/7698
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Bracken Mosbacker