refs #6199, #6177
makes it easier for a plugin to modify the logic. also removed dummy
method in Account that is never hooked into.
Change-Id: I87e2cad5172f6dece4448d61dc4681a94c44cecb
testplan: login
Reviewed-on: https://gerrit.instructure.com/6982
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
test plan:
create a user with a sortable name other than what is automatically
inferred; make sure it displays correctly in the users list for the
account
Change-Id: I12528436571ffdd211d6d2719eb1789d9afffdd2
Reviewed-on: https://gerrit.instructure.com/6732
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
By properly configuring external tools (see
/spec/models/course_spec/rb:898 for examples) they can
be added as left-side navigation links to a course,
an account, or to the user profile section of Canvas.
testing notes:
- you have to manually set options on the external tool:
- for user navigation the tool needs to be created on the root account
with the following settings:
{:user_navigation => {:url => <url>, :text => <tab label>} }
(there are also some optional language options you can set using
the :labels attribute)
- for account navigation it's the same
- for course navigation it's the same, except with :course_navigation
there's also some additional options:
:visibility => <value> // public, members, admins
:default => <value> // disabled, enabled
test plan:
- configure a user navigation tool at the root account level,
make sure it shows up in the user's profile section
- configure a course navigation tool at the account level,
make sure it shows up in the course's navigation
- configure a course navigation tool at the course level,
make sure it shows up in the course's navigation
- make sure :default => 'disabled' course navigation tools don't
appear by default in the navigation, but can be enabled on
the course settings page
- make sure :visibility => 'members' only shows up for course members
- make sure :visibility => 'admins' only shows up for course admins
- configure an account navigation tool at the account level,
make sure it shows up in the account's navigation, and
any sub-account's navigation
Change-Id: I977da3c6b89a9e32b4cff4c2b6b221f8162782ff
Reviewed-on: https://gerrit.instructure.com/5427
Reviewed-by: Brian Whitmer <brian@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
also, make the random assignment happen on the server via an ajax call.
before, it would make one ajax call per student assigned, which is
rather inefficient when there are many students to assign.
fixes#6099
Change-Id: I89e5059fa1bd42b1a25e5cb88d552841c426530a
Reviewed-on: https://gerrit.instructure.com/6576
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Since SAML/CAS users are unlikely to be using email addresses as logins, we
now show the "Login:" field always in the Add User dialog for them. They can
also specify a login label in their authentication configuration, and it
defaults to Login.
Change-Id: Idcfd876d947eb0ca104a6681a02ac11f993302ce
Reviewed-on: https://gerrit.instructure.com/6566
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
* expose sortable name directly to the user
* don't downcase it
* use a LOWER(sortable_name) index for postgres
* set sortable name as "last_name, first_name" explicitly for SIS imports
* populate sortable name intelligently in the UI
Change-Id: I476641f4817e27a11b573d91f102c5a74d3eba26
Reviewed-on: https://gerrit.instructure.com/6512
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
fixes#5573, #5572, #5753
* communication channels are now only unique within a single user
* UserList changes
* Always resolve pseudonym#unique_ids
* Support looking up by SMS CCs
* Option to either require e-mails match an existing CC,
or e-mails that don't match a Pseudonym will always be
returned unattached (relying on better merging behavior
to not have a gazillion accounts created)
* Method to return users, creating new ones (*without* a
Pseudonym) if necessary. (can't create with a pseudonym,
since Pseudonym#unique_id is still unique, I can't have
multiple outstanding users with the same unique_id)
* EnrollmentsFromUserList is mostly gutted, now using UserList's
functionality directy.
* Use UserList for adding account admins, removing the now
unused Account#add_admin => User#find_by_email/User#assert_by_email
codepath
* Update UsersController#create to not worry about duplicate
communication channels
* Remove AccountsController#add_user, and just use
UsersController#create
* Change SIS::UserImporter to send out a merge opportunity
e-mail if a conflicting CC is found (but still create the CC)
* In /profile, don't worry about conflicting CCs (the CC confirmation
process will now allow merging)
* Remove CommunicationChannelsController#try_merge and #merge
* For the non-simple case of CoursesController#enrollment_invitation
redirect to /register (CommunicationsChannelController#confirm)
* Remove CoursesController#transfer_enrollment
* Move PseudonymsController#registration_confirmation to
CommunicationChannelsController#confirm (have to be able to
register an account without a Pseudonym yet)
* Fold the old direct confirm functionality in, if there are
no available merge opportunities
* Allow merging the new account with the currently logged in user
* Allow changing the Pseudonym#unique_id when registering a new
account (since there might be conflicts)
* Display a list of merge opportunities based on conflicting
communication channels
* Provide link(s) to log in as the other user,
redirecting back to the registration page after login is
complete (to complete the merge as the current user)
* Remove several assert_* methods that are no longer needed
* Update PseudonymSessionsController a bit to deal with the new
way of dealing with conflicting CCs (especially CCs from LDAP),
and to redirect back to the registration/confirmation page when
attempting to do a merge
* Expose the open_registration setting; use it to control if
inviting users to a course is able to create new users
Change-Id: If2f38818a71af656854d3bf8431ddbf5dcb84691
Reviewed-on: https://gerrit.instructure.com/6149
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
also rearrange account settings slightly so that stuff that doesn't apply
to non-root accounts doesn't show for them
Change-Id: I568887a30cbf923c976e7c5bbac1036bb8e88659
Reviewed-on: https://gerrit.instructure.com/6012
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
Just use Rails.cache.fetch directly. This fixes some problems that
find_cached wasn't fully serializing the object.
Also, be sure to change cache keys so that we don't get data back
using the old format.
Change-Id: I8beea2f2ba446a97249a495789b25c3a71de420e
Reviewed-on: https://gerrit.instructure.com/5857
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
these are syntax errors in 1.9.x
Change-Id: I7cbd66643cb371e4be9f8da0365bf1e988ee5de8
Reviewed-on: https://gerrit.instructure.com/5833
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
(note that this is the only place that assert_by_email is used)
Change-Id: I5ed8985a5a84940e50b403b3753f9102bad23164
Reviewed-on: https://gerrit.instructure.com/5772
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Changed the "feedback" link to say "help" instead, and put a
dialog in front of the original feedback dialog which helps
point users to additional useful resources.
Also added account#custom_feedback_links so that plugins can
optionally add other useful links to this help dialog.
fixes#177
Change-Id: I31e855cbf83475006dd530cd027aff123a75d56a
Reviewed-on: https://gerrit.instructure.com/5310
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
push the unique back to the database, so that it's consistent with
pagination
Change-Id: Ibf66de841fb09ea6b0f8b4c4cd8b468dee6ded30
Reviewed-on: https://gerrit.instructure.com/5630
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
* avoid joining with users just to get the count of associated_users
Change-Id: I79635e7bd189d361fb9f1deee73806ffc40d40db
Reviewed-on: https://gerrit.instructure.com/5321
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
phased out AssessmentQuestion#context, did some ground work for #5026
and #5027
Change-Id: Ice4567a0f069dd49da8ce57bf0c8325b0b062115
Reviewed-on: https://gerrit.instructure.com/5303
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
Avoid n queries for sub_account counts and course counts; instead do
a single query of each type for all visible accounts (if necessary;
sub_account count might be inferred from loaded sub_accounts)
Change-Id: I46aa607f485eda8e48effefe0c5ae72ee383ac80
Reviewed-on: https://gerrit.instructure.com/5295
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
also tweaked named_context_url to work better with UserProfile
contexts
Change-Id: If16ef16db507c8713436d0d88a1867f206ecdf48
Reviewed-on: https://gerrit.instructure.com/5225
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
* Daily job to evaluate alerts
* Spawns a new job for each root account (for parallelization).
It could be broken down to per-course level if needed (i.e.
if there is a *huge* root account).
* Evaluating criteria at a course level using efficient queries.
* UI for CRUD on alerts
* Render existing alerts
* Delete existing alerts
* Create a new alert
* CRUD for criteria, recipients, repetition
* Validations
* Improve instructure_helper's formErrors to support passing errors
for specific elements
* Improve Rails' :include to be able to :exclude an :include
inherited from a named scope
* Specs!!
* Note that we want to slowly roll this out, so there is a setting on
root accounts to enable it
So I ran an alert with just an interaction criterion on a test
cluster against 50,000 courses, and it took less than 10 minutes
without any parallelization. That seems like acceptable
performance to me (since there are only just over 3000 courses
in production that would even be elligible to have alerts sent
right now). Of course, that's probably skewed because I'm sure
a bunch of those 50,000 courses were essentially empty.
Change-Id: Ie028ef206c9155b9a72fb2a820f3e0e516de562a
Reviewed-on: https://gerrit.instructure.com/4799
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
* Manually cache account chains (query cache gets dumped after every
update or delete)
* Use batch queries and preloads to make the number of queries
constant wrt how many users are getting updated
* Simplify calculation - find the root account ids, and merge the
account chains together
* Fix depth to be defined as the minimum depth to reach that account
(rather than whichever path happened to be processed last)
* Add incremental mode to only add accounts, rather than re-calculate
all associations (only for User)
* Don't auto-create the default section during
update_account_associations; it costs a query and possibly an
insert, causes angst with schools that don't want it, etc.
Instead, always create associations against a 'nil' section so
that a course has the proper associations.
Change-Id: I7d476d45f41d9c3e382fac9b5c0c0aaa5369b956
Reviewed-on: https://gerrit.instructure.com/5135
Tested-by: Hudson <hudson@instructure.com>
Tested-by: Selenium <selenium@instructure.com>
Reviewed-by: JT Olds <jt@instructure.com>
Basically, change from using recursive calls to a single flattened call.
Interestingly, this change caught a bug in the become user spec, so
apparently the old code wasn't quite working as intended.
Change-Id: I20fce8dbc5ca7c4797a4f8bd929202aaf8a96f9c
Reviewed-on: https://gerrit.instructure.com/5062
Tested-by: Hudson <hudson@instructure.com>
Tested-by: Selenium <selenium@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Refs #4952
* Fix saving role overrides for Site Admin account roles
* Add the following permissions:
* read_course_list (for listing or searching courses)
* view_statistics (for viewing account statistics)
* manage_user_notes (instead of being implied-ish by read_reports)
* Hide UI elements that provide access to features that are not
allowed
* Remove lots of not applicable stuff from Site Admin settings
Change-Id: I7414368b472ba655d04118db30c1bb46542deb37
Reviewed-on: https://gerrit.instructure.com/5054
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
* Remove the show_create_course_button helper, and refactor into
Account's set_policy block
* Don't implicitly give any admin :manage_courses rights (since it
can be revoked)
* Check for the correct permission on the correct account in the
GettingStartedController and CoursesController#copy
Change-Id: I6769d20c299d7e34ea83a79cdb6fab0d588122dc
Reviewed-on: https://gerrit.instructure.com/5027
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
The strategy is that if a term is named "Default Term", that will be a marker
that it's the default term in any language. When displaying the term name, we
check if it == "Default Term" and show the translated version if so. We also
do some special-casing on saving a new term name to make sure the translated
term name doesn't get saved as the new name.
Change-Id: Ic2b6659f75ef5e56bb5aa5fb7b241bba77dee445
Reviewed-on: https://gerrit.instructure.com/4905
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
At this point, nobody should be writing quotas as bytes anymore, so we mass
convert the remainder to bytes and get rid of the backwards-compatible code.
Change-Id: Ic5d6f8c8eaed947aef48dd7b1da348158f4ea2a4
Reviewed-on: https://gerrit.instructure.com/4276
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
This was already a small issue if the job queue was on a different
database driver than the main database, and it'll become more important
as more AR connections are introduced.
Change-Id: I204becadd32bb935df096e8c937a04bb6962f0b2
Reviewed-on: https://gerrit.instructure.com/4601
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Basically, don't call a bazillion procs everytime you check_policy;
just the "given" statement. Everything else is evaluated just once,
and cached on the class. This does lose functionality (the ability
to access the instance inside of set_policy, and set methods), but
none of it was currently in use.
Change-Id: I736879d98beb4115a2e8c492931c755076291d08
Reviewed-on: https://gerrit.instructure.com/4665
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: JT Olds <jt@instructure.com>
Cody Cutrer