test plan:
1. set GERGICH_GIT_PATH to a valid plugin gem path
2. script/lint_commit_message should lint according to the plugin's HEAD,
not canvas-lms'
Change-Id: I0976c39ca8278d8241c37ed464b24fcdf7cd9e58
Reviewed-on: https://gerrit.instructure.com/71928
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
test-plan:
* put an unnecessary hyphen there ^
* gergich should not complain
Change-Id: Id092e5e9430bd6d7cb95b3f583f3bd1a5b1e82b3
Reviewed-on: https://gerrit.instructure.com/65749
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
sorry, not sorry; it's better than cloak'n'daggering
Change-Id: I641167cb402a616601e9c95499bec474947f4c66
Reviewed-on: https://gerrit.instructure.com/65719
Tested-by: Jenkins
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
the # is not necessary, but now you won't get misleading linter messages
if you do one, e.g. refs #PROJ-123
test plan:
1. the linter should not complain about this commit message
Change-Id: I3eb9e5de093a5b8948c2892bd3ecdec8c3ea4add
Reviewed-on: https://gerrit.instructure.com/65225
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Tested-by: Jenkins
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
now you can have a colon between refs and the ticket, e.g.
refs: FAKE-123
test plan:
1. this commit message should pass the linter (even though that's not a
real ticket)
Change-Id: I32776d59c3ee2d7935c20caba759e0bd0b2596e9
Reviewed-on: https://gerrit.instructure.com/65208
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Tested-by: Jenkins
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
Now with full js/jsx/coffee/hbs/scss goodness \o/
If your commit ONLY touches js/jsx/coffee/hbs/scss/views/controllers or
specific whitelisted things, and doesn't touch global-y bundles or
layouts, then your commit may** be selinimized. That means it will only
run the selenium specs that care about those files.
If you touch lib, or gems, or models, or any global-y stuff, all the specs
will still run.
Also add the ability to override what we selinimize against when testing
changes to selinimum.
**Note that actual selinimization depends on a post-merge build having
succeeded for the parent (or a near ancestor). If the post-merge build
failed, or your build starts before it finishes, or there are
unselinimizable changes between your commit and the nearest ancestor with
selinimum stats, then your commit will not be selinimized :'(
See 4a83f6b6 for the full story.
Test Plan:
* Specs should pass on this commit
* It should not be selinimized because we touch package.json
* See dependent test commits where selinimization happens
Change-Id: I62c78c316876aaff07514a0f460ff4d608dac494
Reviewed-on: https://gerrit.instructure.com/65082
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Tested-by: Jenkins
Reviewed-by: Derek Bender <djbender@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
ruby port of the useful pieces of bridge's bash linter
test plan:
1. run it on this commit
2. it should complain that there is no ticket :P
3. feed it a commit message via stdin, e.g.
`echo -e "yay\n\na commit"|script/lint_commit_message --stdin`
4. confirm it behaves sensibly
Change-Id: I6bdd6db53e178c4d5d7372aafba47b60c4b9f076
Reviewed-on: https://gerrit.instructure.com/65124
Tested-by: Jenkins
Reviewed-by: Derek Bender <djbender@instructure.com>
Product-Review: Jon Jensen <jon@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
we no longer use `npm run compile-sass` to do css.
also, css must happen before handlebars.
besides, all the js, css, styleguide and docs stuff
is handled by rake canvas:compile_assets already.
and in a way that whatever can run concurrently,
will.
(although, admittedly, the syntax to pass arguments
to a rake task, e.g.: [0,0,1,0] is pretty lame)
Change-Id: I83c8ceb21b476456f47f3ec37d4ba6088ca68088
Reviewed-on: https://gerrit.instructure.com/57768
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Tested-by: Jenkins
what this does:
* Changes the way we generate css so we are able to generate custom
css for people that use the theme editor.
* Sets everything up so we can push all of our static assets
(js, fonts, css, images, etc) to s3 pre-deploy and serve them
from cloudfront. Yay! faster canvas for everyone!
* as part of that, this enables the rails asset pipeline just so we
can use it to put md5s in our urls. we don't use it for any of the
coffeescript/sass/sprockets transformer stuff.
* adds a new "Theme editor" functionality (only for people that have
have the use-new-styles feature flag turned on) where an admin for
an account can pick their own colors/images for all the users
at their account/school.
* when the user is done saving things in theme editor, it will,
in a delayed job, generate all the css with against the variables
that user specified and push it to s3 so it will be available to
anyone else that requests it. (the delayed job will shell
out to a node.js executable called `brandable_css`).
* ability to pick an existing shared theme and to reset to
blank theme. closes: CNVS-19685
* gets rid of jammit.
test plan:
(this is exaustive, so not every person has to do every step
but we should make sure at least someone does each of these things.
maybe as part of the review add a comment if you have done one of these
bulletpoints)
* before you check this out, compile all css and copy the
public/stylsheets_compiled directory somewhere. after you check out
this code and regenerate all the css. make sure there are no
significant changes to the css output. (we updated the versions of
node-sass and autoprefixer that we use so we want to make sure they
don't change things in a way we weren't expecting)
* make sure the way we load css for handlebars templates still works.
eg: if there is a handlebars template at
app/views/jst/some/template.handlebars
if there is also a scss file at
app/stylesheets/jst/some/template.scss
then that stylesheet should get loaded when that template is rendered
* check out the code and run migrations. browse around canvas,
make sure css and js files load correctly as before.
* cody, jacob, or someone on queso: look at the db migrations and
make sure everything looks good and that I am handling sharding
correctly.
* verify that both rake canvas:compile_assets and guard, works as well
as `node_modules/.bin/brandable_css` (note: if you have
"node_modules/.bin" in your PATH (which you should), it will also
work with just `brandable_css`)
* verify that passing the --watch option to
`.bin/node_modules/brandable_css` works and picks up changes to
sass files, images, fonts, or any other resource that goes into
a css file. and that it only recompiles the css files that actually
depend on that file.
* go to https://github.com/ryankshaw/brandable_css and check out the
code there. that is what is actually doing the sass compiling
* create a config/canvas_cdn.yml file and add aws access creds and
an s3 bucket and cdn hostname (for testing, you can use the credentials
for instructure_uploads_engineering from
https://gollum.instructure.com/OtherServiceTestAccounts ). for a test
cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that
is a cloudfront bucket I set up on my personal account that points to
instructure_uploads_engineering
* run rake canvas:compile_assets again, this time, at the end, you
should see it run the assets:precompile task that puts md5s in filenames
and, gzipps them, and copys them to public/assets.
then you should see it run canvas:cdn:upload_to_s3
(look at log/development.log for progress),
which pushes everything to s3.
closes: CNVS-17333 CNVS-17430 CNVS-17337
* try out the theme editor: turn on new styles, go to accounts/x
(where x is the @domain root acount you are testing from) and click
the "theme editor" button on the right side of the page.
that should take you to a page that has the ability to pick colors/images
on the left side and preview your changes in an iframe on the right
closes: CNVS-19360 CNVS-20551
* test the "preview", "save", "reset", and "choose existing" functionality
closes: CNVS-17339 CNVS-17338 CNVS-19685
* make sure that the themeeditor works both if you have
config/canvas_cdn.yml set up and enabled as well as if you don't.
if it is enabled, you should see it push the css for just that new
brand config to s3 when you hit preview, and the css
should be accessible from the cdn you configured.
Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22
Reviewed-on: https://gerrit.instructure.com/53873
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
also start moving the more complicated logic
from the rlint script into tested helper
classes
Change-Id: I5c3916b0c7e695389b552dc1a6b4353aaaeba290
Reviewed-on: https://gerrit.instructure.com/52743
Tested-by: Jenkins
Reviewed-by: Simon Williams <simon@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
lets rlint only run with local changeset unless you specify "--heavy"
Also checks for whether you actually touched a line
or not before deciding an INFO comment is relevant
Change-Id: I4a960c72644dfc46aca7a51d04321711cef0850c
Reviewed-on: https://gerrit.instructure.com/51992
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
Tested-by: Ethan Vizitei <evizitei@instructure.com>
on jenkins this was taking up to 9 minutes.
By removing the file I/O and batching
the georgich commits, this ran locally on my
sentry patch set in 15 seconds.
Change-Id: I23b0df9b9396829de4b8ff084f4f92df6e698da2
Reviewed-on: https://gerrit.instructure.com/51987
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
Needed some better use of environment variables
to get the right SHA. also shouldn't care about
dirty working directory on jenkins.
Change-Id: I85d4b9468f629217adcdd25039e44f26fd20b1d5
Reviewed-on: https://gerrit.instructure.com/51907
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
add migration lint as rubocop cops
create frozen constant linter
find_ids datafixup lint
send_later lint
lint send_later in predeploys
add freeze_constant cop to default config
don't forget to include rubocop when running
get the rubocop runner into the script
lint for wrong algorithm name
lint primary key
lint remove_column in predeploys
get rubocop output as parsed json
diff munging for gergich
disable a few style cops
tweak rubocop setup to allow IDE plugins to work
get gergich comment format right
shell out to gergich if we're in jenkins-land
Change-Id: I6eecc8d8ede17a755c9d9a86121c3658776de9cd
Reviewed-on: https://gerrit.instructure.com/51755
Tested-by: Jenkins
Reviewed-by: Jason Madsen <jmadsen@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
This commit adds a new module called LiveEvents that knows how to send a
certain set of events to Kinesis. The module is configured via
normal plugin settings per account. Once the plugin is configured with
a Kinesis stream, events will start getting sent to that stream.
Events are sent asynchronously, in a background thread.
test plan:
* See `doc/live_events.md` for instructions on how to setup a local
kinesis stream and configure the LiveEvents plugin.
* Start tailing the stream with the command specified in
`doc/live_events.md` in a terminal.
* Perform the actions described in `doc/api/live_events.md` and verify
that events show up in your Kinesis terminal with the correct data.
Change-Id: Id799688c972205a1eee84a673912f84b0c7abb57
Reviewed-on: https://gerrit.instructure.com/50324
Reviewed-by: Rob Orton <rob@instructure.com>
Tested-by: Jenkins
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
Product-Review: Zach Wily <zach@instructure.com>
vendor/plugins
When either gems/plugins or vendor/plugins doesn't exist in the repo,
the script would print an error as it tried to list the directory
contents through globbing. This fixes that error.
Fixes CNVS-19519
Test Plan:
- Create a new checkout with no vendor/plugins directory, or delete
the existing one (not recommended)
- Run the script and ensure it does not report an error with
a missing vendor/plugins/*
- Ensure the script completes without error
Change-Id: I4d49fc090d4abc21ac8e8005f4ed83c47b4e89c5
Reviewed-on: https://gerrit.instructure.com/50961
Reviewed-by: Cameron Sutter <csutter@instructure.com>
Product-Review: Cameron Sutter <csutter@instructure.com>
Tested-by: Jenkins
QA-Review: Benjamin Porter <bporter@instructure.com>
This makes a number of changes to get the compilation compatible with
node 12 and iojs.
- removes loom (no longer used)
- updates karma dependencies to more recent versions
- minor css change to make sass compilation work with node-sass
(lib-sass)
test plan:
- should be able to compile assets with node 12 and iojs
- JS specs still pass
Change-Id: Id4a0628ff0c6dd09e622d02329a4400d60459ec2
Reviewed-on: https://gerrit.instructure.com/49493
Tested-by: Jenkins
Reviewed-by: Nick Houle <nhoule@instructure.com>
Product-Review: Cameron Matheson <cameron@instructure.com>
QA-Review: Cameron Matheson <cameron@instructure.com>
bash best practice is to use double quotes to prevent globbing and word
splitting. This probably doesn't matter in the context we are using,
but it pollutes the output of the linter so might as well just fix it.
Also switch `` to $(). Backticks are deprecated
Fixes CNVS-18183
Change-Id: I03cef6a7b3e1740bfb46c422e89788cd5d1eb7e0
Reviewed-on: https://gerrit.instructure.com/47726
Reviewed-by: Mark Severson <markse@instructure.com>
Tested-by: Jenkins
QA-Review: Adam Stone <astone@instructure.com>
Product-Review: Benjamin Porter <bporter@instructure.com>
closes: CNVS-17331 CNVS-14993
refs: CNVS-17332
This is the first step to having a full theme editor where
accounts can pick their own color scheme in a UI and all of
canvas will be branded to their school colors.
test plan:
* copy config/brand_variables.scss.example to config/brand_variables.scss
* recompile sass
* users in accounts that have "new styles" or "k12" turned on that have
not turned on "high contrast". should see a new purple-orange canvas.
* but users that have turned on the "high_contrast" feature or accounts
that have not turned on either "k12" or "new styles" should not.
Change-Id: I16342d43b56e49d52fbee8fa5c6a0fd57ae6e602
Reviewed-on: https://gerrit.instructure.com/46085
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Colleen Palmer <colleen@instructure.com>
this will allow us to enforce linting in the build
also ignore plugins' vendored javascript
Change-Id: Ibf6e9b73e0051a0b581ee52b641f9ff00dd6b2f2
Reviewed-on: https://gerrit.instructure.com/46351
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
no significant issues/vulnerabilities fixed in this commit, rather this is
a catch-all so we can enforce linting in the build.
to better understand what's going on here, see the following:
* public/javascripts/.xssignore
* script/xsslint.js
* https://github.com/jenseng/xsslint
high level summary of what's going on in this commit:
1. .html/.append/etc. now know what to do with a SafeString ... in many
cases we now put a $.raw around an .html argument to tell the linter
it's ok
2. although translation is an unlikely attack vector, we now htmlEscape
I18n.t calls used in html snippets, etc. this is a good thing, as it
ensures we don't create a vulnerability later (e.g. by interpolating
user content into a translation)
3. many vars were renamed (Html suffix, $ prefix) to let the linter know
it's something that was manually vetted
4. in some cases, rather than renaming or creating a superfluous var,
we add special xsslint comment overrides
test plan:
specs should all pass
Change-Id: Ide1df825b798d1b0c468a5308802543bf716c0d7
Reviewed-on: https://gerrit.instructure.com/46097
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Derek Hansen <dhansen@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
this swaps out our "parsing" with i18nliner-js
also remove localization abilities of I18n.beforeLabel, since it's not
worth the trouble to support. it can still be called to format a string.
notable changes/fixes in generated yml:
1. client_apps are picked up by i18n:rake so they'll get translated...
due to the old short-circuiting logic (`rc = rc && ...`), it would
stop processing scripts within a particular file after the first one
it found without an I18n.t
2. we no longer incorrectly double-escape special chars in our js strings
(e.g. newlines are actually newlines, not a literal "\n")
test plan:
1. verify string extraction:
1. `rake js:generate i18n:generate` before and after this commit
2. confirm `config/locales/generated/en.yml` is identical, except the
notable changes/fixes listed above
2. verify js translation file generation:
1. `rake i18n:generate_js` before and after this commit
2. confirm the files in public/javascripts/translations are identical
3. verify client_app checker still works:
1. `cd client_apps/canvas_quiz_statistics/`
2. `grunt check_i18n`
Change-Id: Ic8ad058bee1c9476f42916f10b612c1c08863fe3
Reviewed-on: https://gerrit.instructure.com/42809
Reviewed-by: Michael Ziwisky <mziwisky@instructure.com>
Product-Review: Michael Ziwisky <mziwisky@instructure.com>
QA-Review: Michael Ziwisky <mziwisky@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
closes CNVS-15881
This mostly involved adding hooks to the gem for things that we were
directly modifying in Canvas, then hooking into those points in the
canvas config/initializers/delayed_job.rb file.
Periodic jobs scheduling changed a bit as well -- there's no longer
support in the extracted gem for reading a special file under config/,
so I moved our periodic_jobs.rb file to a normal initializer.
test plan: delayed jobs should still work as before, including queuing
jobs, running the worker pool, and in tests.
Change-Id: I9ce57091d18f21f4355011fcb75230193d53facb
Reviewed-on: https://gerrit.instructure.com/42027
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
and my fingers still want to type it. at least this will remove
it from my tab-complete
Change-Id: Id826cff0612c27bb54dc2c74925193b8f33a66cf
Reviewed-on: https://gerrit.instructure.com/41607
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
closes CNVS-14275
While we're at it, fix all the rspec deprecation warnings.
test plan: delayed jobs should still work as before, including queuing,
viewing in the UI, and running.
Change-Id: I36c6b74aa2b59a99e4f1f36e25e6d0e9e153f92a
Reviewed-on: https://gerrit.instructure.com/41211
Reviewed-by: Cody Cutrer <cody@instructure.com>
QA-Review: August Thornton <august@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
We compile sass using npm run compile-sass now, but the
script was still referencing the old (now deprecated) rake
task, which was causing updates to fail.
Change-Id: Idbedcf61ccccbdb0f1deb5907afb25d5d6650000
Reviewed-on: https://gerrit.instructure.com/40392
Reviewed-by: Nick Houle <nhoule@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Dave Donahue <ddonahue@instructure.com>
QA-Review: Dave Donahue <ddonahue@instructure.com>
...and print a message of what went wrong
test plan:
write some bad syntax in a sass file,
run `npm run compile-sass`
it should exit with non-zero status code
it should tell you what line of css caused the error
Change-Id: I0febb3286f6100993d5d2d53083d6a53719cbedf
Reviewed-on: https://gerrit.instructure.com/39385
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Colleen Palmer <colleen@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
after many steps towards this moment, we're finally here
This yanks sass and compass out of canvas-lms
completely and instead uses the libsass based
node-sass to compile our SASS files.
wins:
It is WAYYY faster!
as in, < 10 seconds to recompile all css in canvas
(compared to the 5+ minutes it used to take)
It is all in JS, helping use move to a completely
nodeJS based fronted tooling workflow.
next steps:
remove jammit: we don't need an assets.yml file
since node-sass can output compressed css for us
and we use sass to do all of our @import'ing of other
files (@colleen calls those "compiler" sheets), this
would simplify and speed up fronted asset building
even more
use gulp/broccoli/whatev to do cached, incremental builds
test plan:
all outputted css should look exactly the
same as it used to.
run `npm run compile-sass`, make sure it works
and is way faster than `rake css:generate` used to be
Change-Id: I7d865ea6b3e374cdc27a883d2019a4c15746c0e2
Reviewed-on: https://gerrit.instructure.com/38416
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
QA-Review: Trevor deHaan <tdehaan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
test plan:
* run `script/canvas_update`
* verify that the log output goes in /log
* verify that canvas was updated
* run `script/canvas_update -q` for QUICK_MODE
* verify QUICK_MODE's output is:
Quick mode enabled (assumes you have guard running and don't want to
generate docs)
Bringing Canvas up to date ...
Log file is /Users/lwilkins/sandbox/canvas-lms/log/canvas_update.log
Updating plugin vendor/plugins/canvasnet_registration ...
Updating plugin vendor/plugins/instructure_misc_plugin ...
Updating plugin vendor/plugins/multiple_root_accounts ...
Pulling Canvas code ...
Checking your gems (bundle check) ...
Gems are up to date, no need to bundle install ...
Migrating DB ...
Installing npm packages ...
Tips:
- 'bundle exec guard': auto-compiles JS files while developing
- 'script/delayed_job run': run delayed jobs in the foreground
NOTE 1) if you see
Gems are up to date, no need to bundle install ...
then `bundle install` will not be run
NOTE 2) after running this command, you'll be on master branch,
if you want to continue testing this script, checkout the
branch you pulled down again.
Change-Id: I99c3097d452128d6fffa31d25e3b7e57a438555e
Reviewed-on: https://gerrit.instructure.com/37423
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Braden Anderson <braden@instructure.com>
Product-Review: Landon Wilkins <lwilkins@instructure.com>
QA-Review: Landon Wilkins <lwilkins@instructure.com>
self.up works in rails2 and rails3, but up only works in rails3+
also tag the switchman migrations as RAILS3 only, now that they actually
run in rails2
Change-Id: I768c8e657e86de6504a40444d127e2d875ce6934
Reviewed-on: https://gerrit.instructure.com/35390
Tested-by: Brian Palmer <brianp@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Brian Palmer <brianp@instructure.com>
QA-Review: Brian Palmer <brianp@instructure.com>
fixes CNVS-12182
test plan
- regression test on incoming mail
- use script/process_incoming_emails to manually trigger the processing
of incoming mail
Change-Id: Iccd74d8fe2b5af3d5eefe25a2736273e3bf559b0
Reviewed-on: https://gerrit.instructure.com/32794
Reviewed-by: Simon Williams <simon@instructure.com>
Reviewed-by: Braden Anderson <banderson@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Trevor deHaan <tdehaan@instructure.com>
Product-Review: Joel Hough <joel@instructure.com>
Brad Horrocks