Check Kaltura to verify the media id is valid, then create the object,
so that we can track it as we normally do.
fixes#5775
also update some of the submission api documentation around media
comments and file uploads.
test plan: there isn't a UI to show media objects yet, so you'll have to
have console/db access. submit a video/audio submission comment through
the API, then verify that after jobs run, a MediaObject exists for the
media id you gave.
Change-Id: Id0f5b4cdc23330ea952e674df4fc0d1f1c81bf23
Reviewed-on: https://gerrit.instructure.com/12245
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan:
* add two sections to a course
* add a teacher or ta to a section, and limit them to that section
* as that teacher, go to GB2
* you should not be able to view any enrollments outside of that
section
Change-Id: I3d7dd17828cb79aaf162b0947640e2fa7da7952d
Reviewed-on: https://gerrit.instructure.com/11705
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
* Allow linking to individual endpoints on the page.
* Give each endpoint a summary string, and list the summaries at the top
of the page, with links to the endpoint details.
* Make an omnibus "all resources reference" page, which has been a
common request. This only includes the endpoint details, not the
summary descriptions of the resources.
* Syntax highlighting for JSON
test plan: visit /doc/api/index.html and see the changes (run rake
doc:api first if on a dev box)
Change-Id: Ib126805825d40770c36b3688668c62938348412d
Reviewed-on: https://gerrit.instructure.com/10516
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
This API abstracts away the difference between S3 uploads and local
storage uploads, while still allowing direct-to-S3 functionality to
avoid typing up Rails processes during S3 uploads.
The only concrete starting endpoint I've implemented in this changeset
is for submission file uploads. Uploads to course and user files is
coming in a subsequent changeset.
test plan:
see the api doc (generate with rake doc:api). repeat this test for both
s3 and local storage configurations.
first, post to the submission file upload endpoint, get your
upload_params back. use that to post the actual file data to the url
returned. then follow the redirect back to canvas, and verify you can
download the file from the url given in the json response. verify you
can attach the new file as part of an assignment submission.
edge cases to test:
* in local files, verify that attempts to modify the policy will fail
the request. in s3, amazon handles this.
* verify that if you do step 2 without step 3, the file isn't available.
* if you do step 1 but wait more than 30 min to do step 3, the upload
will be rejected.
* make sure you can't upload twice in the 2nd step
* make sure you can't verify twice in the 3rd step
Change-Id: I9b16b6e75defe9da551b965d9401f2cad8801f1d
Reviewed-on: https://gerrit.instructure.com/9552
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
also added checkbox (and api support, etc.) to assignment submission
forms and gradebook2
test plan:
1. create a group assignment
2. as a student, go to submit the assignment
3. ensure the group comment checkbox is present and unchecked on all
submission forms (file upload, text entry, etc.)
4. ensure that checking it sends a group comment and leaving it
unchecked does not
5. go to the submission details
6. ensure that the group comment checkbox is unchecked by default
7. as a teacher, go to the speedgrader and ensure the checkbox is
unchecked
8. go to the gradebook and ensure the checkbox is unchecked
9. go to gradebook2 and ensure it is unchecked and functional (wasn't
present before)
10. delete all comments and go to the dashboard. ensure that when you go
to add the first comment, you have a working group comment checkbox
(if there are existing comments on the stream item, you won't have a
real comment form, just a link that looks like a text area)
Change-Id: I009b797c2b391c20f41f33c7c0b8afdd4b57dbd3
Reviewed-on: https://gerrit.instructure.com/8978
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Allows submitting an assignment as a student.
test plan (API calls):
* submit as the four supoorted types
* submit a comment with the submission
* submit as a user not a student in the course, verify the 401
* submit invalid data, verify the 400
* as a teacher, verify you can view and grade the submission
Change-Id: Ie567d57987e2d5ed6532a0616d5a9c4681ee0364
Reviewed-on: https://gerrit.instructure.com/8717
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
Change all curl examples to use an oauth access token with the
Authorization header. Also cleanup of the pages discussing authorization
and oauth, and some general sprucing up of the documentation front pages.
test plan: n/a
Change-Id: I64dfe89932c4e98b6ea0f67b3ef09ba10a315444
Reviewed-on: https://gerrit.instructure.com/7764
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
fixes#6565
Test plan:
* get a student with a submitted homework that has been graded
* get /api/v1/courses/#{course.id}/assignments/#{assignment.id}/submissions/#{user.id}.json,
you should see the grade, score, etc.
* mute the assignment and re-get the submission json. the response
should lack grade/score/etc. keys
* check the api as a teacher, the information should still be returned.
* ditto, as an account admin with no enrollments in the course.
Change-Id: Iab46fcaae3d0485905f96f7e73e05b20c47b7435
Reviewed-on: https://gerrit.instructure.com/7297
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
fixes#6510
Most of this is a refactor so that all API JSON generation goes through
an api_json method, in order to standardize stuff like permissions and
:include_root. The existing specs verify that this doesn't inadvertently
change any existing responses -- except the discussion topics responses,
which were returning the :permissions array in the json unintentionally.
The refactor fixes the locked assignment response as a side effect.
Change-Id: I287b366fe05ef6116f713fc52075aff93d5e87b6
Reviewed-on: https://gerrit.instructure.com/7262
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
testplan:
* hit the API with a few different calls that use SIS ids (such as
sis_user_id:whatever), and make sure calls still return the correct
data. no calls currently use api_find_all, so nothing yet to test
there.
Change-Id: I2804c29a18342254a94709bac93a1ffb9b0467b8
Reviewed-on: https://gerrit.instructure.com/7026
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: John Harrison <john@instructure.com>
The conversations API had made up its own submission response format,
rather than using the standard submission formatting already used by
other API calls.
fixes#6289
testplan:
* as a teacher, create a conversation with a student
* create an assignment, and have the teacher and/or student comment on
the assignment submission
* verify those comments still appear in the conversations web ui
verify that the submission and comments now come back in the api
using the same format as the submissions api, with assignment and
comment data included
* make more than 10 comments, verify that only 4 are displayed at
first, then 10 total, and a link provided to view the full submission.
Change-Id: I05a37a1498fa3d6a1ab908c462a04d28f2854eb8
Reviewed-on: https://gerrit.instructure.com/6852
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
but don't allow them to grade :)
test-plan:
* attempt to post entry to discussion through api as student; should
succeed
* attempt to post reply to entry through api as student; should
succeed
* attempt to set graded through api as student; should be unauthorized
* attempt to apply rubric through api as student; should be
unauthorized
* attempt to set grade and/or apply rubric through api as teacher;
should succeed
Change-Id: I4215ef02d1b0e3b68661fd6ab228be203d45526c
Reviewed-on: https://gerrit.instructure.com/6780
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
teachers and TAs can be limited to a specific section, in which case we
need to enforce those limitations in the submissions api.
testplan: set up a course with 2+ sections, and a teacher who is only
allowed to access 1 of those sections. then verify:
* GET /submissions should not list users in other sections
* GET /submissions/:id for a user in another section should 404
* PUT /submissions/:id for a user in another section should 404
* GET for_students with user ids in other sections should not return those users
* all of the above should return no submissions if the user attempts to access the api via /sections/:section_id of the other section
close#5859
Change-Id: I102b13d1462f588277ca559f418785452e58e816
Reviewed-on: https://gerrit.instructure.com/6796
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
testplan: you can set up an assignment as an external_tool type
manually, and then hit the IMS certification test tool to verify that
replaceResult and readResult are now fully supported.
Change-Id: Id193ba1943f51b3cb4b6a2d078d8a2262c26659e
Reviewed-on: https://gerrit.instructure.com/6678
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
this is because we need it in $.fn.mediaComment('show')
Change-Id: Ia53912ef8bf25e255463234bf1bb1f806cf49dfa
Reviewed-on: https://gerrit.instructure.com/6028
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
fixes#5737
There is one situation where a session is still desireable -- if the
attachment data includes links, for instance a html file attachment,
then a session will be needed to view the links from that file. The
limited safefiles session will still be created when downloading the
file, so apps can optionally use the session to support that
functionality.
Change-Id: I48558c4a3217ebea92118f8f08d1254041bd65e5
Reviewed-on: https://gerrit.instructure.com/5860
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
* fix a bug in Api.map_ids that was causing a worthless SELECT for each id given
* pre-load all the assignments and manually set them on the
submissions, to avoid those individual queries
* if sis ids are given, resolve them to AR ids all in one query, rather
than individually
* allow excluding attachments and discussion_entries using the
response_fields/exclude_response_fields functionality
Change-Id: Ib48016f8440959a08637385f0ccaa23d40e7adde
Reviewed-on: https://gerrit.instructure.com/5975
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Shaw <ryan@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>
Finding users is a bit different, since the user's sis information is
actually stored on the pseudonym. Before, we were working around this in
the submissions api. I've generalized it to work everywhere that uses
the Api find functionality, and in the process fixed the page views api
so that it works with sis ids.
This is necessary as we add more user apis, like the upcoming
/users/:user_id profile API.
Also added the /users/self shortcut to query the various user apis for
the user accessing the api.
Also for consistency, deprecate users/activity_stream in favor of
users/self/activity_stream
Change-Id: Icb0776231070b838bb341893d12b1061b90c5d04
Reviewed-on: https://gerrit.instructure.com/5628
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
users have both a SIS user_id and login_id, return both in the API and
allow both as ids when specifying a user in API calls using the syntax
sis_user_id:someid and sis_login_id:someid
These columns in the db aren't well named, unfortunately, but we'll try
to at least be consistent in the API.
This is technically a breaking change for the API. We've decided to go
ahead with it, as this API functionality was only recently added.
Change-Id: I8eabe4226580aa3b1aec7e5b7082b045f786e605
Reviewed-on: https://gerrit.instructure.com/4556
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: JT Olds <jt@instructure.com>
This is a read-only view, it doesn't allow students to submit homework
through the API.
Change-Id: Ibb23d0f99d0c77b24b9c31fe204f97afcc5bb53c
Reviewed-on: https://gerrit.instructure.com/4339
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
I also had to change the api spec stuff a bit, which caused some changes
in other specs.
Change-Id: I62e87fa4c9e79716455ca47ca342c9eec86ddc39
Reviewed-on: https://gerrit.instructure.com/2848
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
Brian Palmer