When we're lauching submission details in beta, we notice that some
AccountDomains hosts is point to production instead of beta. The
`UrlHost.context_host` method in beta is from the (MRA) plugin
https://gerrit.instructure.com/plugins/gitiles/multiple_root_accounts.
Example:
!PRODUCTION (canvas-fra-beta secondary)!
irb(main):026:0> HostUrl.context_host(@context.root_account)
=> "quizzesqa-fra.instructure.com"
So, we're adding `current_host` to the Submission::ShowPresenter, that
will be used to discover the correct host when lauching the submission
details page in beta.
Example:
!PRODUCTION (canvas-fra-beta secondary)!
irb(main):027:0> current_host = 'quizzesqa-fra.beta.instructure.com'
irb(main):028:0> HostUrl.context_host(@context.root_account, \
current_host)
=> "quizzesqa-fra.beta.instructure.com"
closes INTEROP-6594
flag=none
test-plan:
* Have an LTI 1.3 tool installed;
* Have a Course recorded;
* Have a Student enrolled to this Course;
* Have an Assignment recorded to this Course;
* As a Student you should be able to access the Assignment to submit your
homework. At the submission homework page you should be able to find
LTI tool (usually rendered in a tab);
* When accessing the Submission Details page you should be able to see
that the tool was launched properly;
* When accessing the Submission Details page in beta you should be able
to see that the tool was launched properly using the beta domain
instead of production domain;
Change-Id: I9053d168c3d56a8455335b579804265a077c5387
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/260271
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Mysti Lilla <mysti@instructure.com>
QA-Review: Wagner Goncalves <wagner.goncalves@instructure.com>
Product-Review: Wagner Goncalves <wagner.goncalves@instructure.com>
closes INTEROP-6315, INTEROP-6319
flag=none
test plan:
* Have an LTI tool installed with homework submission and RCE editor
placement enabled;
* Have a Course recorded;
* Have a Student enrolled to this Course;
* Have an Assignment recorded to this Course;
* Have LTI links added to the RCE editor in that assignment (later,
we'll check if this link still working because we're changing the
resource_link_lookup_id to resource_link_lookup_uuid LTI tool launch
parameter)
* As a Student you should be able to access the Assignment to submit your
homework. At the submission homework page you should be able to find
LTI tool (usually rendered in a tab);
* Specify the custom params do you want to record, and submit it from the
tool. You can add some comment too, and click to the submit assignment
button;
* When accessing the Submission Details page you should be able to see
that the tool was launched. At this point, the tool is launched via m
eta refresh tag https://www.w3.org/TR/WCAG20-TECHS/H76.html.
You can check the application logs to see that a request was performed
with resource_link_lookup_uuid parameter and you could check that the
custom claim contains all custom params specified in the previous step;
* As a Teacher/SiteAdmin when accessing the SpeedGrader via Gradebook
page you should be able to acces the homework submission via tray.
After selecting the desired student you should be able to see the tool
launched via iframe and the src URL should have the
resource_link_lookup_uuid (I did this by inspecting the HTML elements)
parameter. You should check if the custom claim has all expected
parameters;
* You can Re-Submit a homework with different custom params to check
that the custom claim was changed and was generate a new resource link
(resource_link_lookup_uuid);
* Check if the LTI links added to the RCE editor still working;
* Add new links to the RCE editor and check if is working as expected;
[fsc-timeout=30]
Change-Id: I00c2bcdc02c7a5134efff1deff836657071067fa
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/256716
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Evan Battaglia <ebattaglia@instructure.com>
Product-Review: Karl Lloyd <karl@instructure.com>
Reviewed-by: Evan Battaglia <ebattaglia@instructure.com>
test plan:
* generate a peer review notification
* the link should have a full url with host
closes #CNVS-46754
Change-Id: I6e1f7b028e79adbabbb102f5b644dc91bf76b286
Reviewed-on: https://gerrit.instructure.com/206925
Tested-by: Jenkins
Product-Review: James Williams <jamesw@instructure.com>
Reviewed-by: Gary Mei <gmei@instructure.com>
Reviewed-by: Jeremy Neander <jneander@instructure.com>
QA-Review: Jeremy Neander <jneander@instructure.com>
fixes GRADE-2058
Test plan:
NB: In the test plan below, "anonymized" refers to links of the form:
assignments/<assignment ID>/anonymous_submissions/<anon ID>
as opposed to the standard, "non-anonymized" form:
assignments/<assignment ID>/submissions/<user ID>
Note that the above format is solely for submissions and submission
comments: rubrics behave a bit differently, as described below.
Setup:
- Create the following assignments corresponding to test sections:
1. An assignment with anonymous peer reviews
2. An assignment with non-anonymous peer reviews
3. An assignment with anonymous peer reviews + a rubric
4. An assignment with non-anonymous peer reviews + a rubric
- For each assignment, assign some peer reviews
- Have the Network panel in your browser's developer tools handy so you
can see the requests being sent, as described below
Testing (1):
- As a peer-reviewer, open the assignment
- The 'Assigned Peer Reviews' links should be anonymized
- Select one to peer-review
- Check that leaving a comment sends an anonymized request
- As that student, open your own submission details page
- This URL should *not* be anonymized
- Leaving a comment should send a non-anonymized request
- As a grader, open the submission details page for a student
- The links should *not* be anonymized
Testing (2):
- As a peer-reviewer, open the assignment
- The peer review links and comment requests should *not* be
anonymized
- As a grader, open the assignment
- Same here; links should not be anonymized
Testing (3):
- Take a mighty breath and gird yourself for battle
- As a peer-reviewer, open the assignment
- Click "Show Rubric" and submit a rubric assessment
- Check that the parameters of the sent request include:
- rubric_assessment[anonymous_id]: <anonymous ID>
- They should *not* include rubric_assessment[user_id]
- Unlike with submissions, the URL will not change for
anonymous rubric assessments (since it includes no
data directly identifying the user)
- As a grader, open the assignment
- Submit a rubric assessment
- Check that the parameters of the sent request include:
- rubric_assessment[user_id] (i.e., same as before)
A note on testing rubrics: as far as I can tell, students can't edit a
peer review rubric after they've submitted it. To work around this in
testing, you can set the workflow_state of the relevant RubricAssessment
to 'assigned' (instead of 'completed') and it'll be editable again.
Testing (4):
- Same as (3), but in both cases we should send
rubric_assessment[user_id] as before
Finally:
- Do some smoke testing for assignments (3) and (4) in SpeedGrader to
make sure we haven't broken rubrics there
- Note that SpeedGrader will not currently attempt to anonymize
rubric assessments as described above even if anonymous grading
is enabled, which is fine for now since peer reviewers can't
access SpeedGrader
Change-Id: I25d9350a6a486fd5ba84b9c784017eac45d24098
Reviewed-on: https://gerrit.instructure.com/184406
Tested-by: Jenkins
Reviewed-by: Jeremy Neander <jneander@instructure.com>
Reviewed-by: Gary Mei <gmei@instructure.com>
QA-Review: Gary Mei <gmei@instructure.com>
Product-Review: Jonathan Fenton <jfenton@instructure.com>
Wagner Gonçalves