* fix view spec rendering to include helpers
* re-implement have_tag rspec matcher
* fix problems with finding routes to
unsaved records
Change-Id: I6ed267fcf5e8e32a62ee059be46371bc0ea35603
Reviewed-on: https://gerrit.instructure.com/30016
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
test plan:
N/A, they weren't used
Change-Id: Icb078fb8e9a2386f22a07e1b5ce543e9b29f72e5
Reviewed-on: https://gerrit.instructure.com/19086
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Joe Tanner <joe@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Implementing the re-designed Notification Preferences page.
Testing plan:
=========
* Verify that expected preferences can be set.
* Verify that it supports accessibility (screen readers) for blind users
* Verify that mobile users (iPad at least) can smoothly interact.
Change-Id: I2b98f2477932d800d2ec3de580e47a95f827616b
Reviewed-on: https://gerrit.instructure.com/12356
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
change registration flows for teachers, higher-ed students, and parents.
now users can start using canvas immediately before confirming their
email address (and setting a password). they get a nice big reminder when
they first view the dashboard, and can't edit their profile (or related
things) until they do so.
test plan:
1. go to the signup form for a teacher
2. fill it out
3. confirm that you are immediately logged in to the dashboard
4. confirm that you get a big popup when you first view the dashboard
5. confirm that you can't edit your profile
6. repeat steps 1-5 for higher-ed students (no join code)
7. repeat steps 1-5 for parents (observers)
8. confirm that students registering with a join code do not need to
verify their email address (since no email is sent)
Change-Id: I4e7e1c083d70725fffd345016f1ca1eec4aeab13
Reviewed-on: https://gerrit.instructure.com/12172
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
it always created them in the default account, so it didn't make sense
anyway
test plan:
* go to the profile page, and add an e-mail address
* on a default account, it should have a checkbox to create an
associated login
* on a non-default account, it shouldn't
Change-Id: I38d216df828c5bbf4fd9579e2ead06241692c8dd
Reviewed-on: https://gerrit.instructure.com/12198
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
fixes#6585, #7096
by normalizing, it's impossible to not maintain a column that isn't
there (yes, triple negative is intended in that sentence), thus
preventing sending notifications to the wrong user after a merge
or any other bugs that would have missing maintaining the
denormalization.
test plan:
* test notifications in general
* merge two active users together - their notification preferences
should survive the merge
Change-Id: I239d810c5499b94550b65128cac71c42cedd11ba
Reviewed-on: https://gerrit.instructure.com/8013
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
fixes#6786, #6789
the uniqueness check was failing if there was a matching retired cc,
even though this cc is the only active/unconfirmed one. so
instead write a custom validator that only searches for
active/unconfirmed ccs.
test plan:
* manually add the same email address to a user multiple times,
in a retired state (in script/console, or directly in the db)
* try to add that email address to the user in the UI
* it should work
Change-Id: I41bdff34ffcd273d82d1d251e45c1ce48b61d51c
Reviewed-on: https://gerrit.instructure.com/7889
Tested-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@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>
James Williams