test plan:
* invite a new user into a course
* use the link from the registration email to confirm
the account, but don't enter in a password
* should receive a error that the password
is too short but not a misplaced "doesn't match" error
closes #ADMIN-312
Change-Id: Ib806fd76d602be7236051715862100c59fbb863d
Reviewed-on: https://gerrit.instructure.com/131468
Tested-by: Jenkins
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
turns out it was hitting the endpoint twice
(other one via communication_channels.js)
test plan:
* have an unconfirmed sms communication channel
* click on the address and press "Re-send Confirmation Code"
* it should not send two messages in "/messages"
closes #CNVS-35966
Change-Id: Iff5150664534025e04192c0502542b1f572a3af4
Reviewed-on: https://gerrit.instructure.com/107452
Tested-by: Jenkins
Reviewed-by: Dan Minkevitch <dan@instructure.com>
QA-Review: Deepeeca Soundarrajan <dsoundarrajan@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
refs: CNVS-29532
ENV['CANVAS_FORCE_USE_NEW_STYLES'] is true in the
jenkins hourly NewUI only build. so each of these
were failing there.
as far as the formatting of these changes, I tried
to do it in a way to make it so the process of
removing the oldUI code path this summer is explicit,
easy and clear.
Change-Id: Icb4653c2b5a32a28d192fe228ad8b480a25423bd
Reviewed-on: https://gerrit.instructure.com/80203
Tested-by: Jenkins
Reviewed-by: Robert Lamb <rlamb@instructure.com>
Product-Review: Robert Lamb <rlamb@instructure.com>
QA-Review: Robert Lamb <rlamb@instructure.com>
fixes SD-1063, speeds up :allthethings:
negative DOM assertions are 💩, but if we must have them, make them
more tolerable. the old way:
expect(f(".something-that-should-be-gone")).to be_nil
expect(fj("buhleeted:visible")).to be_nil
expect(fln("Can't Click Here Anymore").to be_nil
the new way:
expect(container).not_to contain_css(".something-that-should-be-gone")
expect(container).not_to contain_jqcss("buhleeted:visible")
expect(container).not_to contain_link("Can't Click Here Anymore")
(you can of course use these new matchers for positive assertions as well)
although it's a tad more verbose, the new way is better because:
1. it's smart enough to bail once the assertion is met (versus the old way
which would take 10-20 seconds to not find the thing and *then* run the
assertion)
2. it requires them to be scoped, to reduce the likelihood of false
positives (e.g. if the page is totally broken, then of course the
assertion would pass)
also reworked the various flash message assertions... see the new
expect_flash_message and expect_no_flash_message
this should remove over an hour of linear time off the build (10 sec per
old assertion, except fj ones which took 20 sec)... so like a minute of
actual time, cuz parallelization :P
a consequence of this change is that f/fj/ff/ffj now raise if nothing is
found, so you really have to go out of your way to do it the bad way. so
don't :)
Change-Id: I0fe6e8500947c27d748b70bb2cda585edf71e427
Reviewed-on: https://gerrit.instructure.com/78420
Tested-by: Jenkins
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@instructure.com>
Fixes CNVS-20747
Test plan:
- Create a user
- Add an email address to the user
- The address doesn't need to be able to actually receive
messages, so put anything you want in here
- Make note of the user's id
- Assuming the user's id is 42, open a rails console and type:
c = User.find(42).email_channel
c.bounce_count = 3
c.save!
- Log in as the user (actually log in, don't just masquerade)
- Visit the user's settings page
- Verify you see the usual warning triangle next to the user's
email address
- Verify you don't see the reset icon (just a refresh-like icon,
two arrows pointing in a circle)
- Log in as a siteadmin
- Masquerade as the user
- Visit the user's settings page
- Verify you see both the warning triangle and the reset icon
- Click the reset icon
- Verify that the reset icon and the warning triangle go away
- Refresh the page and verify that they're still gone
- Assuming the user's id is 42, open a rails console and type:
c = User.find(42).email_channel
c.bounce_count = 1
c.save!
- Log in as a siteadmin
- Masquerade as the user
- Visit the user's settings page
- Verify you see only the reset icon and not the warning
triangle
- Click the reset icon
- Verify that it goes away
- Refresh the page and verify that it's still gone
Change-Id: Ibd9d2e04555be2ec3eae811fd93f2cba0645d870
Reviewed-on: https://gerrit.instructure.com/55139
Reviewed-by: Joel Hough <joel@instructure.com>
Tested-by: Jenkins
QA-Review: Adrian Russell <arussell@instructure.com>
Product-Review: Allison Weiss <allison@instructure.com>
- reasoning: this group contains set-up and teardown,
it does not include 'it' blocks
Change-Id: I1803420a5c7f59246f3af211e42ced808a994c3f
Reviewed-on: https://gerrit.instructure.com/60329
Tested-by: Jenkins
Reviewed-by: Matt Fairbourn <mfairbourn@instructure.com>
Product-Review: Matt Fairbourn <mfairbourn@instructure.com>
QA-Review: Matt Fairbourn <mfairbourn@instructure.com>
in particular, change "it_should_behave_like" to
"include_examples" (in rails 3, "it_should_behave_like"
does not extend the defined methods to nested examples)
Change-Id: I24c3d0a214e763cd61bbe73e055f610e021fddd0
Reviewed-on: https://gerrit.instructure.com/28157
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>
Turns our we *do* want to grandfather in existing users :P
This reverts commit ae6d9033ac.
Change-Id: I7b109375a4844ef0291f0f72d89028b39d2289a0
Reviewed-on: https://gerrit.instructure.com/23384
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
fixes CNVS-7385
test plan:
1) in a console:
# grab a user of your choice
u = User.find(5)
# make it seem as if they have never accepted the terms before
u.preferences[:accepted_terms] = nil
u.save!
2) log in as that user
3) verify that you are required to accept the terms of use
Change-Id: Ibc314040f35d3d7418a3b31c7280188db86a552b
Reviewed-on: https://gerrit.instructure.com/23110
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
they were required prior to our new settings refactors. this way we don't
need to go set it in prod
test plan:
1. terms should be required when registering at /register
2. terms should be required when activing an account (via course
invitation email)
3. in the console, do Setting.set('terms_required', 'false')
4. terms should no longer be required on those pages
Change-Id: Idb13727839b847845cd4dacde4797e4e1571b42f
Reviewed-on: https://gerrit.instructure.com/22988
Reviewed-by: Mark Ericksen <marke@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
also fix issue around communication_channels/confirm not giving a visual
indication that the terms must be accepted if you forget to check the box
fixes CNVS-7189
test plan:
1. go to /register
2. you should not need to agree to the terms on any form, but you should
see a link to the privacy policy
3. invite a user to a course
4. the user should not need to agree to the terms when setting a password
5. in the console, do Setting.set('terms_required', true)
6. go to /register
7. you should need to agree to the terms on all the forms
8. invite a user to a course
9. the user should need to agree to the terms when setting a password
Change-Id: I54857d7aaef1b528c6033a3464701abeae4ce14f
Reviewed-on: https://gerrit.instructure.com/22770
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
since we have already "validated" the email (by virtue of them receiving
it and clicking on a link), we don't need to validate it here. fixes an
issue where users with non-email pseudonyms could not get past this page
also tweak form so that pseudonym can be specified if it needs to be set
(for example, the email was already taken by another user)
test plan:
1. as an admin create a new user with a login other than their email
address
2. check the user's /messages URL to see the email that was sent to the
user
3. copy and paste the URL that was sent in the email and navigate to it
4. the registration page should allow you to proceed and the label should
say "Login"
Change-Id: I563b53b16b950bd7f6dafc456349db74fd97b294
Reviewed-on: https://gerrit.instructure.com/12569
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
James Williams