fixes CNVS-5794
links to an access token to get the proper ARN
test plan:
* set up an SNS app in AWS
* configure your credentials in sns.yml
* set sns_arn on a developer key to be the ARN of the app in SNS
* using an access token created from that developer key,
you should be able to create a push channel
* you should see that channel in your profile (named after your developer
key)
Change-Id: I183241d02715252bf558c495d72d4995cea4232d
Reviewed-on: https://gerrit.instructure.com/25281
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes CNVS-8732
makes Mailer#message act in the rails3 style, but then provides
scaffolding so that it produces the necessary rails2 behavior when
running under rails2
test-plan:
* email delivery needs to be configured
* set up an email communication channel for a student
* configure to receive conversation alerts at that channel
* have a teacher send a conversation message to that student
* confirm receipt of the email at the student's address
Change-Id: I7f027a0a9a9dfd0231847017c888f1003b38d948
Reviewed-on: https://gerrit.instructure.com/25035
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Jacob Fugal <jacob@instructure.com>
fixes CNVS-7199, CNVS-4414
abstract some ICU stuff out to Canvas::ICU, and add some missing
functionality in FFI-ICU
test plan:
* create a bunch of groups in the same category, named 1-10.
10 should sort after 9, not 1
* repeat for creating and publishing quizzes *with the same due date*.
go to the quiz index, and 10 should sort after 9, not 1
Change-Id: I323eb12dfb5bd23dbcbb3b543fa1b90a72f4341b
Reviewed-on: https://gerrit.instructure.com/24732
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes CNVS-6974
test plan:
* create a user with Ĭńşŧřůćƭǜȑȩ in their name, enroll them in a course
* search for that user in the course roster, they should be found
Change-Id: Ia21d4d5163eec950cd45950123c1a273673a8c9a
Reviewed-on: https://gerrit.instructure.com/22470
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
no behavior change
test plan:
* run specs
* invite a user to a course, and accept the invitation as an
existing user
Change-Id: I2b0dc379a2c34065183cb8d9b74c2f61e94a736e
Reviewed-on: https://gerrit.instructure.com/15261
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
Really resurrect retired communication channels.
Fixes some callbacks that should've returned true.
test plan:
1) in rails console:
u = User.find(<some user id>)
cc = u.communication_channels.detect{|cc| cc.path_type == 'email'}
cc.bounce_count = 5
cc.workflow_state = 'retired'
cc.save
2) take note of the email on the cc
3) start up the server and go to /about/<user id>
4) click 'Add Email Address' and enter the email noted in #2
5) it should be successful
Change-Id: I0b4572545859eacd823a46b326303860069b00f1
Reviewed-on: https://gerrit.instructure.com/21102
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Landon Wilkins <lwilkins@instructure.com>
There are three parts to this:
- API access for site admins and account admins. Account
admins can only see messages for their account.
- Includes start and end time parameters for basic searching
- Summary notification are gathered up per account now, so
account admins will not see a summary notification from
multiple accounts.
fixes CNVS-3695
test plan:
- Verify Admin Access:
- Have a user enrolled in two courses in separate root
accounts.
- Send the user ASAP notification from each account.
- Go to /users/:id/messages (the old interface) and verify
the messages appear there.
- As a site admin, get /api/v1/comm_messages for the user
(see documentation for the api).
- Verify that data for both messages are returned.
- Use the console to give an account admin on one of the
accounts :read_messages permissions.
- As the account admin, get /api/v1/comm_messages for the
user.
- Verify that only the message for the admin's account is
returned.
- Verify start_time and end_time parameters
- Use the console to modify the created_at field for the
user's messages
- As a site admin, get /api/v1/comm_messages for the user,
specifying various combinations of start_time and
end_time, and make sure the appropriate messages are
returned.
- Verify account based summaries
- Set the notification policies for the user to a summary
setting (daily or weekly)
- Send multiple notifications to the user from each account.
- Use the console to run the
SummaryMessageConsolidator::process function.
- View /messages for the user and verify that separate
summaries are sent for each account.
Change-Id: Ie33ec02cc2033a1cc2f1fcbe538b76792aab0e6c
Reviewed-on: https://gerrit.instructure.com/18586
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Mark Ericksen <marke@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
fixes CNVS-4544
the bugfix was rolled into a larger refactor. registration
messages should now work as they originally did, before the
last refactor broke them
the refactor consumed three notable methods:
- Notification#create_message (which is still there, but calls
NotificationMessageCreator#create_message immediately)
- Notification#record_delayed_jobs
- CommunicationChannel#find_all_for
related specs have been adapted and moved to
NotificationMessageCreator's specs
test plan
- ensure that notification messages work as they did before
- particularly ensure that adding additional email addresses send
registration emails to those addresses, not the default address
Change-Id: Id201abbbc3cdc37305f5cd7125f1e4cb82fe4c96
Reviewed-on: https://gerrit.instructure.com/18561
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Cam Theriault <cam@instructure.com>
Reviewed-by: Mark Ericksen <marke@instructure.com>
fixes CNVS-4001
allow institutions to prevent students from removing
their institution-given, SIS-imported email address
from canvas.
test plan:
* in an account set the 'Users cannot delete their
institution email address' setting to true;
* create an SIS-imported communication channel;
* as a student or teacher in the account, create
and confirm a new communication channel and set
it to your default;
* verify that you cannot delete the SIS-imported channel
using the UI (e.g. the trash can icon will not
display);
* verify that attempting to delete the SIS-imported
channel from the API returns a 401.
Change-Id: If9b92f9436d6fe027a977894a1819792530435c4
Reviewed-on: https://gerrit.instructure.com/18071
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Willesen <jonw@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
refs CNVS-3559
test plan:
* create a user on the default shard (and confirm the e-mail address)
* on another shard, invite that same e-mail address to a course
* it should *not* show the user from the default shard
Change-Id: I897c55f8eaac832cbf655e0348189db4dc7a0a5e
Reviewed-on: https://gerrit.instructure.com/17414
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
refs #CNVS-2326
Added a UserSearch module that provides
and interface for searching across the name,
the email, and the sis id (and the database id),
and added a trigram index on the columns
that will be searched against.
also made a slight refactor to the AR
initializer in order to expose
some of the behavior I wanted more granularly
and added some specs to cover it
fixed a small permissions bug in course.rb
and pulled some scoping out of the courses
controller down into the user search module
TEST PLAN:
This is currently not accessible from
the site itself, this is just the ground
work for the eventual user search api endpoint.
The code is not called by anything currently in
production either so there is no need for
regression testing. The one thing to check would
be the creation of new users (and pseudonyms and
communication channels). There have been new
indexes added to columns on those tables
and there is some documentation indicating
that writing to these indexes can be time
consuming if the data set is quite large. It
would be worth making sure that there have not
been any unacceptable performance regressions
in the creation of any of those record types in
a database that has a full load of data
(comparable to the production environment)
Change-Id: I8fb13a6ec714f27efc8012c5ed2bed4d963c24e6
Reviewed-on: https://gerrit.instructure.com/16459
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Adds support for the "cspire" cell carrier for user SMS
notification options.
Testing Notes:
==========
NOTE: Full testing requires someone with that network service
to verify that messages are correctly being received.
* On /profile/settings page click the 'Add Contact Method'
in the sidebar under "Other Contacts"
* On the "Text (SMS)" tab, verify that 'C Spire' is now a carrier
option.
* Verify that when selected, the "SMS Email" uses the
"@cspire1.com" domain
Change-Id: I1dd409f728cff28499bfbf5fa7c189f64f705746
Reviewed-on: https://gerrit.instructure.com/16555
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
test plan:
* add an sms channel to a user
* retire that channel
* merge that user with a user in a different shard
Change-Id: Ibd24978c7456505b813961044b635b99b6beec6b
Reviewed-on: https://gerrit.instructure.com/15318
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
* Add CommunicationChannel#merge_candidates and use that in
CommunicationChannelsController#confirm, UsersController#create,
and profile settings view
* change a few pseudonym accesses to be based off the account, not
the user
* search all_pseudonyms in a few places
* shorten @communication_channel.confirmation_code to @nonce in
several places
test plan:
* create a normal user in shard 1. invite the same e-mail address to
a course in shard 2. accept the invitation as you're existing user
(you should have to log in)
* invite a different e-mail address to a course in shard 2. accept
the invitation while logged in as the user from the previous step
Change-Id: I9e7a4adb0b816650f444210c7a110b08858ec037
Reviewed-on: https://gerrit.instructure.com/15121
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
test plan:
* turn on cross-shard invitations in the console
(Setting.set('cross_shard_invitations', '1'))
* create a user with an email address in a shard (NOT
a site admin)
* in an unrelated shard with open registration on,
as an admin invite that e-mail address to a course
* log in as the original user on the first shard; the invitation
should show up on your dashboard
* accepting/rejecting that invitation is *not* yet supported
Change-Id: I3b0c9657fe0dd37a737af9f4253ea8ef8b2f2b91
Reviewed-on: https://gerrit.instructure.com/14903
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
fixes#10690
previously, notifications only considered user locale settings
when translating; they now consider the context as well.
test plan:
* create a course with a spanish or russian locale;
* enroll an english user in the course;
* verify that the enrollment email is sent in the course
locale and not the user locale.
Change-Id: Ib942f35dff770ec02aa4e39880a5234e318f26a9
Reviewed-on: https://gerrit.instructure.com/14103
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
test plan:
* enable optional MFA, and check the following:
* normal log in should not be affected
* you can enroll in MFA from your profile page
* you can re-enroll in MFA from your profile page
* you can disable MFA from your profile page
* MFA can be reset by an admin on your user page
* when enrolled, you are asked for verification code after
username/password when logging in
* you can't access any other part of the site directly until
until entering your verification code
* enable required MFA, and check the following
* when not enrolled in MFA, and you log in, you are forced to
enroll
* you cannot disable MFA from your profile page
* you can re-enroll in MFA from your profile page
* an admin (other than himself) can reset MFA from the user page
* for enrolling in MFA
* use Google Authenticator and scan the QR code; you should have
30-seconds or so of extra leeway to enter your code
* having no SMS communication channels on your profile, the
enrollment page should just have a form to add a new phone
* having one or more SMS communication channels on your profile,
the enrollment page should list them, or allow you to create
a new one (and switch back)
* having more than one SMS communication channel on your profile,
the enrollment page should remember which one you have selected
after you click "send"
* an unconfirmed SMS channel should go to confirmed when it's used
to enroll in MFA
* you should not be able to go directly to /login/otp to enroll
if you used "Remember me" token to log in
* MFA login flow
* if configured with SMS, it should send you an SMS after you
put in your username/password; you should have about 5 minutes
of leeway to put it in
* if you don't check "remember computer" checkbox, you should have
to enter a verification code each time you log in
* if you do check it, you shouldn't have to enter your code
anymore (for three days). it also shouldn't SMS you a
verification code each time you log in
* setting MFA to required for admins should make it required for
admins, optional for other users
* with MFA enabled, directly go to /login/otp after entering
username/password but before entering a verification code; it
should send you back to the main login page
* if you enrolled via SMS, you should not be able to remove that
SMS from your profile
* there should not be a reset MFA link on a user page if they
haven't enrolled
* test a login or required enrollment sequence with CAS and/or SAML
Change-Id: I692de7405bf7ca023183e717930ee940ccf0d5e6
Reviewed-on: https://gerrit.instructure.com/12700
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@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>
fixes#5711
also cleans up broadcast policy a bit
* remove cruft
* re-organize so that the DSL doesn't become methods on the model
* add context method to the DSL that becomes asset_context on the
message
* only evaluate the policy block once, instead of every time a
model that has a broadcast policy is saved
test plan:
* add an e-mail address to a user, and check the "I want to login" checkbox
* the notification e-mail should link back to the correct domain
Change-Id: I484d07963c86c81f9b0226fd942ef9a71ac5500c
Reviewed-on: https://gerrit.instructure.com/8830
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Reviewed-by: Brian Palmer <brianp@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>
we include memoizable in AR::Base in an initializer, but that runs
after plugin initializers, so we have to do this if a plugin needs
to use CommunicationChannel in its initializer
test plan: n/a
Change-Id: Iddd4141ab816b0b98358bdda3a325a0725f81994
Reviewed-on: https://gerrit.instructure.com/8082
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
It turns out that the defaults for daily/weekly policies actually do work -
the issue before was that they won't work for a user whose first communication
channel is retired. This fixes that problem by using the first active email
channel.
Another problem was that we would only build placeholder policies if the user
had NO notification policies at all. However, that rarely happens - when a
user receives a notification and they don't have a policy for it, that policy
gets built. In this case, when the user went to their preferences page, they
would see all the notification categories they didn't have policies for as
"never". This creates placeholder policies for all the notification categories
the user doesn't have one for.
It also makes sure the correct defaults are displayed on the preferences
screen.
test plan:
* Create a new user A, and enroll them in a course.
* As another user B, create a calendar event in that course. A calendar event
is by default a "never" item.
* As user A, go to your communication prefs and notice that all the default
preferences are still appearing. In the console you can verify that the
policy was created for you too:
> User.find(<A.id>).notification_policies
* Now, delete that policy from the database.
* As user A, add a new comm channel and delete the old one.
* As user B, create another calendar event
* Verify in the console that user A got a notification policy created for the
second communication channel.
* As user B, create a discussion topic.
* As user A, add an entry to that topic.
* As user B, comment on that topic as well.
Discussion entries are by default 'daily', so user A should have a
DelayedMessage. Verify in console:
> DelayedMessage.last
Change-Id: I3f7827d2aa83d5b72ab5f8f96aa92ef96652f115
Reviewed-on: https://gerrit.instructure.com/8062
Reviewed-by: JT Olds <jt@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
When a user had not configured any notification policies, on the communication
preferences page, they would see everything as "immediate". That would lead
people to believe that those are the defaults.
Note that for now, only "immediate" notifications actually will be sent by
default. All others are assumed to be never, so that should be reflected in
the UI.
test plan:
* Create a new user
* Go to the Profile -> Communication Preferences page
* Notice that the pre-selected preferences are immediate for immediate
notifications, and never for everything else.
Change-Id: Ibbd908a5b6f38d144fd4f752bc57258e96c4dc78
Reviewed-on: https://gerrit.instructure.com/8050
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
We were just finding the first CommunicationChannel, which might even be
retired. This will make sure we get an active one and it's an email one.
test plan:
* (perform all these steps on a new account, and don't go into the
notification preferences screen)
* Create a new account with an email address X
* Add a new, secondary email address Y to your account
* Delete the email address X
* As another user, start a conversation with the user created above.
* Verify that you received the email notification at email address Y and not
X.
Change-Id: I7b16001918c5f39b5929e0f520069838a10bcf66
Reviewed-on: https://gerrit.instructure.com/8035
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Zach Wily <zach@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#4805
test plan:
- set up a new email address or SMS in your profile
- in the notifications tab of the profile, add that new unconfirmed
address to "For new conversation messages" and save
- as another user, message your first user, confirm the notification
goes to the active channel but not the new uncofirmed one.
Change-Id: Id34540486e9107e829cacf9a7badcac15ede1dd6
Reviewed-on: https://gerrit.instructure.com/7859
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@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>
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>
* Don't show merge opportunities for confirmation or transfer enrollment flows
* Combine current user and other user sections into a single section
* Use simplified wording for single merge opportunity
* Use "add e-mail address" for logged in, non-matching single e-mail opportunity
* Hide the registration form behind an additional click if there are merge
opportunities
* When a login is required to complete the action, automatically do the action
after login, assuming they logged in as the correct user
Change-Id: If07b38702c15509af6798fc00bc062f286789438
Reviewed-on: https://gerrit.instructure.com/6649
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Hudson <hudson@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>
update_all's update hash doesn't have any magic performed on bare Time
objects; it assumes any Time object it's given is already in UTC. using
a TimeWithZone object (regardless of timezone), which Fixnum#ago and
friends happen to return, is still fine.
Change-Id: I297b2a3211b896b5225ebcfaaee3c1eb56e55fb6
Reviewed-on: https://gerrit.instructure.com/5351
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Twitter recently stopped offering whitelist
exceptions for things like direct messaging. We are
trying to work around the limitations by having
a user direct message themselves instead of having
some global account user that direct messages everyone.
Also added a "short_host" method for HostUrl that
in the future we can use to generate short-ish links
to include in tweets. For now the links are somewhat
short, at least.
refs #4045
Change-Id: Iad59b979b166d572827a8ce16d3f9fcdd57d512d
Reviewed-on: https://gerrit.instructure.com/2938
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
Refs #3752 - this change alone is a 4x increase in users-per-second
import speed.
This should be safe - I looked through as much relevant code as I
could find, and it all is already defensive against policies not
being set up yet. In fact, when you initialize a blank db, the
initial user doesn't have policies set up, and they work just fine.
Change-Id: Id0e449ad0d588e83993bf83ea5536767c9166789
Reviewed-on: https://gerrit.instructure.com/3514
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
Cody Cutrer