fixes CNVS-26161
test plan:
- with an RCS set up
- with remote RCS both on and off
- go to accounts/:account_id/settings
- go to the announcments tab
- make an announcment
- it works
- make an announcement with missing message
- the error message works
- edit an assignment with a missing description
- that error message works too
Change-Id: I4c3fc83fb59097f2ce5d4d0b868253c264ed477c
Reviewed-on: https://gerrit.instructure.com/69609
Tested-by: Jenkins
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
it was the rails 2 to 3 migration helper
Change-Id: I826fa7b260b27d1bea8afcd6c6ea860c9d0a290c
Reviewed-on: https://gerrit.instructure.com/68274
Reviewed-by: Rob Orton <rob@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Change-Id: I601320861bed38e6a37af17a8c65fa526735a9ac
Reviewed-on: https://gerrit.instructure.com/68255
Tested-by: Jenkins
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
closes CNVS-24124
makes working with web pack possible in canvas
instead of require-js. See doc/working_with_webpack.md
for instructions.
TEST PLAN:
Nothing should change in non-webpack'd behavior
Things should mostly work when you use the
USE_WEBPACK environment variable, but make sure to document
and ticket things that don't
Change-Id: I493a259a609e9e183950bc57aa5876df70108547
Reviewed-on: https://gerrit.instructure.com/64386
Tested-by: Jenkins
Reviewed-by: Clay Diffrient <cdiffrient@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
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>
Adds a docker-compose.yml file, some containers for dependencies, and
some docker-compose-friendly config files. See
doc/development_with_docker.md for instructions on how to use.
Change-Id: I5eaee8a3e3c84bb608282bfd44ec7d49a123ef5f
Reviewed-on: https://gerrit.instructure.com/45508
Reviewed-by: Zach Wily <zach@instructure.com>
Reviewed-by: Addison Higham <ahigham@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins
Product-Review: Zach Wily <zach@instructure.com>
QA-Review: Zach Wily <zach@instructure.com>
it to the gitignore file
Change-Id: Ic17f80370a000ed3e9800a5d9fb9a0547a30cde9
Reviewed-on: https://gerrit.instructure.com/47782
Reviewed-by: Benjamin Porter <bporter@instructure.com>
Product-Review: Colleen Palmer <colleen@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
QA-Review: Jacob Fugal <jacob@instructure.com>
Tested-by: Colleen Palmer <colleen@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 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>
This commit brings in canvas_quiz_statistics, a client app that can be
embedded in Canvas.
Closes CNVS-14781, CNVS-14846, CNVS-14847, CNVS-14850
> What's done
- full build integration, meaning the app runs with ?optimized_js=1:
+ JavaScript "built" source gets piped into the r.js build pipeline
like any other Canvas JS source in public/javascripts/*
+ SCSS sources get picked up by the sass-compiler like Canvas style
sources and they get compiled from the grounds-up
+ I18n: phrases are extracted properly, with default values and
options, by our i18n rake tasks
- new rake task js:build_client_apps that builds client apps and
injects them as input to the rest of the JS build process
- support for using Canvas JS packages, like d3, jQuery, and Backbone
- support for using Canvas SASS variables & helpers
- super i18n support: use raw I18n.t() calls like you are in Canvas,
with development-time interpolation, as well as super new
Handlebars-like block-style translations in React, perfect for very
long phrases (mini-articles)
> Docs and References
The code was originally developed in its own github repository. While I
won't be pushing code to that repo anymore, the Wiki will still house
the docs until we find a better place.
- Repo: https://github.com/amireh/canvas_quiz_statistics
- Development guide: http://bit.ly/1sNOhER
- Integration guide: http://bit.ly/1m9kA9V
> TESTING
- login as a teacher
- go to /courses/:course_id/quizzes/:quiz_id/statistics_cqs
+ make sure you see something that looks like the Ember stats
+ click one of those little "?" help icons, you get a dialog:
- verify the contents within the dialog are actual English text,
not code gibberish
- there's also a link at the end of that dialog, click it and
verify it takes you to an Instructure help article
- build the assets: `bundle exec rake canvas:compile_assets` then:
+ add ?optimized_js=1 to the URL and reload the page:
- verify the app still works
Change-Id: Ic474650dfb06a1c22869ed9680dd04d1ca0f651d
Reviewed-on: https://gerrit.instructure.com/39105
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Hannah Bottalla <hannah@instructure.com>
Reviewed-by: Adam Ard <aard@instructure.com>
QA-Review: Trevor deHaan <tdehaan@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
also switch rails3 lockfile to the default, so the spring binstub can
use the default lockfile and see itself
Change-Id: Id10cbc3df010671a59c73137a77583e2c2e0e5a8
Reviewed-on: https://gerrit.instructure.com/37802
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cameron Sutter <csutter@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
closes CNVS-12609
test plan:
- make sure rake i18n:generate still works
- basic regression of i18n in canvas
Change-Id: I882c7b6f197d65aa673a22225ae6a87ee4431aa0
Reviewed-on: https://gerrit.instructure.com/33760
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
QA-Review: Amber Taniuchi <amber@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
Refactoring the generation of quiz question statistics into its own gem.
This patch adds support for Essay question statistics.
Closes CNVS-12725
TEST PLAN
---- ----
- create a quiz with an essay question
- perform an API request to retrieve the quiz statistics
- ensure that the following metrics are generated and correct:
- "graded": number of students whose answers have been graded by the
teacher
- "full_credit": number of students who received a full score
- "point_distribution": a list of scores and the number of students
who received them (so if 2 students got graded for 3 points, it
should have a key of 2 and a value of 3), un-graded submissions
should be keyed under null
- "responses": number of students who answered the question
(wrote anything)
- "user_ids": IDs of those students
- documentation for QuizStatistics -> Essay should be updated with the
new stats
> Other things to test
- verify that the old statistics page still renders:
/courses/:course_id/quizzes/:quiz_id/statistics
- verify that you can still generate both student and item analysis
CSV reports
API endpoint for quiz stats:
/api/v1/courses/:courseid/quizzes/:quiz_id/statistics [GET]
Change-Id: Ib15434ff4cef89ac211c1f4602d1ee609ef48ec4
Reviewed-on: https://gerrit.instructure.com/33990
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Reviewed-by: Derek DeVries <ddevries@instructure.com>
Product-Review: Ahmad Amireh <ahmad@instructure.com>
fixes CNVS-11426
The UI/UX team *really* wants to start doing some major style changes
to the canvas interface. Because it is a very visual change and especially
because we've let people hack the crap out of canvas styles with
their own css override file, any changes we do need to be behind a
feature flag so an institution can opt-in when they are ready.
This commit does some trickery so we actually create 4 different versions
of every stylesheet. one for each variant in:
legacy_normal_contrast legacy_high_contrast
new_styles_normal_contrast new_styles_high_contrast
and then sets the $use_new_styles and $use_high_contrast sass variables
accordingly in each.
now, in any sass file, you can do things like:
@if $use_new_styles {
background-color: red;
} @else {
background-color: blue;
}
@if not $use_high_contrast{
font-size: 12px;
}
test plan:
* in a production (minified assets) environment, ensure you see:
<link href="/assets/common_legacy_normal_contrast.css... in the <head> of the page
* go to the account settings page for the domain_root_account you are on
* turn on the "Use New Styles" feature
* now verify that <link href="/assets/common_new_styles_normal_contrast.css...
is in the <head>. There should not be any visible differences because we do
not have any styles that target specifically $use_new_styles yet.
* now, go to /settings and turn on the user feature for "Use High Contrast Styles"
* verify that <link href="/assets/common_new_styles_high_contrast.css..
is in the <head>
* again, turning that on will not actually change the way anything looks,
the next commit (g/32863) will take care of that
Change-Id: I45ba4ddfe780c5c819fb995b61ebfc0a5325d418
Reviewed-on: https://gerrit.instructure.com/31881
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
QA-Review: Ryan Shaw <ryan@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
closes CNVS-11294
test plan:
- enable ember quizzes
- ensure that existing ember quizzes continue to work
- all existing ember tests should continue to pass
Change-Id: I4f56b1267504533be8332520ea5f77d2fa566263
Reviewed-on: https://gerrit.instructure.com/33105
Reviewed-by: Derek DeVries <ddevries@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
Product-Review: Jason Madsen <jmadsen@instructure.com>
Change-Id: I2af3335578140c943b962dee7fa506bba62948d3
Reviewed-on: https://gerrit.instructure.com/32171
Reviewed-by: James Williams <jamesw@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Simon Williams <simon@instructure.com>
QA-Review: Simon Williams <simon@instructure.com>
- js:generate_runner now generates common files to be used by different test runners
- js spec file order now shuffled to better expose dependencies
- fakeENV now returns two methods: setup and teardown
- stock tinymce 3 files are now wrapped for AMD
test plan:
- tinymce should work the same
- js:test rake task should run tests
- js:build task should work as normal (using new location of r.js)
- test results should successfully send to firework
Change-Id: Ic09647f55dae57130fa0fe3d6a9168d2b67b89a2
Reviewed-on: https://gerrit.instructure.com/29297
QA-Review: Shawn Meredith <shawn@instructure.com>
Tested-by: Shawn Meredith <shawn@instructure.com>
Tested-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
Reviewed-by: Aaron Shafovaloff <ashafovaloff@instructure.com>
Product-Review: Aaron Shafovaloff <ashafovaloff@instructure.com>
QA-Review: Aaron Shafovaloff <ashafovaloff@instructure.com>
test plan:
- run "rm -rf spec/javascripts; git checkout HEAD --
specs/javascripts" to reset your compiled javascript tests.
- run rake js:generate_runner
- JS tests should pass
- # of JS tests should be the same as they are on master before this
commit
Change-Id: I936aec8a8a5e2cc739e09757c622f300e99c72ef
Reviewed-on: https://gerrit.instructure.com/25615
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Product-Review: Bryan Madsen <bryan@instructure.com>
QA-Review: Bryan Madsen <bryan@instructure.com>
also added styles to make .form-controls look
good in dialogs.
closes #CNVS-4302
Change-Id: Ibe54ee4046ac255b0b0ea83d32afc88e4a820464
Reviewed-on: https://gerrit.instructure.com/19331
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
QA-Review: Ryan Florence <ryanf@instructure.com>
Product-Review: Ryan Florence <ryanf@instructure.com>
test plan:
- make sure you have the coffee binary from npm:
`npm install -g coffee-script@1.6.2`
- run rake js:generate, make sure all coffeescript still compiles
correctly
- open a coffeescript file and make sure it still gets automatically
compiled when saved by guard.
- rejoice at the arrival of source maps.
Change-Id: I06ce9e83a76be9d4cc0e2b2c80566a0db19f9d7e
Reviewed-on: https://gerrit.instructure.com/18842
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Product-Review: Stanley Stuart <stanley@instructure.com>
QA-Review: Stanley Stuart <stanley@instructure.com>
This can successfully load rails console and rails server. There are
many, many problems still. The idea is this won't change anything under
rails 2.3, it's all backwards compatible.
closes CNVS-4711
test plan: `touch RAILS3` in your Canvas Rails.root directory. The run
`bundle update` and verify that you get rails 3 installed. Run `bundle
exec rails c` to load console or `bundle exec rails s` to start a
webrick server. You can login, though the dashboard currently breaks.
Also jammit isn't working yet.
But more importantly, Rails 2.3 should still work same as ever. All
tests should pass, and a basic regression sanity check would be good too.
Change-Id: Idd6f35de88adde84cd2db3a650f44b71bd6e9684
Reviewed-on: https://gerrit.instructure.com/18453
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Clare Hetherington <clare@instructure.com>
Product-Review: Bracken Mosbacker <bracken@instructure.com>
don't need this, plus ** isn't supported on all platforms
Change-Id: I69eb02143624bdf82497dcd997eb0e8c834ac51f
Reviewed-on: https://gerrit.instructure.com/17024
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Joe Tanner <joe@instructure.com>
Reviewed-by: Stanley Stuart <stanley+gerrit@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
remove a lot of things that are no longer relevant, DRY it up a bit and
make it a bit more explicit (root paths, better globbing)
test plan:
1. `git status`
2. all your previously ignored stuff should still be ignored, except
perhaps editor stuff, which should really go in .git/info/exclude
Change-Id: I0c0f6dc3cd969bb6f90f26c1af83f1bd7ef852e4
Reviewed-on: https://gerrit.instructure.com/16994
Reviewed-by: Joe Tanner <joe@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Jon Jensen <jon@instructure.com>
allows plugins to have a bundle get auto-loaded with a corresponding
canvas bundle. uses require.js' include mechanism in build.js (when
optimized) and a rails helper tweak (when not optimized).
this happens automatically based on the path, e.g. the foo plugin's
"bundles/extensions/bar" will get automagically included whenever the
regular "bar" bundle is required.
removes the need for a plugin-level build.js, and auto-generates bundle
module definitions in canvas' build.js (via erb). this handles all
regular bundles both from canvas and plugins.
also fixes plugins so that bundle dependencies get optimized. plugin
paths are created automatically, so this means we can remove things like
this from plugin bundles and specs:
require.config
paths:
myplugin: "/plugins/myplugin/javascripts"
test plan:
1. use canvas in development mode, it should work
2. use canvas in optimized JS mode, it should work
i. confirm that all scripts are optimized
3. use canvas in development mode with plugins w/ JS, it should work
4. use canvas in optimized JS mode with plugins w/ JS, it should work
i. confirm that all scripts are optimized
5. add a bundle extension in a plugin (e.g. create
bundles/extensions/conversations in plugin foo)
i. confirm that the extension code runs in development mode
ii. confirm that the extension code runs in optimized JS mode
Change-Id: If8507afdbabab4ae8966f7db79d9b0e2284034db
Reviewed-on: https://gerrit.instructure.com/11238
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
no more maintaining spec/javascripts/supports/specs.js to tell the
runner which specs to run. instead, the runner is built from an erb that
determines the list of specs to run from the filesystem. this new way is
also plugin friendly by maintaining a plugin symlink to include plugin
specs in the spec/coffeescripts tree.
second, give the runner page to the phantomjs execution as a file:///
path rather than just a local path. the latter worked on the build
machine, but failed with the phantomjs installed viw macbrew.
third, clean up/out some slightly broken specs.
* ENVSpec fails when the specs are reordered by the dynamic globbing,
but is no longer necessary anyways (since ENV is global now)
* the 'specs/helpers/' path in TemplateSpec doesn't work with the new
setup, but just 'helpers/' does and is what it should have been using
before anyways.
* asyncTest is not reliable. once the specs started running in a
slightly different order (thanks to the initial point), they started
failing with asyncTest race conditions. use fakeTimers and
fakeServers instead when appropriate.
* found and fixed a minor bug in BackoffPoller while converting/fixing
its asyncTests
test-plan:
- run rake js:test; should run completely as before
- add a plugin with a spec in spec_canvas/coffeescripts then run rake
js:test again; the plugin's spec should be executed.
Change-Id: I9ce5a038829a9e747df26d878ce86dbb7da8c384
Reviewed-on: https://gerrit.instructure.com/9411
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
while guard was watching and handling most of this, it wasn't happening
on deploy.
Change-Id: Ia4682b5487381ac741db5d2a7b1e8199495510d0
Reviewed-on: https://gerrit.instructure.com/9293
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
test plan:
* install a plugin with a public directory
* remove public/plugins
* start script/server
* it should generate public/plugins/<plugin>
* remove public/plugins
* run rake canvas:compile_assets
* it should generate public/plugins/<plugin>
Change-Id: I0acd530dfc29d3263abed01f27d6eb449b6d029b
Reviewed-on: https://gerrit.instructure.com/8994
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
test plan:
* in a class with a ton of assignments, open
gradebook2, make sure the header column doesn't
wrap.
Change-Id: Ie1a178a3f28f3d6c8554330bad8131f69790b569
fixes: #7195
Reviewed-on: https://gerrit.instructure.com/8628
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jake Sorce <jake@instructure.com>
"Trivial" JavaScript / CoffeeScript changes
--------------------------------------------------
For the most part, all javascript was simply
wrapped in `require` or `define`. The dependencies
were found with a script that matched regexes in
the files, it errs on the side of listing too many
dependencies, so its worth double checking each
file's dependencies (over time, anyway).
i18n API changes
--------------------------------------------------
No longer have to do I18n.scoped calls, just
list i18n as a dependency with the scope and it's
imported already scoped
require ['i18n!some_scope'], (I18n) ->
I18n.t 'im_scoped', 'I'm scoped!'
JS bundling now done with r.js, not Jammit
--------------------------------------------------
We don't use jammit to bundle JS anymore. Simply
list dependencies for your JS modules in the file
and RequireJS handles the rest.
To optimize the JavaScript, first make sure you
have node.js 0.4.12+ installed and then run:
$ rake js:build
The app defaults to the optimized build in
production. You can use non-optimized in
production by putting ?debug_assets=true in the
url just like before.
You can also test the optimized JavaScript in
development with ?optimized_js=true.
Significant changes
--------------------------------------------------
These files have "real" changes to them (unlike
the JavaScript that is simply wrapped in require
and define). Worth taking a really close look at:
- app/helpers/application_helper.rb
- app/views/layouts/application.html.erb
- config/assets.yml
- config/build.js
- lib/handlebars/handlebars.rb
- lib/i18n_extraction/js_extractor.rb
- lib/tasks/canvas.rake
- lib/tasks/i18n.rake
- lib/tasks/js.rake
Change-Id: I4bc5ecb1231f331aaded0fef2bcc1f3a9fe482a7
Reviewed-on: https://gerrit.instructure.com/6986
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Test plan:
- open a file in vim
- open that same file in another vim
- git stat
Change-Id: If79e3393b81e15fd970235c8d77225c0acd0b476
Reviewed-on: https://gerrit.instructure.com/8203
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cameron Matheson <cameron@instructure.com>
test plan: run the doc:api rake task, verify the docs are still
generated
Change-Id: I9f372a8e68de1019619b452c14f1ebbb1895cecf
Reviewed-on: https://gerrit.instructure.com/7745
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
this means that if someone pulls the repo,
they need to run:
bundle exec canvas:compile_assets
...before doing script/server
Change-Id: Ib1ac917f9e6f05db6feb53868d7123cb2dbee14c
Reviewed-on: https://gerrit.instructure.com/7464
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
they should be written in coffeescript
Change-Id: I82a9a86b9f31ac0155caeac4a8ac8bb7b17c7059
Reviewed-on: https://gerrit.instructure.com/7185
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
we can do this because if someone is running qUnit
tests we can expect they have all the gems in the
"test" gemset so they will be using guard.
Change-Id: I751e14a09aae3356fdd543c2dd822354e113b326
Reviewed-on: https://gerrit.instructure.com/7090
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
- New rake task `rake jst:compile` to precompile
JavaScript templates into functions.
Add handlebars templates to app/views/jst and
they'll get compiled to public/javascripts/jst
- New rake task `rake jasmine` and `jasmine:ci` to
run JavaScript specs.
Add specs to spec/coffeescripts and they'll get
compiled into spec/javascripts
- Added Guard gem `$ guard` that watches
coffeescript and handlebars files and compiles
them when changes are made.
- Created Handlebars Ruby class that precompiles
the templates into JavaScript functions
- Added JS Template constructor to abstract
our tempting API
Change-Id: Ie993d0fc50d49b161ed94dbc066c4475cefdc427
Reviewed-on: https://gerrit.instructure.com/5813
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Once rake doc:api or canvas:compile_assets is run, the API will be
accessible from within Canvas at /doc/api/index.html
Change-Id: I503701c0ef3dc0df0ea67477053b328411553352
Reviewed-on: https://gerrit.instructure.com/4723
Reviewed-by: Zach Wily <zach@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Michael Nomitch