Each differentiable object has a visible_to_students_in_course_with_da
scope which is used by the DifferentiableAssignment module to determine
what learning objects a student should see. Each differentiable also has
a visible_ids_by_user class method, which is used in modules for the
same purpose. These methods used to be shared by DiscussionTopic and
WikiPage in the Submittable module because they were very similar. Now
that they're becoming more complex with 1st-class support for
differentiation, it makes sense for these scopes to live in their own
models.
The changes to Submittable and DiscussionTopic are primarily moving
the scopes from Submittable to DiscussionTopic. The changes in
WikiPage provide support for WikiPage assignment overrides - if a page
has an assignment (because it is part of mastery paths), then read the
assignment's overrides. Otherwise, read the page's overrides.
Note: this commit does not yet guard directly-differentiated pages
and ungraded discussions.
This reverts commit df5b751592.
refs LF-1050
flag = differentiated_modules
Test plan:
- Regression test creating pages with and without "allow in mastery
paths" - ensure that all students who should have access do
- Regression test creating graded and ungraded discussions, including
ungraded section-differentiated discussions
Change-Id: I775d6fa7036189aca16b484ff55795cb001f6f81
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/346493
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jason Gillett <jason.gillett@instructure.com>
QA-Review: Jason Gillett <jason.gillett@instructure.com>
Product-Review: Jackson Howe <jackson.howe@instructure.com>
This reverts commit 32ee8e6c53.
Reason for revert: performance issues with wiki_page_student_visibilities
Change-Id: I0d0726ee973985272f8589365a15308db063b697
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/345735
Reviewed-by: Ryan Norton <rnorton@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Sarah Gerard <sarah.gerard@instructure.com>
Product-Review: Sarah Gerard <sarah.gerard@instructure.com>
Each differentiable object has a visible_to_students_in_course_with_da
scope which is used by the DifferentiableAssignment module to determine
what learning objects a student should see. Each differentiable also has
a visible_ids_by_user class method, which is used in modules for the
same purpose. These methods used to be shared by DiscussionTopic and
WikiPage in the Submittable module because they were very similar. Now
that they're becoming more complex with 1st-class support for
differentiation, it makes sense for these scopes to live in their own
models.
The changes to Submittable and DiscussionTopic are primarily moving
the scopes from Submittable to DiscussionTopic. The changes in
WikiPage provide support for WikiPage assignment overrides - if a page
has an assignment (because it is part of mastery paths), then read the
assignment's overrides. Otherwise, read the page's overrides.
This is not flagged because there are no functional changes other than
reading a page's overrides, and no WikiPage overrides exist without the
flag.
Note: this commit does not yet guard directly-differentiated pages
and ungraded discussions.
refs LF-1050
flag = none
Test plan:
- Regression test creating pages with and without "allow in mastery
paths" - ensure that all students who should have access do
- Regression test creating graded and ungraded discussions, including
ungraded section-differentiated discussions
Change-Id: I107171d0d48d4bba1f44b7953869dd3f25450664
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/345529
Reviewed-by: Sarah Gerard <sarah.gerard@instructure.com>
QA-Review: Sarah Gerard <sarah.gerard@instructure.com>
Product-Review: Jackson Howe <jackson.howe@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
closes VICE-3943
flag=discussion_checkpoints
Test Plan:
- specs pass
- Create an assignment, old quiz, new quiz and graded discussion
assigned to multiple students and ensure each can be submitted
to by the assigned students.
- Sanity check that the submissions can be viewed and graded
within Speedgrader
Change-Id: I058a4093ee8bd00d8d7186fb6ada2dd5ba37d016
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/334399
Reviewed-by: Omar Soto-Fortuño <omar.soto@instructure.com>
Product-Review: Omar Soto-Fortuño <omar.soto@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Spencer Olson <solson@instructure.com>
QA-Review: Caleb Guanzon <cguanzon@instructure.com>
[skip-stages=Flakey]
Change-Id: I6abefdfa9fed6dd4525c8786e93efa548b3710f2
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/319603
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Isaac Moore <isaac.moore@instructure.com>
QA-Review: Jacob Burroughs <jburroughs@instructure.com>
Product-Review: Jacob Burroughs <jburroughs@instructure.com>
Build-Review: Jacob Burroughs <jburroughs@instructure.com>
Migration-Review: Jacob Burroughs <jburroughs@instructure.com>
Context module progressions should only consider items that a user
is able to view when evaluating a module's completion status. Ungraded
discussions can be posted to only certain sections within a course, so
only discussions in section(s) where the student is enrolled should be
considered. This is normally the case, however, when evaluating all of
the progressions within a course, we cache the item visibilities to
prevent recalculating the same thing repeatedly (see
ContextModule#evaluate_all_progressions). This codepath is not
frequently followed, but is, for example, when a module itelf is
edited. In the caching process, we get all of the sections (and
associated discussions) visible to a list of users. This was an issue
becuase the list of users might contain users with different section
visibilities. This patchset considers section visibilities for each
user in the list individually, ensuring that module progressions
evaluate appropriately for all users.
closes LS-3245
flag = none
Test plan:
- Create a course with 2 sections
- Create a module in the course
- Create 2 discussions in the module - both ungraded; assign one to
the first section, and one to the second section
- Create a page in the module
- Edit module requirements - set "contribute to the page" on both
discussions and "view" on the page
- Enroll a student in one of the sections and publish the course
- As the student, view the page and reply to the visible discussion
- Expect the module to be marked as completed
- As the teacher, create a new (empty) module, move it to the top of
the page, then delete it
- As the student, view the modules page; expect the module to still
be marked as completed
Change-Id: I4d9a57dae0cf521a46953f4c5217df7358b08835
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/296104
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Luis Oliveira <luis.oliveira@instructure.com>
Reviewed-by: Luis Oliveira <luis.oliveira@instructure.com>
Product-Review: Jackson Howe <jackson.howe@instructure.com>
There are a number of models in a course that can either be graded or
non-graded. If a teacher switches these between graded and non-graded
it can affect course paces that are for graded assignments. This commit
republishes course paces that are affected by these types of models
switching modes.
fixes LS-3060
flag=course_paces
test plan:
- Have a course with a published course pace
- Add an ungraded discussion to a module
- Verify the course pace has not changed
- Edit the discussion and make it graded
- Verify the course pace has updated with the new item and has was
republished
- Edit the discussion and make it ungraded
- Verify the course pace no longer has the discussion and was published
- Repeat this with other objects that may be ungraded like quizzes,
wiki pages, etc. (A note on WikiPages, they will only update if Mastery
Paths is enabled)
Change-Id: I541aa5f9620ae15ff9f01bab5396b536eb88b015
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/289879
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Robin Kuss <rkuss@instructure.com>
QA-Review: Robin Kuss <rkuss@instructure.com>
Product-Review: Eric Saupe <eric.saupe@instructure.com>
fixes COMMS-1874
Test Plan
- Create a course with multiple sections
- Add students to those sections
- Create a discussion assigned to everyone
- Create a module
- Add the discussion to the module
- Edit the discussion from being visible to everyone to only specific sections
- As a user not in the section assigned to the discussion access the modules page
- Notice you cannot see the discussion in the module anymore
- Play with edge cases
Change-Id: I1e3330dc4ab297fef76adbf5e9c0ca93bab6cfd8
Reviewed-on: https://gerrit.instructure.com/180669
Reviewed-by: Landon Gilbert-Bland <lbland@instructure.com>
QA-Review: Steven Burnett <sburnett@instructure.com>
Tested-by: Jenkins
Product-Review: Steven Burnett <sburnett@instructure.com>
Fixes COMMS-1323
Test Plan:
* Have a course with >= 2 sections.
* Have a section specific discussion and a non-specific one.
* Add these to a module.
* Have a student in each of the sections.
* MAKE SURE YOUR RAILS CACHE IS CLEARED, BECAUSE WE
CACHE VISIBILITIES AND SO PREVIOUS WRONGNESS MAY
PERSIST
* TO BE SAFE RESTART YOUR RAILS SERVER TOO
* Only the student in the right section should see the
section specific discussion.
* Both should see the non-specific discussion.
Change-Id: I8d126ceb49fc4bcb0899e06699fae6ea71d75831
Reviewed-on: https://gerrit.instructure.com/159231
Tested-by: Jenkins
Reviewed-by: Landon Gilbert-Bland <lbland@instructure.com>
QA-Review: Steven Burnett <sburnett@instructure.com>
Product-Review: Venk Natarajan <vnatarajan@instructure.com>
refs CORE-1196
* avoid calling saving in an after_save callback. things just get weird
* enable logging of deprecation warnings in specs (so that you can
use the log to figure out which spec caused it)
Change-Id: I64804f7b02e4edee0650caa6346cc58bcbe69628
Reviewed-on: https://gerrit.instructure.com/144667
Tested-by: Jenkins
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
Change-Id: Id1900160375644ea33badaa9d9f9185fab6b81ac
Reviewed-on: https://gerrit.instructure.com/92726
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
Filters pages from set of assignments rendered in modal
Filters pages from displayed content tags according to differentiated
assignments behavior
refs CYOE-263
Test Plan:
1. Create a wiki page, via pages index or modules + button
2. Ensure page can be added to module and is visible to students
3. Check edit page, "mastery paths content"
4. Ensure the page is no longer visible to students in modules, until
they are assigned it via an override.
5. Open the "add item to module" modal. Ensure the page does not appear
in the assignments section, only under pages.
Change-Id: I822d53dc562476ef422f4a3ee6004e0d1e132246
Reviewed-on: https://gerrit.instructure.com/87418
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Tested-by: Jenkins
QA-Review: Jahnavi Yetukuri <jyetukuri@instructure.com>
Product-Review: Christian Prescott <cprescott@instructure.com>
refs #CNVS-26056
Change-Id: Ife03a54b6b0e1fa6eda737f2002f57caec6dcf1e
Reviewed-on: https://gerrit.instructure.com/77702
Tested-by: Jenkins
Reviewed-by: Christian Prescott <cprescott@instructure.com>
Product-Review: James Williams <jamesw@instructure.com>
QA-Review: James Williams <jamesw@instructure.com>
refs CYOE-67
Test Plan
0. `rake db:migrate` and compile assets. Enable the conditional release
feature flag in course settings.
1. Create a published WikiPage, assignment-free. Ensure it is visible
to errybody.
2. With the API, create an assignment with submission type 'wiki_page'.
A new page will be created for the assignment.
```sh
curl "http://canvas.dev:3000/api/v1/courses/1/assignments" \
-H "Content-Type: application/json" -H "Authorization: Bearer <token>" \
-X POST -d '{"assignment": {"name": "Page Asg", "published":true, \
"submission_types":["wiki_page"]}}'
```
3. Ensure the assignment is assigned to "Everyone" and the page is
visible to all.
4. Assign the assignment to a specific student or section. Ensure the
page is visible only to the assigned set.
```sh
curl "http://canvas.dev:3000/api/v1/courses/1/assignments/13" \
-H "Content-Type: application/json" -H "Authorization: Bearer <token>" \
-X PUT -d '{"assignment": {"only_visible_to_overrides": true }}'
curl "http://canvas.dev:3000/api/v1/courses/1/assignments/13/overrides" \
-H "Content-Type: application/json" -H "Authorization: Bearer <token>" \
-X POST -d '{"assignment_override": {"student_ids":[126]}}'
```
5. Ensure the DA behavior also applies to WikiPage#show and update and edit.
6. Ensure API behavior matches docs for Assignment and Page endpoints.
7. Ensure no regressions in non-page assignments, with and without CR
feature flag. Ensure no regressions in discussion topics and
announcements, including assigned discussions.
Change-Id: Ie53c6ffa4e4533cedd54f10aee3ba0b8a27aa4d5
Reviewed-on: https://gerrit.instructure.com/75139
Reviewed-by: Matt Berns <mberns@instructure.com>
Tested-by: Jenkins
QA-Review: Michael Hargiss <mhargiss@instructure.com>
Product-Review: Christian Prescott <cprescott@instructure.com>
Jackson Howe