This implements the part of the 1Edtech Platform Notification Service
specification, namely, platforms that support PNS should advertise the
supported notification types in LTI launches.
flag=platform_notification_service
closes INTEROP-8879
Test plan:
- Have an LTI tool whose developer key includes the scope
https://purl.imsglobal.org/spec/lti/scope/noticehandlers
- turn the platform_notification_service FF on (`canvas-ffs flip` to get
flag from checked out HEAD)
- launch the tool
- check that the
https://purl.imsglobal.org/spec/lti/claim/platformnotificationservice
claim is present in the JWT, and matches as described in the platform
notification spec
- flip the FF off
- launch the tool check that the claim is not present
- flip the FF on and remove the scope from the key
- launch the tool check that the claim is not present
Change-Id: Ibd2e2d19263e86557fb8269188143892c2c2211e
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/360075
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
Reviewed-by: Paul Gray <paul.gray@instructure.com>
QA-Review: Paul Gray <paul.gray@instructure.com>
When launching form student_context_card placement,
there are two basically two contexts, course and student.
The standard context claim is filled with the course but tools
want to know about the student as well.
With this ticket we introduce a new custom claim
'https://www.instructure.com/student_context' that will be filled with
{ id: <student.lti_id> } when launching from student_context_card.
closes INTEROP-8186
flag=none
test plan:
- Launch a tool from student_context_card placement
- Check that the https://www.instructure.com/student_context claim
is present in the idtoken and filled with the student's lti_id
Change-Id: Ie1b1b9d80ae415c8e7356f9ac313ec0f5bcb1ea5
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/354130
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Bence Árpási <bence.arpasi@instructure.com>
QA-Review: Bence Árpási <bence.arpasi@instructure.com>
Product-Review: David Varga <d.varga@instructure.com>
why: we used to pass the assignment title as the resource link claims
title, and customers are expecting this behavior, but we changed
this at some point to prefer the the resource link title.
fixes: INTEROP-8629
flag=none
test plan:
note:
it would be easiest if this was QA'd after 8700 has been merged
(including the commit to the LTI 1.3 Test Tool - or cherry-pick from
https://gerrit.instructure.com/c/lti-1.3-test-tool/+/351606) and using
the LTI 1.3 Test Tool you added
{"https://canvas.instructure.com/lti/preserveExistingAssignmentName": true}
to the new 'Extra arbitrary content item data' field in the tool
configuration to ensure that the assignment title is different and not
overwritten by the tool title or the lineItem.label
- create an assignment with a 1.3 tool that has a title different from
the assignment title and save
- if using the LTI 1.3 Test Tool you should see in the decoded jwt on
the assignment view that the resource link claims title is the
assignment title.
Change-Id: Iac0a74a5c47fdddbaa9a5ab1071c0b846984f0c4
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/351965
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Tucker Mcknight <tmcknight@instructure.com>
QA-Review: Tucker Mcknight <tmcknight@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
why: a previous commit erroneously included the tool nonce only when the
associated tool 'consumer_key' was present. This prevents an LTI
tool from launching correctly (or at all)
refs INTEROP-8624
test plan:
- all specs pass
- successfully launch the LTI 1.3 Test Tool from an assignment
Change-Id: I96f8f0d23c73b97eb8052a656c2f3626096fc6c8
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/352421
Reviewed-by: Bence Árpási <bence.arpasi@instructure.com>
QA-Review: Bence Árpási <bence.arpasi@instructure.com>
Product-Review: Bence Árpási <bence.arpasi@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
why: oauth_consumer_key_sign is being calculated using
the wrong nonce (it is actually being overwritten)
so the timing of what is gathered and when needs
to be adjusted to ensure the correct nonce is used
fixes INTEROP-8624
flag=none
[fsc-timeout=60]
test plan:
- Go to Admin -> pick your account -> settings -> Apps -> View App
Configurations -> +App -> Fill out the LTI 1.1 information, making
note of the Launch Url
- Create a course.
- Create an assignment. Use submission type "External Tool" finding and
selecting the tool above.
- Launch the assignment, showing the LTI 1.1 tool does have the right
oauth consumer key/secret
- Go back to Admin -> pick your account -> settings -> developer
tools -> +Developer Key -> +LTI key -> Fill out the LTI 1.3
information. Make sure to put the LTI 1.1 Launch Url into the Target
Link URI field.
- Relaunch the assignment, now in LTI 1.3. This will provide the
oauth_consumer_key_sign
Change-Id: I3b0daf816c61d7bb9cb56d85e94301bae455c520
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/350764
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
and apply new cop 99% Style/SuperArguments
and a couple Layout/EmptyComment and Style/ArgumentsForwarding that
are found by fixes in those cops
Change-Id: Icc0af9c8065f035bca43868b564f73e8776052f2
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/348626
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jake Oeding <jake.oeding@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
Build-Review: Cody Cutrer <cody@instructure.com>
why:
- In 29304fe219, we passed the resource
link title through to the assignment and thus the update_line_items
method.
- That method also left some resource link's behind in the database that
have an empty title. We don't want to send an empty title.
refs INTEROP-8606
test-plan:
- Replicate production first by doing the following:
- Create an assignment with a resource link by using the LTI 1.3 test
tool. You won't be able to set
the title to an empty string through the UI.
- Run `Lti::ResourceLink.last.update!(title: "")` to replicate the bad
data in production.
- Launch the assignment again. The resource link title should be an
empty string.
- Check this commit out.
- Launch the assignment again. The resource link title should now match
the assignment title.
Change-Id: I7796f5988aa898c41be569a966e154c2da00ae58
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/347831
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Ryan Hawkins <ryan.hawkins@instructure.com>
why:
- We currently send the old 1.1 resource_link_id for assignment launches
but we don't currently do it for module items. This makes it
effectively impossible to migrate 1.1 module items to a new 1.3 tool.
- We're going to need a way to migrate a few other resources, so having
a nice abstraction over the migration should make things smoother in
future commits.
- Note: This commit does NOT migrate content has previously been
migrated by installing a 1.3 tool in the same context as a 1.1 tool.
It migrates existing content in a background job when a new 1.3 tool
is installed in the same context as a matching 1.1 tool. We plan to
address this in future commits.
closes INTEROP-8262
flag=none
test-plan:
- Install Xander's handy-dandy LTI 1.1 test tool in either a course or
account.
- Create a module item with that test tool.
- Launch it and take note of it's resource_link_id. It should be a hash,
not a UUID.
- Install the LTI 1.3 version of Xander's test tool that lives on the
same domain (likely at localhost:2918/1_3) in the same context as the
1.1 tool you installed above.
- Launch the module item again. You should launch into the 1.3 tool.
Look under the "https://purl.imsglobal.org/spec/lti/claim/lti1p1"
claim for the resource_link_id. This should be the same
resource_link_id you saw earlier.
- That's it! A lot of the work on this commit went into creating a good
framework for migrating content that does not currently migrate so we
can easily fix that in later commits.
Change-Id: I8270e18d99228cc1d666fe6a7db3cec261a37d1c
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/334295
Migration-Review: Cody Cutrer <cody@instructure.com>
Reviewed-by: Paul Gray <paul.gray@instructure.com>
QA-Review: Paul Gray <paul.gray@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
refs INTEROP-8266
flag=none
test plan:
1. Create an LTI Deep Link on a page via RCE (You can use the LTI Testing Tool) Make sure the title is filled
2. Save the page
3. Click on the external tool link
4. Validate the title tag attribute is the same in the LtiResourceLinkRequest claim
Change-Id: Ifbd5718f2f998e305d0de958cbe67f2b386bb043
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/334336
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
Migration-Review: Jacob Burroughs <jburroughs@instructure.com>
why:
* LTI 1.1 tools launching from this placement receive the
`ext_lti_student_id` launch parameter that corresponds to
the student from which the tool was launched
* this provides parity for LTI 1.3 tools to receive a similar parameter,
`https://www.instructure.com/lti_student_id`
closes INTEROP-8058
flag=none
test plan:
* install a 1.3 tool with the student_context_card placement enabled
* Course -> People -> click on a Student
* a card will slide out from the right side, and will have a button
to launch the 1.3 tool
* launch the tool
* scroll to the bottom of the decoded id_token
* the lti_student_id custom claim should be present and
match the id of the student you clicked on
* bonus:
* change the id in the URL to a non-student - it should fail
* change the id to a non-number like SQL injection - it should fail
* remove the `&student_id=1` query param entirely - the launch should
succeed, but not include the lti_student_id claim
* extra bonus:
* test this with a 1.1 tool to confirm it's still working as intended
Change-Id: Ie3aeebb549c14b978fe84e28748275478685fba4
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/335539
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Paul Gray <paul.gray@instructure.com>
QA-Review: Paul Gray <paul.gray@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
why:
* to avoid inconsistencies in the way that tools are found
for content tags and assignments
refs INTEROP-8182
flag=none
[pin-commit-instructure_misc_plugin=0e59ae0b57c3d10345560797d9ff838a734ecbdf]
ignoring FSC since it's trying to run both the line items and scores
controller specs, and those are pretty slow. it was still timing out
even after 60 min. +1ed by devx
[ignore-stage-results=Flakey Spec Catcher]
test plan:
* launching a tool from any/all of these places still works:
* an assignment
* a module item
* an assignment (with A2 on as a student)
* sessionless launch for a module item
* specs
Change-Id: I6eccdd56d3ed97a9089fe979a0ba72ffa5d0de55
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/325732
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Tucker Mcknight <tmcknight@instructure.com>
QA-Review: Tucker Mcknight <tmcknight@instructure.com>
Product-Review: Xander Moffatt <xmoffatt@instructure.com>
This reverts commit 0e703b84c0.
why:
- Previously, work was done to add the oauth_consumer_key and
oauth_consumer_key_sign to LTI 1.3 launches that are associated with a
1.1 tool.
- This work is important, as it improves the migration experience for
tools.
- However, the previous attempt at this did not account for tools within
production Canvas having invalid URLs/domains. While we do validate
URLs now, we didn't always, so there are some bad tools still hanging
out in the wild.
- Additionally, while the previous commit did add a feature flag, it
didn't add it properly, meaning that even though the flag was off, it
was still looking up the association, it just wasn't adding the
property to the 1.3 Message. This commit does it properly now.
fixes INTEROP-8124
flag=include_oauth_consumer_key_in_lti_launch
test-plan:
- The first half of this test plan is taken verbatim from the previous
commit:
------ Start Old Test Plan
- Clone Xander's handy dandy Remix 1.1/1.3 test tool and run it locally.
https://github.com/xandroxygen/lti_1p1_test_tool
- Run the tool and then install it locally by following the directions
for both 1.1 and 1.3.
- Launch the 1.3 tool and make sure that under the 1.1 claims section,
there is an oauth_consumer_key with value key and an
oauth_consumer_key_sign section. You don't have to check the
signature, as the algorithm for it is unit tested using values from
IMS's examples from the spec itself.
- Now delete the 1.1 tool and launch the 1.3 tool again. You should
still see the oauth_consumer_key info.
------ End Old Test Plan
- Now, to test that things won't broke when there are malformed tools,
do the following:
- Create a new course.
- Manually create a new tool in the rails console in this course with
malformed data. We have to bypass some rails validations to mock prod.
```ruby
tool = Course.last.context_external_tools.new(url: "http://url path>};/invalidurl}",
domain: "url path>};"
settings: {
"text"=>"LTI 1.1 Tool with Garbage Data",
"visibility"=>"public",
"custom_fields"=>{"user_id"=>"$Canvas.user.id"},
"course_navigation"=>
{"enabled"=>true,
"url"=>"http://url path>};/invalidurl}/launch?placement=course_navigation",
"text"=>"LTI 1.1 Garbage Data",
"selection_width"=>500,
"selection_height"=>500,
"message_type"=>"basic_lti_request",
"visibility"=>"none"},
"vendor_extensions"=>[]
})
tool.save(validate: false)
```
- Launch the LTI 1.3 test tool from this new course. You should NOT see
an oauth_consumer_key & oauth_consumer_key_sign in the LTI 1.1 claims.
More importantly, the launch should succeed without a 500.
- Delete the manually created tool and launch the 1.3 tool again. All
should be the same as above.
Change-Id: Icea1ed5fd0a316fac51ba87591ea79b2002d5a9d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/322172
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Ryan Hawkins <ryan.hawkins@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
In Beta and Test versions of Canvas, we always want to send
the xxx.beta.instructure.com URL in LTI calls (NRPS, AGS, etc)
instead of the preferred domain.
fixes INTEROP-8102
flag=consistent_ags_ids_based_on_account_principal_domain
test plan:
1. temporarily modify local code for ApplicationController.test_cluster_name
to return a beta url
2. Launch an LTI 1.3 tool in an assignment context (e.g. create an LTI
1.3 assignment) and check both the "lineitems" and "lineitem" fields
3. Also check the context_memberships_url (NRPS) from the launch
4. Get an LTI advantage token for your LTI 1.3 tool
(/api/lti/advantage_token?tool_id=123) and GET the
/api/lti/courses/2/line_items endpoint, and check the "id" fields
of the returned results.
5. Post a score to the /courses/123/line_items/456 (etc.) endpoint --
see the example request from the docs at
https://canvas.instructure.com/doc/api/score.html --
and check the the "progress" URL (under content_items) and the
resultUrl returned.
6. Get the /api/lti/courses/2/line_items/1/results and check the URLs
in the "id" field and the "scoreOf" field.
7. Get the /api/lti/courses/2/names_and_roles endpoint and check the
URL in the "id" field.
Change-Id: I21ad34097442283f74dd70b28b1a46fbc8fbcaf8
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/320726
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Tucker Mcknight <tmcknight@instructure.com>
QA-Review: Tucker Mcknight <tmcknight@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
This reverts commit b4eafd838e.
Reason for revert: This commit is causing issues within Canvas and Sentry is down, so we can't see just how bad they are. They seemed pretty bad when we could see them though.
Change-Id: I672876dd6dd6fe22d5b5c1fb010b1050db3c5a7a
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/320360
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Tucker Mcknight <tmcknight@instructure.com>
QA-Review: Tucker Mcknight <tmcknight@instructure.com>
Product-Review: Ryan Hawkins <ryan.hawkins@instructure.com>
why:
- the spec says send it
- we are not doing that now
- instead, do it right
- (Also, it will help tools migrate from 1.1 to 1.3, which is currently
a bit of a pain point)
test-plan:
- Clone Xander's handy dandy Remix 1.1/1.3 test tool and run it locally.
https://github.com/xandroxygen/lti_1p1_test_tool
- Run the tool and then install it locally by following the directions
for both 1.1 and 1.3.
- Launch the 1.3 tool and make sure that under the 1.1 claims section,
there is an oauth_consumer_key with value key and an
oauth_consumer_key_sign section. You don't have to check the
signature, as the algorithm for it is unit tested using values from
IMS's examples from the spec itself.
- Now delete the 1.1 tool and launch the 1.3 tool again. You should
still see the oauth_consumer_key info.
closes INTEROP-8050
flag=include_oauth_consumer_key_in_lti_launch
Change-Id: I31b5082e76ec3408b4706f4abb4e3d9ab6890b45
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/319394
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Alexis Nast <alexis.nast@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>
The collaboration edit link already passes in a content_item_id to the
`retrieve` endpoint. In ExtgernalToolsController#retrieve, this is used
in the LTI 1.1 path to make a content_item_id in the data for the
content item success URL, but it is not used in the LTI 1.3 path. This
commit:
1. passes thru the content_item_id into the `data` param (a JWT) for the
deep linking return URL
2. In the deep-linking response page, includes content_item_id as
"service_id" (following LTI 1.1 nomenclature) in the postMessage, and
3. in the collaborations code, correctly extracts the content_item_id
from the the postMessage sent by the deep_linking_response page.
closes INTEROP-7986
flag=none
Test plan:
- Install the LTI 1.3 test tool
- From the course collaborations page, create a new collaboration using
the tool
- Update the collaboration to have an updateUrl, e.g.:
c=ExternalToolCollaboration.where(workflow_state: :active).last
c.data['updateUrl'] = "http://web.lti-13-test-tool.docker/launch"
c.save!
- Refresh the collaborations page and click the "edit" button to launch
the tool
- In the tool, enter a new value in the title field, and send the link
back to Canvas. The collaboration should be modified with the new
title -- no new collaboration should be created
Change-Id: Iac13b5a2a5b3034a26cfb8541d34749c89704b91
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/317193
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
This will provide consistency in the IDs for Accounts which can be
accessed on multiple domains. No matter what domain is used to access
Canvas, the AGS ids will always use the domain which is considered the
primary for the account.
closes INTEROP-7813
flag=consistent_ags_ids_based_on_account_principal_domain
Test plan:
- Make sure you have a Canvas account which you can access from multiple
domains. To do this you'll likely need to have MRA setup, and then add
an additional domain in Account Settings -> Canvas Cloud Information,
and setup an additional domain with your proxy
(traefik/dinghy/dory/whatever) as you did when setting up MRA
- Check the following both with the new feature flag
(consistent_ags_ids_based_on_account_principal_domain) off and on.
Hit Canvas on a domain which is the not the account's primary domain.
For each, check that, for the ID/URL in question:
- With the flag off, it should include the domain you're accessing
Canvas on
- With the flag on, it should include the primary domain
1. Launch an LTI 1.3 tool in an assignment context (e.g. create an LTI
1.3 assignment) and check both the "lineitems" and "lineitem"
fields
2. Also check the context_memberships_url (NRPS) from the launch
3. Get an LTI advantage token for your LTI 1.3 tool
(/api/lti/advantage_token?tool_id=123) and GET the
/api/lti/courses/2/line_items endpoint, and check the "id" fields
of the returned results.
4. Post a score to the /courses/123/line_items/456 (etc.) endpoint --
see the example requst from the docs at
https://canvas.instructure.com/doc/api/score.html --
and check the the "progress" URL (under content_items) and the
resultUrl returned.
5. Get the /api/lti/courses/2/line_items/1/results and check the URLs
in the "id" field and the "scoreOf" field.
6. Get the /api/lti/courses/2/names_and_roles endpoint and check the
URL in the "id" field.
Change-Id: I4250323445d00324cf7470b2496683b492dfce27
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/309389
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
closes INTEROP-7743
flag=NONE
refs INTEROP-7703
why: This is a small part of adding support for launching LTI tools from
Canvas in New Quizzes. parent_frame_context will facilitate Canvas
allowing window.postMessage messages from internal tools framed within
Canvas itself.
test plan: Make a call to the resource_selection endpoint, including a
parent_frame_context parameter and make sure that for 1.1 content item
launches, the content_item_return_url includes this parameter, and for
1.3 launches, the deep_link_return_url includes this parameter.
Change-Id: I97de211e6b98338e8880482b260cb3e53b3e4046
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/305661
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Product-Review: Paul Gray <paul.gray@instructure.com>
why:
* to prevent tampering with current deep_link_return_url parameters
like placement and assigment id
* to ensure that content items are created only once for a given
deep link launch
closes INTEROP-7439
flag=none
test plan:
* perform a deep link launch and look at the launch data, specifically
the deep_link_return_url in the deep_linking claim
* that url should now contain `?data=<a JWT>` instead of raw
query parameters
* copying that JWT and decoding it using jwt.io should show those
same parameters
* confirm that existing deep linking flows have no change in behavior:
* creating a module item for an existing module still adds the content
item(s) to the module
* creating a module item from the module_index_menu_modal placement (top
right 3-dot menu on modules page) adds the content item(s) to a new
module
* returning a content item from the assignment_selection placement while
creating a new assignment reloads the page and creates an assignment
with the given data
* (with the lti_assignment_page_line_items flag on) returning a content
item from the assignment_selection placement while editing an existing
assigment reloads the page and updates the assigment with the given data
Change-Id: Ic16d87f82a704fabfbac3efa3dd402e209c30333
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/301765
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
Reviewed-by: Tucker Mcknight <tmcknight@instructure.com>
QA-Review: Tucker Mcknight <tmcknight@instructure.com>
fixes INTEROP-6491
flag=none
test plan:
* created a module item assoc with an lti 1.3 tool
* launch the tool from the module item
* resouce_link claim should contain the title of the module item
* launch the tool from the course navigation placement
* resouce_link claim should contain the name of the course
* test with newer resouce_link that doesn't have a url
Change-Id: I1ba42d5a9d4ff282f6c12bd84021b3bb4ba4075b
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/294918
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
why:
* in rare cases (an Assignment exists in the account that does not have
an `lti_context_id`), the deep link return url that is passed in the LTI
launch will mistakenly point to that assignment, instead of the
correct context
closes INTEROP-7506
flag=none
test plan:
* create an assignment however you would like
* in a rails console, remove its lti_context_id:
`a.update_attribute(:lti_context_id, nil)`
* without this commit checked out:
* perform a deep linking launch from the account announcements page
by creating a new announcement and launching the 1.3 test tool from
the RCE that opens
* note the deep_link_return_url in the LTI launch JWT - it should point
to `.../courses/:account_id/assignments/:id...`, which is incorrect
* check out this commit
* repeat the same deep linking launch
* the deep_link_return_url should point to `.../accounts/:id...`, which
is the correct context
Change-Id: I90946a1a505e18d7349b953ff9c108959240406b
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/293692
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Product-Review: Xander Moffatt <xmoffatt@instructure.com>
why:
the dimensions in the launch_presentation claim are pretty much
all 500x500, despite any iframe size changes
refs INTEROP-7365
flag=none
--------------------------------------------------
Test plan
--------------------------------------------------
* launch the LTI 1.3 Test Tool from any placement
* find the "Decoded JWT"
* find the launch_presentation claim:
"https://purl.imsglobal.org/spec/lti/claim/launch_presentation"
* check the height and width values. They can assume the values
following the order of preference bellow:
1 - ContentTag.link_settings hash. Eg:
{"selection_width"=>"123", "selection_height"=>"456"}
2 - ContextExternalTool.placement["selection_width"] and
ContextExternalTool.placement["selection_height"]
3 - ContextExternalTool.settings["selection_width"] and
ContextExternalTool.settings["selection_height"]
Change-Id: Ia2e9903bb46a3eacfcd48c30f551032113f05651
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/290482
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
fixes INTEROP-7418
flag=lti_deep_linking_module_index_menu_modal
flag=lti_deep_linking_line_items
Test plan
- With an existing assignment in Canvas
change the submission type to external tool
and choose a tool that you can create line
items with
- Create a line item and finish the deep
link request
- Ensure that the page doesn't go to a completely
new assignment
- Do the same process with a new assignment
and ensure it does still create a new assignment
Change-Id: I2ac2c38e2f5ad2785e4b2e92a7e70ff3d5d11539
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/290194
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
why:
* to be consistent in allowing deep linking content to be added from the
3-dot menu at the top of the modules page and for each module
closes INTEROP-7294
flag=lti_multiple_assignment_deep_linking,lti_deep_linking_line_items
test plan:
* install a 1.3 test tool that has the module_menu_modal placement
configured, and with a message_type of LtiDeepLinkingRequest
* make sure these feature flags are enabled:
* lti_multiple_assignment_deep_linking
* lti_deep_linking_line_items
* lti_deep_linking_module_index_menu_modal
* from the modules page, click on the 3-dot menu in an existing module
* you should be able to launch the tool from there, which wasn't
possible before
* launch and return these content items. all scenarios should reload the
page and add things to the module:
* 1 content item: should add 1 item to the module
* many content items: should add all items to the module
* 1 content item with line item: should add 1 assignment to the module
* many content items with line items: should add all items to the
module as assignments
* many mixed content items (some with line items and some without):
should correctly add all items to the module as either lti links or
assignments
Change-Id: Id0c4d7933213b8a8acfab0a4c988807cddcedfa7
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/287770
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Tucker Mcknight <tmcknight@instructure.com>
QA-Review: Tucker Mcknight <tmcknight@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
why:
* currently only assignment-associated LTI resource links send their
unique resource_link_id in the LTI launch, while other LTI resource
links (like module items, RCE content etc) use the context resource
link id
* this is in violation of the LTI spec and has been for a long time
closes INTEROP-6708
flag=none
test plan:
* create some LTI resource links in different places in a course
* an LTI-type assignment
* an LTI launch module item
* an LTI resource link in an RCE instance
* each of these should have an `Lti::ResourceLink` model associated with
them, with a resource_link_uuid
* launching each of these links should include that uuid in the
resource_link_id claim of the LTI launch message
Change-Id: I49e1de494dd16a9c12a3ab27900291014675e1a6
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/287450
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Product-Review: Alexis Nast <alexis.nast@instructure.com>
closes INTEROP-7279
* Currently, when editing a developer key, if something is set in a
placement-specific target_link_uri, but then it is removed, the
target_link_uri gets set to "". This can happen even if
target_link_uri is initially not present, but you put some text in
there and remove it. When the placement-specific target_link_uri is
"", the placement will not launch.
* Also, if you give a number for a placement-specific selection
width/height, and then get rid of it, the selection_width/height is
set to "" in the React state, and you'll get an error when trying to
save the dev key.
* This commit fixes the React components so, if the text edit boxes are
empty, the placement object won't have the keys at all, instead of
having an empty string.
* For keys which already have a empty string ("") placement-specific
target-link URI, this fixes the launch be treating that as nil.
Test plan:
- Before checking out this commit:
- ensure that you have an LTI 1.3 tool installed with a placement with
a placement-specific target_link_uri. The test tool by default does
this.
- Make sure you have jobs running (these copy the dev key changes to
ContextExternalTools)
- Edit the LTI Dev Key and empty out the edit box for the
target_link_uri for one of the placements. Try launching the tool
from the placement. it should crash.
- Check out this commit
- Try launching the tool from the placement. It should not crash: it
should launch using the URL for the tool.
- Edit the dev key. Fill in something in the empty placement-specific
target_link_uri and delete it. Save the key.
Then, look at the JSON for the dev key (in a console, or just edit it
again and look at the JSON in the UI). Instead of the blank string it
should not have a "target_link_uri" set.
- Edit the tool again. Put in a value for selection height and selection
width for one of the placements, then delete one of these two values
before saving. It should save successfully. After saving, look back at
the JSON. The selection height or width value you kept should be set,
whereas the one you deleted should not be in the JSON hash at all.
Change-Id: Ib1a5cde7ad398310e5cc8b705cf90e539a9d92c7
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/285325
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Evan Battaglia <ebattaglia@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
why:
* previously only resource link requests had the AGS claim attached,
but this does not conform to the LTI 1.3 spec
* include the AGS claim in deep linking request messages as well
* the single lineitem property of the AGS claim is only included
when the launch is associated with a lineitem (eg, for an assignment),
and that is delegated to the ResourceLinkRequest since the
DeepLinkingRequest is never told about an assignment
closes INTEROP-7261
flag=none
test plan
* with a 1.3 tool installed in an account
* launch the tool from the account_navigation placement
* search the decoded JWT for `lti-ags/claim/endpoint`
* it should not be there
* launch the tool from the course_navigation placement
* the AGS claim should be there, and include scope and lineitems
* launch the tool from the assignment_selection placement, ie
when creating a new assignment
* the AGS claim should be there, and include scope and lineitems
* this should be a LtiDeepLinkingRequest launch type
* save and publish the assignment, and then view it
* this should launch the tool
* the AGS claim should be there, and include scope, lineitems, and
lineitem
Change-Id: Id41fd3a1137a7f601491f489fa18d21d803adba1
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/284487
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Product-Review: Karl Lloyd <karl@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Added in the "resource_link_id" migration parameter for resource link
launches. This parameter is included when the LTI 1.3 resource_link_uuid
is different than the LTI 1.1 lti_context_id. It helps tools migrating
from 1.1 to 1.3 map old ids in their databases to the new ids.
flag=none
closes INTEROP-6796
test-plan:
* Install an LTI 1.1 tool and create an assignment that launches that
tool, then launch it. Note the resource_link_uuid that is provided. It
should look like a hash, not a UUID. Xander likely knows of a good LTI
1.1 tool that would work for testing, or a way to make the 1.3 tool
work for this.
* Install the LTI 1.3 Test Tool in at least the assignment submission
and course menu placement. I'm lazy, so I have it installed everywhere :)
* Migrate your previous LTI 1.1 assignment to use the LTI 1.3 Test Tool.
You can do this by updating the assignment's external_tool_tag.url to
the launch url of the LTI 1.3 Test Tool which is typically
http://lti13testtool.docker/launch.
* Launch the assignment. You should see under the
"https://purl.imsglobal.org/spec/lti/claim/lti1p1" a value for
resource_link_id. This should match the hash you saw earlier when you
launched the 1.1 tool.
* Now for some monkey-patching :). Place a byebug breakpoint at the
beginning of the include_lti1p1_claims? method in
lib/lti/messages/resource_link_request.rb. Then, launch the 1.3 tool
from the assignment. When you hit the breakpoint, monkey-patch
Assignment with the following code:
class Assignment < ActiveRecord::Base
def lti_resource_link_id
primary_resource_link.resource_link_uuid
end
end
This makes sure that the code thinks that the LTI 1.1 and 1.3
resource_link_ids are the same, even though that can basically
never happen in real life. This way though, we know that only
include the claim when we absolutely need to.
Continue the launch after monkey-patching and you should see there is
no resource_link_id claim in the lti1p1 claims section.
* Launch the tool from the course menu and make sure that you *don't*
see a key-value pair for resource_link_id. It should only be included
on assignment launches.
Change-Id: I85bbd977f4aa0809b2b031492bf58c0c86fea4bc
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/275459
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Ryan Hawkins <ryan.hawkins@instructure.com>
why:
* module_index_menu is behind a feature flag and opens in a tray,
which is not ideal for creating module items and assignments
via deep linking
* replace it with the new module_index_menu_modal placement
closes INTEROP-7075
flag=lti_deep_linking_module_index_menu_modal
test plan:
* with a tool that has this placement configured,
* change the message type in the placement config to
`LtiDeepLinkingRequest`
* launch the tool again - it should still not be a deep linking launch
* enable the feature flag
* launch the tool again - it should be a deep linking launch
* any content items returned from here should become
module items in a newly created module
* returning content items should reload the modules page
Change-Id: I906578ddbea347e1a23fcca8dd24c672f0abbb7b
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/277620
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Alexandre Trindade <alexandre.trindade@instructure.com>
Product-Review: Karl Lloyd <karl@instructure.com>
Reviewed-by: Mysti Lilla <mysti@instructure.com>
closes INTEROP-7069
flag=lti_deep_linking_line_items,lti_deep_linking_module_index_menu
why:
* a new addition to the IMS LTI spec is to accept line items as part of
a deep link response, and the Canvas way of handling line items is to
create an assignment
test plan:
* with a 1.3 test tool set up, launch the tool from either the modules
or assignment index menu (3-dot button in top right of page)
* fill in the line item box in the test tool with:
```
{"scoreMaximum":10,"label":"line item test","resourceId":"id","tag":"test"}
```
* fill in the available box in the test tool with:
```
{"startDateTime":"2021-10-18T14:32:07Z","endDateTime":"2021-11-18T14:32:07Z"}
```
* fill in the submission box in the test tool with:
```
{"endDateTime":"2021-11-18T14:32:07Z"}
```
* send the content items back to Canvas
* the page should reload
* you should have one new assignment, titled "line item test"
* it should be worth 10 points, and launch the test tool when opened
* it should unlock on Oct 18 and lock on Nov 18, and be due on Nov 18
* launch the tool from the index menu again and this time fill in the
line item box with:
```
{"label":"this should do nothing"}
```
* submit the content items back to Canvas
* the page should reload
* you should not have any new assignments, since scoreMaximum is a
required field and was not present
Change-Id: I5a7cd02f20da23f162efc7705ac1d98cf1bffe8b
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/272069
Product-Review: Xander Moffatt <xmoffatt@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Alexandre Trindade <alexandre.trindade@instructure.com>
QA-Review: Alexandre Trindade <alexandre.trindade@instructure.com>
closes FOO-2467
flag=none
[skip-stages=Flakey]
Since canvas and it's plugins
share an autoloader, they need
to make consistent choices about how to inflect
the same acronyms
TEST PLAN:
1) tests pass
Change-Id: Icb133f33ed3e719b616e42e497bac1dc65bd9370
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/275496
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
QA-Review: Ethan Vizitei <evizitei@instructure.com>
Product-Review: Ethan Vizitei <evizitei@instructure.com>
closes INTEROP-6833
flag=lti_deep_linking_module_index_menu
why:
* this is an easy unit of work that's separate from the requirements
for adding line item and multiple assignment support
* create a new module and add content items to that module
* also extract the deep linking listener for use in contexts other than
collaborations
test plan:
* install the 1.3 test tool and include the module_index_menu placement
* launch the tool from that placement by clicking the 3 dots button on
the top row of the Modules page
* pass back 1 or many content items with any overrides you wish
* the page should reload, and a new module should be created that
contains the content items you passed back
* each of them is properly configured and launches correctly
Change-Id: I2a2bb47db261a9c1bd32e9799f73b81d2102d374
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/272902
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
QA-Review: Tucker Mcknight <tmcknight@instructure.com>
Product-Review: Xander Moffatt <xmoffatt@instructure.com>
fixes INTEROP-6832
flag=lti_multiple_assignment_deep_linking
test plan:
- Install a LTI tool with the "Course Assignments Menu"
placement and the LtiDeepLinkingRequest message type
- Activate the "LTI Multiple Assignment Deep Linking"
feature flag
- Access a course
- Click on Assignments
- Click on the dropdown menu next to the "+ Assignment"
button
- Check the LTI tool as a menu item on the list
Change-Id: I3dca155901bb9d9f7e43b04bb5e63c5177a95204
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/270921
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Alexandre Trindade <alexandre.trindade@instructure.com>
We're adding the https://purl.imsglobal.org/spec/lti/claim/lti1p1
migration claim that will support the `user_id` field.
closes INTEROP-6649
flag=none
test-plan:
* Have a LTI 1.3 tool installed;
* Launch the tool and verify the JWT contains the lti1p1 claim with the
user_id;
Change-Id: I9278a6b22c69336b8ef35190c09c171e9b62dce7
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/262421
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Reviewed-by: Mysti Lilla <mysti@instructure.com>
Reviewed-by: Weston Dransfield <wdransfield@instructure.com>
Product-Review: Wagner Goncalves <wagner.goncalves@instructure.com>
When launching a 1.3 tool as an unauthenticated user (possible in
public courses), Canvas sends the `sub` claim as
`https://canvas.instructure.com/public_user`
However, the sub claim should really be omitted when launching a tool as
an unauthenticated user, according to the IMS spec.
http://www.imsglobal.org/spec/lti/v1p3/#user-identity-claims
The `lti11_legacy_user_id` claim should follow the same behavior of
user_id laim in an LTI 1.1 tool. As `user_id` is empty when launching
a LTI 1.1 tool in a public course with unauthenticated user we're
changing the `lti11_legacy_user_id` claim to return an empty string
instead of `https://canvas.instructure.com/public_user`.
closes INTEROP-6599
flag=none
test-plan:
* Have a public course published;
* Install an LTI 1.3 tool with course navigation placement enabled, you
can use the this change in the LTI 1.3 Test Tool
https://gerrit.instructure.com/c/canvas-lms/+/262530, which disable
sub claim validation;
* As an unathenticated user, access the tool in the course navigation,
and verify that the tool should launch and the `sub` claim should not
be present and the `lti11_legacy_user_id` claim should em empty;
* As an athenticated user, access the tool in the course navigation,
and verify that the tool should launch and the `sub` and
`lti11_legacy_user_id` claims should be present;
Change-Id: I78bb64e3d898f44fcc401a43d054909032ef5420
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/262530
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Product-Review: Wagner Goncalves <wagner.goncalves@instructure.com>
refs INTEROP-6636
flag=none
* open new tab/window or a popup window depending on the message
the tool sends
* include new data from the tool like placement (so that deep linking
launches work), type of window, and width/height of popup
* keep a reference to opened window and close it when the dialog that
opened it also closes
* send postMessages to window.opener if present, instead of
window.parent - helps with tabs/popups opened by the page
* include the canvas placement in the LTI 1.3 launch token, in the
custom claims section - this is required so that the tool can pass it
in the full window launch request, so that Canvas knows whether it
should use a normal launch or a deep linking launch
test plan:
* make sure associated commits for the test tool and safari gem are
checked out and set up, see the test plan for those
* in safari, create a new assignment of type external tool
* choose the test tool from the list of tools
* it should tell you that it needs to open in a popup
* click the button and a popup should open (note: you should not have
Safari in fullscreen mode which is a bummer)
* you should click submit on that form to return a resource link
* the popup should close and the external tool dialog should have a
url in it, like normal
Change-Id: I46dc47cca7f26140041b6a638a8056a7cc0843db
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/261771
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Wagner Goncalves <wagner.goncalves@instructure.com>
Product-Review: Xander Moffatt <xmoffatt@instructure.com>
This is part 3 of changing the datatype from varchar to UUID of
lookup_id and resource_link_id from lti_resource_links.
We start to read from the new columns created lookup_uuid and
resource_link_uuid.
Adding a migration to remove the not-null constraint of lookup_id and
resource_link_id columns. As part 3.1 we'll stop writing into these
columns, we need to execute this postdeploy migration at this point.
refs INTEROP-6488
flag=none
test-plan:
* specs should pass;
* you should check if LTI is launching as expected, and if the custom
params was expanded as expected in all records that were created in the
part 1 and 2;
* you should be able to new persist custom params, for example you can
use the RCE editor placement;
* you can follow the test-plan:
* https://gerrit.instructure.com/c/canvas-lms/+/256029
* https://gerrit.instructure.com/c/canvas-lms/+/254453
[fsc-timeout=30]
Change-Id: I401f53a82f4dbef66c45932eb2eed8727488313d
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/258246
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Tucker Mcknight <tmcknight@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
Product-Review: Wagner Goncalves <wagner.goncalves@instructure.com>
This reverts commit def240c3c5.
This feature flag is no longer needed. And, there was actually a bug in
it which prevented adding multiple content items from working right: a
the js ENV key was called PROCESS_MULTIPLE_CONTENT_ITEMS but we were
checking ENV.process_multiple_content_items_modules_index
The module items were actually being added, but the dialog was not being
closed and the page refreshed as it should have been.
Note that an error (warning?) "invalid messageType:
LtiDeepLinkingResponse" appears in the console still. This appears to
not affect any functionality but I will look at fixing it soon.
Also note that sometimes when processing the deep linking response, I
will apparently get logged out of Canvas. I'm not sure what that's all
about, but this commit shouldn't make that any worse.
Closes INTEROP-6446
flag=process_multiple_content_items_modules_index
Test plan:
- Have the LTI 1.3 test tool installed with the Resource Selection or
Link Selection placement
- From the module index page, add a module item and choose "External
Tool" and choose the LTI 1.3 test tool
- Select "Return multiple Content items" and click "Submit" in the tool
- Three new module items should be created, and the "Add Item to..."
dialog should be closed, and the page refreshed to show the new items.
Change-Id: I85391199493eb0f96b7861c7e9d2318553bc5c91
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/256472
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Xander Moffatt <xmoffatt@instructure.com>
QA-Review: Mysti Lilla <mysti@instructure.com>
Product-Review: Evan Battaglia <ebattaglia@instructure.com>
Evan Battaglia