affects: pseudonyms_controller, api
test plan:
* as an authorized user, make request and verify that
requested user's pseudonyms for given account are
returned;
* make same request for a user with multiple pseudonyms
in a single account and verify that all are returned;
* make request as an unauthorized user and verify that
401 is returned.
Change-Id: I0633e79108c0c6e626cf52f5d39d91a9e67edbb6
Reviewed-on: https://gerrit.instructure.com/8025
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
we are seeing an issue with some requests where the account association
info in a course loaded with these enrollments is getting a proc stored
on it, so that it can't be Marshal'd and the caching throws an error.
We're still investigating the cause, but this fixes up the errors.
fixes#6867
Change-Id: Ibc24e7583d7f3a4f1f4362680f6a2c080a53ba53
Reviewed-on: https://gerrit.instructure.com/8051
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
when a user is enrolled in one or more courses, we now give the query
planner a more efficient way of finding rows in the course subselect in
User#messageable_users. the new condition is redundant (and less
restrictive than the course_sql ones), but it ensures the planner will
use the index on enrollments.course_id and then filter on the other
fields.
the performance gains are most relevant in mysql when there are multiple
conditions in course_sql (from ~4s down to <0.01s)
test plan:
ensure the various course_sql paths work (e.g. section visibility).
existing specs should already cover these different flows
Change-Id: I11d41daa1134146abd2b099be24e873d47ef567b
Reviewed-on: https://gerrit.instructure.com/7450
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jacob Fugal <jacob@instructure.com>
test plan: run the migration
Change-Id: I75184edd64ddee384de485c443d4c7eee45cc26f
Reviewed-on: https://gerrit.instructure.com/7895
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@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>
so that it's case insensitive
also fix some latent CommunicationChannel.find_or_initialize_by_path
discovered by specs for this
test plan:
* run the specs
* use forgot password with a username that differs in case
* self-register a new user multiple times (without confirming)
with e-mail addresses that differ in case
Change-Id: I476325f591c997fc8d50d5f38480177f732f07a7
Reviewed-on: https://gerrit.instructure.com/7724
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@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>
test plan:
* create a user via SIS import with an e-mail address
* add a different e-mail address to the user
* re-import the user via SIS, and set their e-mail address
to the second e-mail you added, but with a different case
* the user should have a single e-mail address, the one set
in the second SIS import
Change-Id: Iab6b16e0b37cfb8caac3faa453be570b99621a9e
Reviewed-on: https://gerrit.instructure.com/7784
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
only adds the creation mechanism requested by #6182 for now
test-plan:
- try the API action to create a new admin role specifying
explicit/enabled/lock for some or all permissions
- try without giving a role name; should fail
- try giving an already used role name; should fail
- try using a reserved role name; should fail
Change-Id: I3b38247dccb704da694b0fd32df16cdd63df6810
Reviewed-on: https://gerrit.instructure.com/7553
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
new api available at /courses/:course_id/enrollments.
takes params:
* enrollment[user_id]
* enrollment[type]
* enrollment[workflow_state]
* enrollment[sis_source_id]
* enrollment[course_section_id]
* enrollment[limit_privileges_to_course_section]
affects: api
test plan:
* post all params and ensure that new enrollment is
created;
* post params with workflow_state of active and
verify that user is properly enrolled in course;
* post only user_id and type to verify that they
are only required params;
* post as unauthorized user to verify that 401 is
returned;
* post without user_id and/or type to verify that
error message is returned with 403 status.
Change-Id: I38e8df930efb2793bf0fa6a190f74f7fb37c7f78
Reviewed-on: https://gerrit.instructure.com/7375
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
enrollments previously had attribute
"limit_priveleges_to_course_section," but should
be spelled "privileges." replaced spelling in a
migration and across app.
affects: enrollments model
test plan:
* run specs
Change-Id: I15dcf9a023ead9bb1aed42abc2d1a7c233610840
Reviewed-on: https://gerrit.instructure.com/7431
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
tags the user as an admin in the account. the membership type may be
specified by a parameter, defaulting to AccountAdmin.
refs #6176
test-plan:
- create user through API; user should not be an admin
- POST to accounts/<account_id>/admins with that user_id; user should
now be an admin with membership type AccountAdmin
- create another user; POST to the same URL with that new user_id and a
membership_type specified; user should be an admin with membership
type matching the specified value.
Change-Id: I003c23324298d8c4214a31be0276067de4b9630b
Reviewed-on: https://gerrit.instructure.com/7443
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
test plan:
* set up an account with a course
* start netcat in listening mode
* enable the grade export plugin for the course to post to your netcat
instance
* visit the course as a teacher and set up some assignments with grades
* publish the grades
Change-Id: I7f5b6b264b70ffe06c38f29ad52ee1d4694e5a8d
Reviewed-on: https://gerrit.instructure.com/7279
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
testplan:
* make sure user models destroy transactionally
* create two users, one with a managed pseudonym and one without,
destroy both, and make sure that the failure to remove the managed
pseudonym makes the original user destroy bail
* make sure you can force delete a user with managed pseudonyms
* make sure that the account controller can destroy users with managed
pseudonyms
* make sure the users controller can destroy users with managed
pseudonyms only when the current user has permission
* also, make sure other user destruction functionality is unchanged
* make sure the users controller doesn't confirm a deletion when
the user doesn't have permission
* make sure we don't add a user destruction link when we know the
destruction will fail, but add it otherwise
Change-Id: Ie7c17de1134543fe55a3fdd03c60879925ecc50d
Reviewed-on: https://gerrit.instructure.com/6832
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
test plan:
* delete the last e-mail (via the console) for a user; their default
email should be blank now
Change-Id: I891f92170b52f24f79451d161d85047b83642ef6
Reviewed-on: https://gerrit.instructure.com/7252
Reviewed-by: JT Olds <jt@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
refs #6177, #6199
testplan: enable open registration and create a public,
self-enrollment course in a non-default account. create a user
in the default account, and enroll yourself in the course.
it should create a pseudonym for you in the second account.
Change-Id: I9f3ede2367d9ed6c20f3fc6a3f417ffd705f4974
Reviewed-on: https://gerrit.instructure.com/6995
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: JT Olds <jt@instructure.com>
refs #6177, #6199
test plan: (only relevant with a plugin that changes the behavior of
Pseudonym#works_for_account?; otherwise behavior should be unchanged)
enable open registration, invite a user that already exists, but
doesn't have a pseudonym in the account you're inviting them to. accept
as the existing user. they should now have a pseudonym in the target
account, copied from another account (preferentially the default account)
Change-Id: Ia86888524a5132387bb120df3262d7205d8e04d1
Reviewed-on: https://gerrit.instructure.com/6983
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: JT Olds <jt@instructure.com>
refs #5833
testplan: enable open registration, invite a user, have that user accept
and create a new account. Then invite with the same e-mail again,
login as the old user, and the invitation should be visible in the UI.
Accept the invitation, using the existing account, and the enrollment
should not be duplicated in the UI.
Change-Id: I64c886617f87f64bad35593229ee18434163ca7b
Reviewed-on: https://gerrit.instructure.com/6778
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@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>
also made general purpose methods for ranking (in ruby and sql) and
distinct on.
Change-Id: I4052472eb700cbdfe6b586ed6d12f61fd51bf08f
Reviewed-on: https://gerrit.instructure.com/6593
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>
just a bit of cleanup
Change-Id: I9535e38155b663c252514a08d65e75dba05719e9
Reviewed-on: https://gerrit.instructure.com/6482
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Features
--------
- The course menu shows the top 12 courses in
alphabetical order
- Users with > 12 courses will get a button to
edit the courses in their menu. Any courses
they add become favorites and will remain
in the course menu, and visa versa for those
they remove
- Users can reset the menu to the default 12
Noteworthy Ruby changes:
------------------------
- Added Favorites model
Favorites are polymorphic so we can save other
contexts as favorites in the future.
- Added FavoritesController
- Added User#menu_courses
This opens up some room to remove lots of code
that's used to build the main menu, but that
isn't in this commit. Gives a list of all the
courses that show up in the user's menu.
- Added User#favorites
- Added User#favorite_courses
- Refactored Enrollment::readable_type to cache
Noteworthy JavaScript changes:
------------------------------
- Jasmine specs are totally working
- Added CustomList constructor
- Added courseList (CustomList instance)
- Added objectCollection
Utility function that extends an array with
methods useful for collections of objects.
Used to manage the data state in CustomList
Fixes#4827
Change-Id: I59468e517ad07678741402bf9cf479cba1dfeaa1
Reviewed-on: https://gerrit.instructure.com/5982
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@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>
a user is allowed to be enrolled in the same section multiple times,
as long as it is for different roles
Change-Id: I662c8601d2cbac8af628cf3dcecb9fa8ad6fc527
Reviewed-on: https://gerrit.instructure.com/6375
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: JT Olds <jt@instructure.com>
uniquifies at the section level, not the course level, since it's
technically valid to be enrolled in multiple sections of the same
course
Change-Id: I2f87cf818ae5a55a7d6f8cad27b93117812da73c
Reviewed-on: https://gerrit.instructure.com/6363
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
We started hiding enrollments where the created_at
and updated_at fields were identical, assuming
it was SIS garbage data.
Turns out we were wrong. Reverting.
Change-Id: I9a479ea5f1ffde61365ab15aa36975e865be4e74
Reviewed-on: https://gerrit.instructure.com/6241
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
group categories can be flagged as self sign-up, and optionally
restricted to be section-homogenous. like normal groups and unlike
student-organized groups, a student may be in at most one self sign-up
group. but like student-organized groups and unlike normal groups,
students can assign themselves to the group of their choice. if the
section restriction is enabled, students can only be assigned (whether
by themselves or their teacher) to a group which is either empty, or
whose existing members are in the same section as the student.
also added an edit UI to group categories allowing renaming and
management of the self sign-up options. polished the existing UI for
creating categories.
fixes#4624
Change-Id: Ib623f4c6afd20e9700984f8294cd42950107252c
Reviewed-on: https://gerrit.instructure.com/6052
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Whitmer <brian@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>
added/changed functionality:
* search for course sections
* browse and select groups/sections/enrollment types (e.g. all
teachers) within a course
* browse and select enrollment types within a section
* changed toggle vs. drilldown input handling (e.g. clicking on an
expandable element now always expands it, unless you click on the
checkbox)
* "Select All" checkbox within groups and enrollment types
Change-Id: I13baa9e8b98abc5b5ec6dfb4cfbd1021160f65cc
Reviewed-on: https://gerrit.instructure.com/5955
Tested-by: Hudson <hudson@instructure.com>
Tested-by: Jon Jensen <jon@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
to be used for the new course menu. uses DISTINCT ON in postgres,
emulates it in ruby for mysql/sqlite
Change-Id: I790f6f9fab89e02b8af2bf26ca1d96703767e45d
Reviewed-on: https://gerrit.instructure.com/6026
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@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>
"Mute Assignment" links in gradebook and speedgrader
stop all announcements, emails, and stream items for grades
and comments from appearing until the teacher unmutes the
assignment.
Change-Id: Id74b305b568ff86e2a0e6f9319cfa40bb98b1bcd
Reviewed-on: https://gerrit.instructure.com/5779
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Zach Pendleton <zachp@instructure.com>
Zach Pendleton