don't throw js error on clicking curve grade button

fixes: #7705

test plan:
* open the curve grade dialog in gb2
* press submit
* make sure it doesn't throw js error

Change-Id: Iffadb82a19f95aedafc8ccb4a4be3340b164fc8f
Reviewed-on: https://gerrit.instructure.com/9388
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
fix todo bug introduced in 17494bce1a745af20c8ec20

Test plan:
  - go to a course page without logging in

Change-Id: I185f74f41cbe547efdba41064f650b5fe7ed2e5a
Reviewed-on: https://gerrit.instructure.com/9080
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
ensure conversations with deleted users load correctly

fixes regression from #7471

test plan:
1. start a conversation with another one or more users
2. delete one of the users
3. ensure the conversation still loads (you should see all participants
   and messages)

Change-Id: Ic0e567f22010864054f7396553b43173110be317
Reviewed-on: https://gerrit.instructure.com/9211
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cameron Matheson <cameron@instructure.com>
prevent group discussion assignments from spawning jobs recursively

discussion topics touch their root topics when they are saved so that post
counts get updated correctly. However, when the discussion is part of a group
assignment, part of the post save logic is to update the child topics to keep
the topics for each group in sync with the root topic. This was done in
a delayed job, and was kicking off a recursive job.

test-plan:
- with delayed jobs running
- create a group discussion assignment
- make sure delayed jobs for #refresh_subtopics don't start growing out of
  control

Change-Id: I592275db18239ba49eaed766dfab5ff1439e3024
Reviewed-on: https://gerrit.instructure.com/9431
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
don't cache tinychat settings on the Tinychat class

This was preventing us from changing the Tinychat settings for different
accounts. I also removed the tinychat.yml.example file, as people should be
using the /plugins interface now.

Change-Id: I5fe6bbf72563f75e9cbfadf1f661715b40a5fc33
Reviewed-on: https://gerrit.instructure.com/9427
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
load account javascript ourselves

Change-Id: Ifeae50a64035edecf81a5f97eee13c2f64cbdb65
Reviewed-on: https://gerrit.instructure.com/9220
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
don't cache discussion topic html to work with marking as read

Change-Id: I116059708a3271c6dce786d7286b85bc24cc536f
fixes: #7724
Reviewed-on: https://gerrit.instructure.com/9430
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
move ungraded count migration to dj

Change-Id: I8f901d1618686ec98341a594cabf6b71183a89fb
test-plan: n/a
Reviewed-on: https://gerrit.instructure.com/9372
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
discussions: only notify people in course or group

fixes #7490, refs #7483

Test plan:
- make a disussion topic
- make a discussion entry with a student, and then end that student's
  enrollment in the class
- make a discussion entry with a different student; the original student
  should not receive a notification

Change-Id: I6465363bc8e99ebe431c9483c9a569a68d3f852e
Reviewed-on: https://gerrit.instructure.com/9161
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
modify data fixup to work in batches of assignments at a time

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>
don't try to update the whole AssetUserAccesses table at one time

test plan:
 * run DataFixup::UseAssetUserAccessLastAccess on a table with millions of
   entries
 * see that the db didn't get backed up by people trying to update
   asset_user_accesses

Change-Id: Ia94c8ca19a57b7067213ef521809b94c678a94d0
Reviewed-on: https://gerrit.instructure.com/9465
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
retry updating discussion participant on duplicate key error

A race condition could cause this method to be called twice nearly in
parallel, meaning both processes would try to create the participant. The
second would fail due to the unique constraint. This catches the unique
constraint violation and retries, which means it will find the already created
one and do an update. (This is what we're opting to do instead of some global
locking for inserting discussion participants - it's optimistic locking.)

test plan:
 * this will only work in an environment where multiple rails processes are
   running. meaning: not development mode with webrick. :)
 * create a discussion topic and add a couple short replies.
 * make sure your window is tall enough to show both replies at the same time
 * log in as another user in that course and go to that discussion
 * verify that you don't get an ajax error, and unread counts get updated
   correctly

Change-Id: I35f6119cabaef890a228c570799b7b3c88bf3f74
Reviewed-on: https://gerrit.instructure.com/9467
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
exclude deleted discussion entries from read counts; fixes #7741

we were including deleted discussion entries in our default unread counts, but
there was no way to mark these as read from the UI so it looked like the counts
were just off.

test-plan:
- run the migration and make sure existing unread counts look good
- create a discussion, make some entries, and delete some
- as a different user, view that discussion and make sure counts look right

Change-Id: I601fc7e0726a7982a2843b5a8a71cf782e5092eb
Reviewed-on: https://gerrit.instructure.com/9468
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
lock discussion_topic_participant row for updating when updating read counts

We need to lock this to serialize updates of the count, so they don't get off
due to race conditions. We also have to make sure the AR query cache is
disabled when using the unique_constraint_retry. If it's not, then on the
retry we might just get the results from the first query out of the cache.

It's possible that that might be generally applicable to all
unique_constraint_retry usage, but it hasn't been thought through yet.

test plan:
 * in a production-like environment:
 * create a discussion topic, and some short entries on it (at least 3)
 * load that topic with a tall window as a lot of different users
 * verify that the visible posts get marked as read, and on reload, the
   unread count stays correct.

Change-Id: I3e0cbebe991bbaaf74f4c8408cbe2214fca80eec
Reviewed-on: https://gerrit.instructure.com/9469
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
treesame commit of origin/stable/2012-03-17

Treesame-Commit-Id: 8f48fee5d3b68e36988cf8d9295281a4a0198980