canvas-lms/spec/selenium/communication_channels_spec.rb

127 lines
5.0 KiB
Ruby
Raw Normal View History

require File.expand_path(File.dirname(__FILE__) + '/common')
describe "communication channel selenium tests" do
include_context "in-process server selenium tests"
context "confirm" do
it "should register the user" do
Setting.set('terms_required', 'false')
u1 = user_with_communication_channel(:user_state => 'creation_pending')
get "/register/#{u1.communication_channel.confirmation_code}"
set_value f('#pseudonym_password'), "asdfasdf"
expect_new_page_load {
f('#registration_confirmation_form').submit
}
expect_logout_link_present
end
it "should require the terms if configured to do so" do
u1 = user_with_communication_channel(:user_state => 'creation_pending')
get "/register/#{u1.communication_channel.confirmation_code}"
expect(f('input[name="user[terms_of_use]"]')).to be_present
f('#registration_confirmation_form').submit
wait_for_ajaximations
assert_error_box 'input[name="user[terms_of_use]"]:visible'
end
it "should not require the terms if the user has already accepted them" do
u1 = user_with_communication_channel(:user_state => 'creation_pending')
u1.preferences[:accepted_terms] = Time.now.utc
u1.save
get "/register/#{u1.communication_channel.confirmation_code}"
spec: rework negative dom assertions fixes SD-1063, speeds up :allthethings: negative DOM assertions are :poop:, 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>
2016-05-01 06:23:03 +08:00
expect(f("#content")).not_to contain_css('input[name="user[terms_of_use]"]')
end
it "should allow the user to edit the pseudonym if its already taken" do
u1 = user_with_communication_channel(:username => 'asdf@qwerty.com', :user_state => 'creation_pending')
u1.accept_terms
u1.save
# d'oh, now it's taken
user_with_pseudonym(:username => 'asdf@qwerty.com', :active_user => true)
get "/register/#{u1.communication_channel.confirmation_code}"
# they can set it...
input = f('#pseudonym_unique_id')
expect(input).to be_present
set_value input, "asdf@asdf.com"
set_value f('#pseudonym_password'), "asdfasdf"
expect_new_page_load {
f('#registration_confirmation_form').submit
}
expect_logout_link_present
end
Link to reset bounce counts for communication channels 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>
2015-10-07 12:27:50 +08:00
it 'confirms the communication channels', priority: "2", test_id: 193786 do
user_with_pseudonym({active_user: true})
create_session(@pseudonym)
get '/profile/settings'
expect(f('.email_channels')).to contain_css('.unconfirmed')
f('.email_channels .path').click
Notification.create!(name: 'Confirm Email Communication Channel', category: 'Registration')
f('#confirm_email_channel .re_send_confirmation_link').click
expect(Message.last.subject).to eq('Confirm Email: Canvas')
url = Message.last.url
# get the registration id from the url
get '/register/' + url.split('/')[4]
expect(f('#flash_message_holder')).to include_text 'Registration confirmed!'
get '/profile/settings'
# the email id does not have a link anymore
expect(f('.email_channels')).not_to contain_link('nobody@example.com')
end
it 'resends sms confirmations properly' do
user_with_pseudonym({active_user: true})
create_session(@pseudonym)
sms_cc = @user.communication_channels.create(:path => "8011235555@example.com", :path_type => "sms")
get '/profile/settings'
expect(f('.other_channels')).to contain_css('.unconfirmed')
f('.other_channels .path').click
Notification.create!(name: 'Confirm SMS Communication Channel', category: 'Registration')
f('#confirm_communication_channel .re_send_confirmation_link').click
wait_for_ajaximations
expect(@user.messages.count).to eq 1
m = @user.messages.first
expect(m.subject).to eq('Canvas Alert')
expect(m.body).to include(sms_cc.confirmation_code)
end
Link to reset bounce counts for communication channels 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>
2015-10-07 12:27:50 +08:00
it 'should show the bounce count reset button when a siteadmin is masquerading' do
u = user_with_pseudonym(active_all: true)
u.communication_channels.create!(:path => 'test@example.com', :path_type => 'email') { |cc| cc.workflow_state = 'active'; cc.bounce_count = 3 }
Link to reset bounce counts for communication channels 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>
2015-10-07 12:27:50 +08:00
site_admin_logged_in
masquerade_as(u)
get '/profile/settings'
expect(f('.reset_bounce_count_link')).to be_present
end
it 'should not show the bounce count reset button when an account admin is masquerading' do
u = user_with_pseudonym(active_all: true)
u.communication_channels.create!(:path => 'test@example.com', :path_type => 'email') { |cc| cc.workflow_state = 'active'; cc.bounce_count = 3 }
Link to reset bounce counts for communication channels 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>
2015-10-07 12:27:50 +08:00
admin_logged_in
masquerade_as(u)
get '/profile/settings'
spec: rework negative dom assertions fixes SD-1063, speeds up :allthethings: negative DOM assertions are :poop:, 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>
2016-05-01 06:23:03 +08:00
expect(f("#content")).not_to contain_css('.reset_bounce_count_link')
Link to reset bounce counts for communication channels 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>
2015-10-07 12:27:50 +08:00
end
it 'should not show the bounce count reset button when the channel is not bouncing' do
u = user_with_pseudonym(active_all: true)
u.communication_channels.create!(:path => 'test@example.com', :path_type => 'email') { |cc| cc.workflow_state = 'active' }
Link to reset bounce counts for communication channels 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>
2015-10-07 12:27:50 +08:00
site_admin_logged_in
masquerade_as(u)
get '/profile/settings'
spec: rework negative dom assertions fixes SD-1063, speeds up :allthethings: negative DOM assertions are :poop:, 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>
2016-05-01 06:23:03 +08:00
expect(f("#content")).not_to contain_css('.reset_bounce_count_link')
Link to reset bounce counts for communication channels 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>
2015-10-07 12:27:50 +08:00
end
end
end