Return the HTML as an ext ics attribute for those few clients that
support it (Outlook), and return better-formatted plain text for all
other clients.
closes#9107
Also refactor a bit.
test plan: add assignment and calendar events to the calendar with
links, formatted text, etc in their descriptions. Export the calendar
feed. In Outlook, you'll see the full HTML of the event. In most other
clients, you'll see a plain-text version of the description, but it'll
be much better formatted than it was before.
Change-Id: I50af1c407483d84c65ca285cbf364b6a303e0379
Reviewed-on: https://gerrit.instructure.com/11891
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
when creating a directory for a plugin symlink, the parent directory may
also not yet exist. use FileUtils.makedirs (behaves like mkdir -p)
instead of Dir.mkdir to ensure the full path is created as necessary.
Change-Id: Iafc00c945923c40613fffd9206a1e45ecb735cb6
Reviewed-on: https://gerrit.instructure.com/11915
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
it was taking a long time to query all existing foreign keys each
time the method was called, so instead just catch the exception that
occurs, and ignore it
Change-Id: Ic4d0d9a4d388aca4cd44eeb1b39d59a3d6c83bfe
Reviewed-on: https://gerrit.instructure.com/11860
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@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>
fixes#9080
if I18n.localizer has been set it, call it during BasicLTI
generation instead of waiting for the first call to translate.
this ensures that the locale is set in time for it to be
populated in the launch_presentation_locale param.
test plan:
* enroll a user in two courses that are offered in two different
languages (e.g. an english course and a spanish course);
* open each course in separate window, and create an external tool
assignment that opens in a new tab in one of the courses;
* load the external tool page, and verify that the value of the
#launch_presentation_locale form element is correct;
* in the second course, load a page;
* reload the external tool page and verify that the
#launch_presentation_locale value is still correct and not the
language of the second course.
* repeat these same steps using different users for each course
* and
verify that the locale is still properly set in the external
tool field.
Change-Id: If4b996317be23a17c824b8000026ac9b7549e0a4
Reviewed-on: https://gerrit.instructure.com/11675
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
test plan:
* ensure specs pass
* test around gradebook and teachers that should only be able to see
their section(s)
Change-Id: I86e431388a414f4edef7e59329c8a5e449f26e7f
Reviewed-on: https://gerrit.instructure.com/11709
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
test plan:
* ensure current specs pass, and no functionality changes
Change-Id: I7296f63421eb8041c1f33277244e6b745197e972
Reviewed-on: https://gerrit.instructure.com/11619
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
See http://seclists.org/oss-sec/2012/q2/504
test plan: Should be covered by unit tests.
Change-Id: I96b32f6e1056e26c9ca343b317492bcb5504a45a
Reviewed-on: https://gerrit.instructure.com/11568
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
remove type, and the CourseAssignedGroup model which isn't used.
remove groupable_id and groupable_type which looks it could have been
a precursor to groups being a context, and is also not used.
test-plan:
- make sure migration runs
- make sure groups pages still load
Change-Id: I868a8c4d405e20f147de4ee23a33c946dd5691d0
Reviewed-on: https://gerrit.instructure.com/11290
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
the datafix logic got mistranslated when we switched to run in batches, so that
only 0.2% of NotificationPolicy objects were being considered for deletion.
test plan:
- set your 'For administrative alerts' notification to something other than
immediate
- run the fix
- do a course export
- you should get an email when it completes/fails
- try this for a few different users
Change-Id: I29f2a0704294ad9e0a055d2a67cc5397f69af8b6
Reviewed-on: https://gerrit.instructure.com/11256
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
adds a 6-character self enrollment code. the longer version is still
supported (since links may be in the wild). courses that already have
self enrollment enabled will get a new 6-char code when someone self-
enrolls or goes to the course settings page.
test plan:
1. on the old code, create a course and enable self enrollment
2. save the self enrollment url (for step 6)
3. on this new code, go to the course settings page
4. confirm that you see the new 6-char code in the link
5. confirm that the code was saved on the course (check db or console)
6. as a student, confirm that you can enroll using the old link
7. as a student, confirm that you can enroll using the new link
8. create another course and enable self enrollment
9. as a student, confirm that you can enroll using the new link
Change-Id: I6d549b50febc3dcb596a7c6b882701aa58b5441b
Reviewed-on: https://gerrit.instructure.com/10835
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jon Jensen <jon@instructure.com>
also fixed user merging so that observer enrollments get merged when
merging observed users
test plan:
1. test observer enrollment creation/updating
1. enroll a student in some courses
2. create another user
3. add that user as an observer of the student (via console)
4. confirm that the user gets enrolled as an observer in the student's
courses
5. enroll the student in another course
6. confirm that the observer is also enrolled
7. conclude the student's enrollment in a course
8. confirm that the observer's enrollment is also concluded
2. test observer enrollment consolidation (via user merge)
1. observe two users in a course
2. merge the users
3. confirm that you just have one observer enrollment after the merge
3. test observer enrollment creation (via user merge)
1. enroll user 1 in course A
2. enroll user 2 in course B
3. observe user 1
4. merge the users (either direction)
5. confirm that you are now observing the user in both courses
Change-Id: Ic5ab29157ab8fc8dc9e7b32cafebbb1290bd4f6b
Reviewed-on: https://gerrit.instructure.com/10811
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cameron Matheson <cameron@instructure.com>
spec updates for 1.9
* fix a syntax error
* update our html_escape backport so that rails 1.9 doesn't print
constant warnings about using the "n" regex option with a utf-8
string (as a bonus this is also a lot more efficient)
* fix using a migration class as a rspec describe context, because its
method_missing prints the method name to console so we get a ton of
"to_ary" etc printed
* fix post header checks in spec/lib
Change-Id: I634570e516252e9a2fbef9f13a55d1bae0a254cd
Reviewed-on: https://gerrit.instructure.com/10856
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
thanks to UserVoice for their blog post outlining these necessary fixes
* fixes association proxies, causing the submission comment spec to pass
* fixes encoding issues with params in action controller -- fixes a lot of failing api specs
* fixes compat issues with TZInfo
Change-Id: Iaa6626a2107a437013c2a783c5929610f076b352
Reviewed-on: https://gerrit.instructure.com/10795
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
test plan:
* log in
* accept a course invitation
* add google docs to your profile
* everything should work, including flash notices
* if you keep refreshing the same page, the server should only send
the cookie once every five minutes
* if you haven't visited any page in 1 day, and you click go back,
you should be logged out
Change-Id: Iee283829f6d81b241b87a50ae0e8fa18c051b89a
Reviewed-on: https://gerrit.instructure.com/10632
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
fixes#7202
test plan:
* Use postgres
* Have pg_collkey installed
* Add users whose last names are subsets of each other
* Grade CSV, speedgrader, accounts page, etc. should sort them correctly
(shorter last name first; case insensitively)
Change-Id: Idec2a9f0e89c4f4479b4fd54136291273ba49ad9
Reviewed-on: https://gerrit.instructure.com/10497
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Mark Ericksen <marke@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
* gemfile tweaks
* removed ruby-debug (since it's broken in 1.9.3)
* removed colons from case statements
* turned off whiny nils for tests (they cause a 2X perf hit)
* added utf-8 encoding markers to files with multibyte chars
* removed an instance of calling String#map, which no longer works
* fixed an issue in the assets file where the yaml emitter doesn't output the
same whitespace as it did in 1.8.7
* fix call to .map without block
* fix yaml engine initialization for delayed jobs (was happening too late)
* fix rspec instafail
* fix UserProfile#id calls
* fix ModelCache for instance_methods now returning symbols
* fix user_spec collection not seeing the new objects
* fix course specs where POST lines are slightly different in 1.9
* fix utc_datetime in the time initializer
Change-Id: Ic95dda23cb910579e2828fb448323d4fc18902a2
Reviewed-on: https://gerrit.instructure.com/10705
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Zach Wily <zach@instructure.com>
instead of leaving the key with a nil value
test plan:
* no user visible changes
* creating a new course, accepting invitations, and
registering google docs, linked in, and twitter are good places
to make sure they haven't changed
Change-Id: Ied684744dd23a4c56c1abab0e7c197a28cd66f40
Reviewed-on: https://gerrit.instructure.com/10633
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
* add the foreigner gem so plugins can begin adding foreign keys
immediately
* add an extension to do less locking when creating foreign keys
on postgres 9.1+
* fix a few pieces of code that either don't properly clean up
foreign dependencies, or create objects in the wrong order
to maintain referential integrity
* change the specs to truncate all tables in a single command
for postgres (to avoid referential integrity errors; also
slightly faster)
test plan:
* no user visible functionality should change
Change-Id: I185e478b99fbe598d408912053c34a064aa9c461
Reviewed-on: https://gerrit.instructure.com/10580
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
slightly modified unique_constraint_retry so that:
1. it runs the block without using the query cache
2. it doesn't capture the UniqueConstraintViolation on the second failure
(should be impossible now, so we definitely want to know if it does)
also fixed a more general issue where inserts would not clear the query
cache if they raised a database error (e.g. violated a constraint)
test plan:
1. in two rails consoles, call Assignment.find_or_create_submission for
the same user/assignment at the same time inside of a query-cached
transaction, ensuring that they overlap, e.g.
Assignment.cache {
Assignment.transaction {
s = Assignment.find_or_create_submission(1, 1)
sleep 10
s
}
}
2. confirm that both commands complete successfully and return the newly
inserted submission
3. ensure that there is only one duplicate key error in your rails log
Change-Id: I128d331081229d640fb27c011b0216e25a59263c
Reviewed-on: https://gerrit.instructure.com/10400
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
this is equivalent to our custom addition to do this escaping (though it
also escapes amperstands, which ours didn't)
test plan: do an api request that returns a json string with html
entities, or just load up the console and do a "<>&".to_json
Change-Id: Ifaeaa595de4bd621708b43c45f915a67409ef95a
Reviewed-on: https://gerrit.instructure.com/9614
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
changes quiz editing UI such that you can't exceed 1000 questions. quizzes
that already have over 1000 questions can still be edited, but new
questions cannot be added. this limit covers both regular questions as
well as question groups (e.g. "pick 20 of the following questions"). the
changes only affect the quiz UI and have no impact on question banks, or
on quizzes or banks created/updated via import.
also doubles the Rack::Utils.key_space_limit to 128 KB so that (most)
existing large quizzes can be taken successfully. this sets a rough upper
bound of ~1500 questions for a quiz.
test plan:
1. on the old code, create a quiz with > 1000 questions (easiest via
question groups)
2. on the new code, confirm that you can edit and remove existing
questions on the quiz.
3. confirm that you cannot add any questions (either standalone or via
groups) until the total is below 1000 again
4. take a quiz with 1000 questions
5. confirm that you can submit the quiz without getting a 500 error
Change-Id: Ifa211ed5baa461351e747dac3266f77623626f3c
Reviewed-on: https://gerrit.instructure.com/10094
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
so that a plugin can require it from its init.rb, without pulling in
all of our other AR extensions
Change-Id: I1f72d5f23e1437049820860f52abab29c12b6248
Reviewed-on: https://gerrit.instructure.com/10191
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
respect "hidden" flag such that we don't show parent events of section-
level events in the calendar or upcoming events.
when viewing the section-level event's details, show the section name.
when editing a section-level event, don't allow changing the title.
link to parent event when clicking "more options"
test plan:
1. create an event with section-level child events (currently only
possible via api or console)
2. go the course calendar (calendar2)
1. confirm that the parent event is not visible
2. confirm that the section-level events are visible
3. click on a section-level event
4. confirm that the section name appears in the details
5. edit a section-level event
6. confirm that you can change the date/times but not the title
7. click the more options link and confirm it takes you to the parent
event
3. go to the dashboard
1. confirm that the parent event is not visible in upcoming events
2. confirm that the section level-events are visible
Change-Id: I8eadc53b7c47922f753625930d94d4f08386c817
Reviewed-on: https://gerrit.instructure.com/10116
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Reviewed-by: Cameron Matheson <cameron@instructure.com>
added a child_event_data attribute that can be set during create and
update for specifying child events. the initial use case is for section-
level events under a course. other context types will return an error
child_event_data should be an array of objects representing the child
events. each object must have a context_code and may have a start_at/
end_at, e.g. child_event_data[0][context_code]=course_section_1&...
when updating a calendar event, child_event_data will replace previous
child events (creating/updating/deleting, as appropriate)
to delete all child events when updating, set remove_child_events=1
when querying events for a given course (via index), child events for the
course's sections will now appear (limited to the user's visibility)
test plan:
1. create a calendar event via the api and specify child events
2. confirm that they were created correctly
3. confirm that the index action returns those child events when searching
by course
4. update the calendar event and change the child events
5. confirm the child events were deleted successfully
6. update the calendar event and delete all child events (via
remove_child_events=1)
7. confirm the child events are deleted
8. delete an event that has child events
9. confirm that the child events are deleted as well
Change-Id: If94b17a9c33ca3a56f7b97908c8c659e12364d8b
Reviewed-on: https://gerrit.instructure.com/10021
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
count can be slow if there are a lot. also remove the "last" link
from api responses that skipped the count
test plan:
* go to a user's page with less than 50 page views; they should show
and it should not try to load more
* go to a user's page with hundreds to thousands of page views; they
should load on demand, and when you reach the bottom, it should
stop trying to load more
Change-Id: I934cd7260232b78c33ae5fc1be5e49b2ea686614
Reviewed-on: https://gerrit.instructure.com/10135
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
test plan:
* run Reporting::CountsReport.process; it should work
* add a slave db configuration as a child of the current
environment to database.yml; re-run the CountsReport
Change-Id: Iba08d6697cf0e864ecbc3a2829fcd7a134267bec
Reviewed-on: https://gerrit.instructure.com/10100
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
like find_ids_in_batches, but returns a closed range of the ids,
instead of the actual ids so that whatever's iterating over the
table doesn't have to use a huge IN clause
test plan:
* run the specs
Change-Id: Id22c197a6e4d80db49cc6ec99bb3e79e6fb69523
Reviewed-on: https://gerrit.instructure.com/10066
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
start tracking root_account_ids more consistently for messages, and
aggregate them on the conversation. add a scope when masquerading such
that conversations tied to other root accounts are hidden. a masquerader
must have access to all root accounts a conversation belongs to in order
to see it (unless the masquerader is a site admin)
test plan:
1. enroll a user in courses under two different root accounts (let's call
them accounts A and B)
2. as the user, log in under the account domain for A and send some
messages
3. log in under the account domain for B and send some messages to
the existing conversations, as well as to some new recipients
4. set up an account admin with access only to B
5. log in as the admin, and masquerade as the user
6. ensure you can only see conversations created under B (none of the ones
that are solely A, or both A and B)
7. log in as a site admin, and masquerade as the user
8. ensure you can see conversations from both accounts
Change-Id: I4a26b8b8914fd531103bb92c3d4442de843d9986
Reviewed-on: https://gerrit.instructure.com/9767
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jon Jensen <jon@instructure.com>
Fixes a race condition where the view might get generated by the job
without the new entry.
test plan: this is difficult to duplicate by hand, but you could put a
breakpoint in and verify the job doesn't get inserted before the
transaction commits.
Change-Id: I6c373553dfae409adab25dd9e3bafc7126169231
Reviewed-on: https://gerrit.instructure.com/9710
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@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>
test plan:
* run the migration and the created job, verify that it touches the
whole assignments table but in batches of 1000
Change-Id: If56aa8152cc0e0fc273a1a949dd4e2b922b39d3b
Reviewed-on: https://gerrit.instructure.com/9466
Reviewed-by: Zach Wily <zach@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
test plan:
* set perform_deliveries: false in outgoing_mail.yml
* verify outgoing mail no longer happens, but you don't get a ton
of error_reports for failed deliveries
Change-Id: I18b6cacc8fc7e79c60969728d5caf0a06caaf91a
Reviewed-on: https://gerrit.instructure.com/9338
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@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>
we never add/remove migrations while code is running, and expect to
pick up the changes without restarting the process, so this is fine
test plan: n/a
Change-Id: I8420e99bc32b0eb5b166e870b31d8bdb02a7b164
Reviewed-on: https://gerrit.instructure.com/9010
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
rake db:migrate:predeploy and db:migrate:postdeploy only run so-tagged
migrations. Additionally a migration tagged as both (i.e. an idempotent
data migration) will not be marked as run during predeploy, even though
it is run.
test plan:
* mark some existing migrations with pre or post deploy, unmigrate them,
and verify db:pending_migrations shows their tags, and the appropriate
rake task runs the correct migrations, and marks them as run
appropriately
Change-Id: I8a787c5f08fe0ab6855cce759aa4eef6de5045d2
Reviewed-on: https://gerrit.instructure.com/8472
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
test plan:
* run the migrations against postgres - confirm by looking at logs
that most migrations run in a transaction, but those modified
here do not
Change-Id: I4820d982e2ce6abd21bde0c882b3177c3f11984e
Reviewed-on: https://gerrit.instructure.com/8456
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@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>
adds a "Message Users Who..." option to the appointment group context
menu which spawns a dialog similar to the one found in the gradebook.
adds an api endpoint to get users or groups for a given appointment
group (all eligible, registered, and not-yet registered)
test plan:
1. create an appointment group for users
2. sign up one or more users
3. open the Message Users Who dialog
4. ensure that the right users appear when the registered users option
is selected
5. send a message and ensure it goes to those users
6. repeat steps 3-5 for unregistered users and all users
7. repeat steps 1-6, but for a section-level appointment group (the
users should be limited just to those in the section)
8. repeat steps 1-6, but for groups instead of users (e.g. create an
appointment group for a particular group category, and sign up a
couple groups)
Change-Id: I3dc74c597d9846afb6a3ffe19e7f6ec09e98e8dc
Reviewed-on: https://gerrit.instructure.com/8447
Reviewed-by: Cameron Matheson <cameron@instructure.com>
Tested-by: Jon Jensen <jon@instructure.com>
Brian Palmer