Test plan:
(We need two users here because Canvas doesn't notify you about
files you upload yourself. We'll call them Student and Teacher
here, but they don't actually have to be these things.)
* As Student, enable notifications for new files in Profile.
* As Teacher, upload a file.
* Within an hour or so (everything about notifications occurs
in low-priority background tasks), Student should receive
a notification for the file.
* As Teacher, upload multiple files.
* Student should eventually receive a notification that
X number of files were added.
Note that files are batched over a five-minute period; that is,
if a file is added to a course within five minutes of a previous
file, it will be counted in the same batch.
Change-Id: I09b5f497cae1d726b7aaf85824e98e69e45b0c1b
Reviewed-on: https://gerrit.instructure.com/12346
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Users can validly be nil for wikis/discussions from content
imports. This makes the UI a little nicer for those cases
Test Plan:
* Import content from a .zip that has wiki pages in it
* The wiki page history should say Content Importer instead of having no name
* The individual revision page should say it was imported at a time
closes#8053
Change-Id: I5e382c3186d439b2e820c4b4c9103566792f4da3
Reviewed-on: https://gerrit.instructure.com/11897
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
In a group graded discussion assignment, when creating the child topics for
each group, the new discussion topics were touching their root topics, kicking
off a new job to refresh the subtopics. This created a race condition where
duplicate subtopics for the group could get created, in addition to a lot of
unnecessary jobs. This commit moves the touch to only happen when an entry in
a subtopic is updated, tightens up some conditions in the way soft-destroys
cascade between assignment and discussion, and adds a unique index on
context+root_topic to prevent this from happening in the future.
test plan:
- ensure that creating a group discussion assignment still creates all
necessary sub-topics for the groups
- in a course with many student groups, create a new group discussion
assignment.
- each group should only have one unique topic for this assignment
- delete a group discussion assignment, it should delete all associated topics
at the course and group levels
- also try initiating the delete from the root topic. the assignment and sub
topics should be deleted
Change-Id: I9b0fb79c2c2b3b9512802a781b8ea0f4364af541
Reviewed-on: https://gerrit.instructure.com/11712
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
closes#8769
An item can be added to multiple modules, or even the same module more
than once. This is especially useful for attachment items, but is also
useful for allowing multiple paths through a course, with say an
assignment in two different modules and the user only has to complete
one of the two modules.
test plan:
For an item in only one module, verify that the module navigation still
appears if you go straight to that item's page, without going through
the modules page.
Add an item to more than one module. If you visit that item from the
modules page, you'll see the right nav depending on which instance of
the item you clicked on. If you visit the item directly without going
through the modules page, you'll see no nav.
Lock one instance of the item by adding a prerequisite, but leave the
other unlocked. You can still see the item as a student.
Lock all instances of the item with prerequisites. The item will now be
locked and you can't see it as a student.
Add completion requirements to the item, such as a minimum score on a
quiz. Make the requirements different -- 3 points in one instance and 5
in the other, for instance. Verify that if you get 3 points on the quiz,
one item is marked as completed but the other isn't, as expected.
Rename the item. Verify that all instances of it in modules get renamed.
Change-Id: I4f1b2f6f033062ec47ac34fe5eb973a950c17b0c
Reviewed-on: https://gerrit.instructure.com/11671
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
To allow commenting on CollectionItems, we are goign to leverage
DiscussionTopics. The topic will not be created until the first comment is
made, and is accessed via the normal DiscussionTopic API (using a special
endpoint).
This also adds a new "flat" DiscussionTopic type, which doesn't support any
nesting of replies.
test plan:
* Create a collection and an item in that collection (via console or API)
* Using the API, query the discussion topic for that item via the API
* Using the APi, add a comment to that discussion topic
* Using the API, fetch the discussion again and see that your comment appears
Change-Id: Ie7cc27a7bc1d7960040632015971e59f084d7e6f
Reviewed-on: https://gerrit.instructure.com/10960
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
fixes#8107
the change made here
https://gerrit.instructure.com/#/c/9647/6/app/views/shared/_topic.html.erb
did not handle the case where topics are loaded dynamically by
jquery.pageless (scrolling down).
test plan:
- have more discussions than will fit on the page (> 10)
- scroll down until new discussions load
- edit one and check "this is a threaded discussion", then save
- reload the discussion page
- scroll down until the formerly edited discussion reloads
- click "edit" and verify the threaded checkbox is still set
Change-Id: If22933f976820ebedbe979ed06a7ff96bdac3cb4
Reviewed-on: https://gerrit.instructure.com/10285
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Brian Palmer <brianp@instructure.com>
Create a discussion topic with support for most of the options -- the
only thing missing is the ability to create an assignment discussion,
that will be added to the assignment create api.
You can also create an assignment linked to the discussion at the same
time you create the discussion. I refactored the assignment api
functionality to support this.
Added a topic delete API as well.
Also fix a bug where we weren't properly validating discussion_type
test plan: hit the api and exercise the various options, such as delayed
posting and require first posting.
Change-Id: I4afdd20313b5cea3ab7b05bf1c005c9f55debe7b
Reviewed-on: https://gerrit.instructure.com/10912
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Florence <ryanf@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>
fixes#8403
test plan:
* import an external content package with discussion topics
* make sure to find a discussion topic that has no author
* on the dashboard of a user that has a stream item about that topic
it should not show that the current user is the author
Change-Id: I681be31462a82591d60665dce967aa1548ef3a07
Reviewed-on: https://gerrit.instructure.com/10579
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
If you copied content into your course, then deleted an item
and copied it again it wouldn't be active. It is now.
Test Plan:
* Create an assignment
* Copy the course and delete the assignment in the new course
* Copy the original course into the new one again
* The assignment should be active
closes#8298
Change-Id: Ief8476d2befff999ed85a35039604d34253bfa1f
Reviewed-on: https://gerrit.instructure.com/10487
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
test plan:
* create a discussion assignment
* edit the assignment, changing its name and making it
a group assignment
* ensure, after saving the assignment, that its name is not
appended with a group name
Change-Id: I87806eba91888680c153c551a21d3829b3fe26e8
Reviewed-on: https://gerrit.instructure.com/10388
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
named_context_url wasn't always giving back absolute urls where it needed to
for atom feeds. additionally, some atom entries did not author entries which
are needed when the main feed does not have an author entry.
test-plan:
- view a modified atom feed in the browser and make sure all links are absolute
and all entries have an author.
- if the url is externally available, run it through http://feedvalidator.org/
and check that it validates.
Change-Id: I9bc2b99cd15ed5677bfd9d2cb977a29568ae4016
Reviewed-on: https://gerrit.instructure.com/9833
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
The selective imports mostly worked before, but if a
given section was completely unchecked the previous
code would import it anyway. This fixes that and makes all
the decision code in one place and easy to test.
Test Plan:
* Import a content package and only choose certain items
* Only the items you chose should be imported
closes#5528
Change-Id: Ia6c0c1f5f9a44497053733101140cc74d6239129
Reviewed-on: https://gerrit.instructure.com/9799
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@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>
consumers can use this to update the view client-side and ensure it's
always up-to-date even if the view is behind.
Change-Id: I1ff0cd80a758a113f8881ef74de78cc28e2fa16b
Reviewed-on: https://gerrit.instructure.com/9717
Reviewed-by: Ryan Florence <ryanf@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
Tested-by: Brian Palmer <brianp@instructure.com>
We changed the threaded boolean to a discussion_type string, with
currently two types: 'side_comment' and 'threaded'
test plan: get the list of topics in the api, verify threaded is
returned appropriately.
Change-Id: Id5bfb867329d93fe8be6131e2e7c401f70ced290
Reviewed-on: https://gerrit.instructure.com/9647
Reviewed-by: Zach Wily <zach@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
test plan:
* Create a graded discussion topic for groups, and set it to threaded
* Verify that the topic created in each group is threaded as well
Change-Id: I76e03d3e475fabca1bd0732637a2e16b519ec33b
Reviewed-on: https://gerrit.instructure.com/9649
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
* faster discussion loading, uses materialized view
* threaded discussion support
* navigate between unread messages
test plan:
* use every feature within discussions
Change-Id: I9e89028e5a618c36a57dae958a16b0be73c35baa
Reviewed-on: https://gerrit.instructure.com/9584
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
test plan: make an api call to create/update an entry, verify the
summary is returned
Change-Id: I3d912c47af99b81a8ccbe4f842b8de71dc72ac80
Reviewed-on: https://gerrit.instructure.com/9582
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
This is a cached-in-the-db view of the topic view json response, and
serialized arrays of participant ids and entry ids (for determining
unread entries). This is an optimization to make loading topics fast and
avoid a lot of db traffic.
test plan:
The UI for this new API is still under development, so this needs to
be tested via the API. With jobs turned off, hit the discussion view
endpoint and verify the 503 response. Then run the job to generate the
view, and verify the response json. Verify that any change to the
discussion that requires updating the view, properly updates the view.
Change-Id: I1eacace438a75a41b8b85ce6c42bfd042f27d1ea
Reviewed-on: https://gerrit.instructure.com/9443
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
This is a specialized, optimized view of the entire discussion,
including a nested view on all the entries and participants, and the
current user's unread entry list.
An upcoming commit will cache these views to the database, and generate
them asynchronously, rather than in-request.
test plan: No UI yet. GET /api/v1/courses/X/discussion_topics/Y/view ,
and verify the formatting of the response, including the nesting of
arbitrarily nested discussion entires (also only creatable via the api,
right now). verify that deleted entries are returned, but without a
user_id or summary and with a deleted flag.
Change-Id: Ib7332743f92cca40cc2a861973bf492b1f294a02
Reviewed-on: https://gerrit.instructure.com/9305
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
fixes#7790fixes#6273
we weren't properly checking the workflow state when deciding whether or not
to create a new submission for discussion assignment posts. also, we were
ensuring that a submission exists for the entry every time the topic was
updated, which is more often than necessary.
test-plan:
- create a discussion assignment
- as a user, post an entry
- as a teacher, grade the assignment
- do something that would update the topic
- make sure a new submission isn't created and that the status is speedgrader
is still graded.
Change-Id: Ic2d0fc5d809695cf856b2902bd8b478fe3bf6934
Reviewed-on: https://gerrit.instructure.com/9543
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
we just added some extra logic to make sure all the entry posters in
a discussion were in the course/group for notifications, but we also need to
include the topic poster in that filtering.
test-plan:
- create a topic (or copy a course with a topic)
- remove the topic poster from the course
- add an entry
- make sure topic poster is not notified
Change-Id: Id27fe84b420fae0911a31d7ca28cf8f8c91713d5
Reviewed-on: https://gerrit.instructure.com/9490
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cameron Matheson <cameron@instructure.com>
If a discussion topic is threaded, it'll allow sub-entries to have other
sub-entries as parents. otherwise it'll force sub-entries to always have
a root entry as a parent (restoring the behavior pre-e9edb2a86f
test plan:
Make a side comment in reply to another side comment, reload the page,
and verify it shows your comment. Do the same via the API. There's no UI
yet for marking a discussion as threaded, but you can do it from the
console and then verify that replies to replies are now nested.
Change-Id: I6bddcfa318f36bcbc6ddb03c152ff1fa8fa550b8
Reviewed-on: https://gerrit.instructure.com/9506
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
We were not scoping a query correctly, which was resulting in some unread
counts to go < 0.
test plan:
* The spec modification should adequately cover the data fixup change
Change-Id: I333d011e8656584fa261845805b87c6b4b1d53b3
Reviewed-on: https://gerrit.instructure.com/9473
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
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>
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>
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>
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>
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>
test-plan:
- in an available course with an active observer, with a communication channel
- have an admin create an announcment
- the observer should receive a notification about it
Change-Id: I94cd7eadead3bd079d820c0ea4595f203c4458bc
Reviewed-on: https://gerrit.instructure.com/9303
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Adds support for threaded discussions. The existing API has been updated
to allow posting replies to replies, and returns the whole thread of
sub-replies rather than just first-level side comments. For backwards
compatbility, the sub-replies are returned in a flattened newest-first,
consumers can look at the parent id of each entry to re-build the
nested, threaded structure.
Another commit will add a new API endpoint for retriving the threaded
structure of the conversation in a more efficient and natural format.
test plan: there's no UI for threaded discussions yet, but you can use
the API to post replies to replies, and retrieve threads and verify the
parent_id information.
Change-Id: I7d541d093fbbdb6fc8a18d079b4337515c02a8a4
Reviewed-on: https://gerrit.instructure.com/9121
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
fixes#7319fixes#7015
if a user deleted a discussion entry an then re submitted one
it would take the date of the original entry
if a teacher made a comment on a no submission and then the
student submitted the entry it would take the date of the comment
test plan
* create a discussion topic assignment
* submit two entries as student
* delete one
* the date should equal the oldest existing submission
* create a discussion topic assignment
* make a comment on a students non existent submission
* submit the assignment as the student
* the submission submitted_at should be the real submission date
Change-Id: I09b643eba575a9d84f3903ab6eefaf52b7801bb1
Reviewed-on: https://gerrit.instructure.com/9070
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
also move notifications in "new email messages" to "administrative alerts",
because that's a much better description of them
test plan:
* go to communication preferences
* the last one should be "administrative alerts"
* "Files", "Private message from student", "New email messages",
and "Context Message" should be nowhere to be found
Change-Id: I8b30d53b8137ab4b17cb436920d87331327e01f9
Reviewed-on: https://gerrit.instructure.com/8996
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
the backend for tracking read/unread state of discussion entries/topics and
unread counts for discussion topics. the strategy is to assume that an entry is
unread unless there is an an entry in the join table indicating otherwise.
interface:
- DiscussionEntry has #read_state, #read?, and #unread?. You can use these
either by passing in a user directly, or by setting the current_user
attribute on the object before calling the method (useful for json). This
should already be handled for existing controllers.
- DiscussionTopic read_state functionality as above, plus #unread_count. Same
general idea with current_user as above.
- routes are setup through the api, use PUT to mark read, DELETE to mark
unread, or rails helpers like course_discussion_topic_mark_read_path
test plan:
- click through discussion pages, and make sure they all still work (no visible
changes though, this is backend only)
- manually call some of the above methods from the console
- make sure sql for updates is reasonable
Change-Id: I655ab6a69a8cbdf1c7c99a5548b8ed0d7eadba02
Reviewed-on: https://gerrit.instructure.com/8671
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
we were already touching the immediate parent discussion topic, but for group
assignment discussions, the parent has it's own root discussion topic that also
needs to be touched for caching purposes.
test-plan:
- enable caching
- make a group discussion assignment
- post some entries in one of the sub discussions that is created
- go back to the main discussion page that lists the group discussions, and
make sure the counts in the main page match those in the right sidebar, and
are up to date
Change-Id: Ied0e07e5c61b7dbe2a148740bb7a9e46cc720b9a
Reviewed-on: https://gerrit.instructure.com/8926
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
the "Topics I've Commented On" notification wasn't working, this fixes it to
correctly send messages for a new discussion entry to all other users who have
participated in that discussion already.
test plan:
- set your topics i've commented on notification to immediately
- create a discussion topic
- have another user create a response
- you should be notified
Change-Id: I6a0d90c7b8c590b645cc31ab004da991a5851b0f
Reviewed-on: https://gerrit.instructure.com/8564
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
closes#7026
refs #5417
tests
* create a discussion with past due date
* attempt to lock discussion
* discussion should be locked
* create a discussion with future due date
* attempt to lock discussion
* discussion should not be locked
Change-Id: Idc35cdbce4a3370c9a9817ae00e92ea2ced786fd
Reviewed-on: https://gerrit.instructure.com/8448
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
provides a role override permission for viewing discussions. primarily useful
for disallowing observers from reading discussion, although by default it is
enabled.
test plan:
- create a course
- create a discussion (d1) in that course
- create a discussion assignment (d2) in that course
- log in as an observer and make sure you can see both discussions above
- log in as an admin and revoke the read_forum permission for observers
- log back in as the observer and make sure you can't see the discussions
- also check that the assignment shows the assignment page, but does not
redirect to the associated discussion.
Change-Id: I4c6441c781c24e6aadacbfc23dcc307c772ecd2c
Reviewed-on: https://gerrit.instructure.com/8069
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Cody Cutrer <cody@instructure.com>
If a user just completed a module and hasn't gone to the
modules page and clicks the next module item button that
goes into the next module (not another item within the same
module), the next module will still be locked. (If they click
before the delayed job is run)
This commit makes it so that clicking on a module item link
that goes to a locked item will cause the module progressions
to be recalculated in-request before the user is redirected
to the destination resource. This should happen fairly
infrequently since the user will only be able to access a
locked module item link under the circumstances mentioned
in the first paragraph. (locked items are disabled while
on the modules page)
Test Plan:
* Run canvas in production with caching on and Delayed Jobs not running
* Create a module with a quiz as the last item
* Make it so that the module isn't complete unless the student has scored at least 1
* Create a second module with an assignment as the first item
* Make it so that module isn't unlocked until the first module is complete
* Add a student and publish the course
* Log in as student
* Go to the quiz in the first module
* Observe that clicking the next module item button takes you to the assignment but that it is locked.
* Take the quiz and score at least 1, _do not_ go to the modules page after this is done.
* Click the next module item button and make sure the assignment is unlocked
closes#6254
Change-Id: I0719ecdc75af2d5c61bf78fbe2f07c4f21f2e24d
Reviewed-on: https://gerrit.instructure.com/7362
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Test Plan:
* Create a course and don't publish it
* Add a student to that course
* Create a discussion topic as the teacher
* Make sure there is no item for the topic in the student's stream
( make sure the student as at least one other active enrollment though because stream items don't show at all if a user has no enrollments at all)
closes#6200#5432
Change-Id: Ib993edf139d3c971197c7876a01e9f9592583704
Reviewed-on: https://gerrit.instructure.com/7221
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
if a discussion goes from ungraded to graded create any missing
submissions in the newly associated assignment for existing entries.
also, find any situations where this should have already happened and
rectify them.
test-plan:
* using old code, create two ungraded discussions
* have a student contribute to each discussion
* switch the discussion to being graded
* note there are no submissions for the student in the speedgrader
* apply migration
* note there are submissions for the student in the speedgrader
* using new code, create a third ungraded discussion
* have the student contribute to the third discussion
* switch the third discussion to being graded
* note there is a submission for the student in the speedgrader
fixes#5748
Change-Id: I30b90ba36c5d688cd9512bdb2d9d2df2cee06a08
Reviewed-on: https://gerrit.instructure.com/6822
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Discussions have an option to not allow users to see replies
until they've posted themselves. This worked correctly on the
discussion page itself, but the user would still see the
replies in their stream
This also removes that option, and the delayed posting option
from group discussion topics. These settings are useless in
that context because all users are admins and can see the
topics anyway.
Test Plan:
* create a topic in a course and check the box "Replies are not visible until after users post"
* post a reply to that topic as the teacher
* log in as a student in that course and go to your dashboard
* you should see the topic in the stream but not the response you created as a teacher
closes#4706
Change-Id: I0c50a3adb8e18ea74d209f4c9a5ac429b7faaf0e
Reviewed-on: https://gerrit.instructure.com/6684
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
wrap Assignment#group_category and Group#category accessors as
Assignment#group_category_name and Group#group_category_name accessors,
respectively, in order to make naming consistent and free up the field
"group_category" for a new association.
Change-Id: Ieb926088d96ebb8b46f70768a77b82fa1dcc8817
Reviewed-on: https://gerrit.instructure.com/5761
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Jeremy Stanley