instead of leaving the key with a nil value
test plan:
* no user visible changes
* creating a new course, accepting invitations, and
registering google docs, linked in, and twitter are good places
to make sure they haven't changed
Change-Id: Ied684744dd23a4c56c1abab0e7c197a28cd66f40
Reviewed-on: https://gerrit.instructure.com/10633
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
This lays the groundwork for the new collections feature. See the API
documentation for details. There is still some pending tasks before this
is totally ready, see the development board.
test plan: no UI yet, but you can make api calls to add/edit/delete
collections, add/edit/delete items, and upvote items.
Change-Id: I8fa019d428d1aae3ac62b1f34ebe2ac3c77310be
Reviewed-on: https://gerrit.instructure.com/10465
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@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>
test plan:
* as an admin, attempt to delete another user's communication
channel via the API and verify that call is successful and
returns deleted communication channel object (meaning its
workflow state is retired).
* as a user, attempt to delete your own communication channel
via the API and verify that the call is successful;
* as a user, attempt to delete another user's communication
channel via the API and verify that 401 is returned.
Change-Id: I636e8154a913710acada725fbf20ec7c306f8979
Reviewed-on: https://gerrit.instructure.com/10571
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
test plan:
* make call as account admin user, verify that channel is created
and in 'unconfirmed' state;
* make call as admin user with skip_confirmation=1 param, verify
that channel is still in 'unconfirmed' state;
* make call as site admin with skip_confirmation=1; verify that
channel is created as 'active';
* make call as any user to create a channel on your own account;
verify that call is successful;
* make call to create own channel with skip_confirmation=1; verify
that channel is still 'unconfirmed';
* make call as non-admin user to create channel for another user;
verify that 401 is returned.
Change-Id: I3108ac31b8b06f9202b9d11fa9475ed204a5f3f1
Reviewed-on: https://gerrit.instructure.com/10567
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan:
* as an admin user, make api request to return a user's
communication channels and verify that they are returned;
* make same request with `self` and verify that channels are
also returned;
* as a student or teacher, make a request for another user's
channels and verify that 401 is returned.
Change-Id: I002d5fcedbaa404d78ada09f2eabbea5fac59181
Reviewed-on: https://gerrit.instructure.com/10224
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
in places where we were trying to do a 'alert' style
box (like the "you've been invited to a course",
account notifications, "you can sign up for this" in
scheduler) we were doing things that were sometimes
ugly and always inconsistent. this change moves
them all to twitter bootstrap '.alert's
test plan:
* go to: /accounts/x/settings#tab-announcements and
create a new global announcement. make sure that
page looks good (like this: http://cl.ly/2p05312y0N1N2W261s1N ).
then go to your dashboard and make sure it looks
good there like this: http://cl.ly/0P1X3y2c2422082v222c
* as a student go to scheduler and make sure it looks
like http://cl.ly/311h1b1V0H321k0C0t3p
Change-Id: If077402a0ee9fd43976ce86918848ca5b21b41b8
Reviewed-on: https://gerrit.instructure.com/10294
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
slightly modified unique_constraint_retry so that:
1. it runs the block without using the query cache
2. it doesn't capture the UniqueConstraintViolation on the second failure
(should be impossible now, so we definitely want to know if it does)
also fixed a more general issue where inserts would not clear the query
cache if they raised a database error (e.g. violated a constraint)
test plan:
1. in two rails consoles, call Assignment.find_or_create_submission for
the same user/assignment at the same time inside of a query-cached
transaction, ensuring that they overlap, e.g.
Assignment.cache {
Assignment.transaction {
s = Assignment.find_or_create_submission(1, 1)
sleep 10
s
}
}
2. confirm that both commands complete successfully and return the newly
inserted submission
3. ensure that there is only one duplicate key error in your rails log
Change-Id: I128d331081229d640fb27c011b0216e25a59263c
Reviewed-on: https://gerrit.instructure.com/10400
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
this commit provides a new api endpoint that exposes the possible profile
pictures of a given user that can be set as her avatar. it also modifies the
existing user update api to allow the avatar image to be set. this permission
is given to the user herself and any account admin that has manage student
permissions
test-plan:
- make sure editing a user from the /users/x page and the /profile page still
works.
- with the api, try querying the users profile pictures, and setting a new
avatar.
- make sure to exercise different permissions:
* look up and change your own avatar => should succeed
* as an admin, look up and change a student's avatar => should succeed
* as a student, try to change another student's avatar => should return 401
Change-Id: Idefe8549a92e109a248936970f9e3ef2bc414a59
Reviewed-on: https://gerrit.instructure.com/9645
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
this is equivalent to our custom addition to do this escaping (though it
also escapes amperstands, which ours didn't)
test plan: do an api request that returns a json string with html
entities, or just load up the console and do a "<>&".to_json
Change-Id: Ifaeaa595de4bd621708b43c45f915a67409ef95a
Reviewed-on: https://gerrit.instructure.com/9614
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
remove links from calendar2 into event show page, unless the user has edit
privs (since there is no readonly view with the section-event change).
also fix links to event show page for section-level events (#8337).
fix dashboard notifications so that event creators aren't notified of
section-level events they create (#8338).
implement route and redirect for section-level events so that event
participants can click on the dashboard link and be taken right to the
event in calendar2 (#8339).
test plan:
1. create a regular dated event and a section-level dated event in
calendar2
2. confirm that you can get to the advanced edit page via the title link
or the more options link for both events
3. confirm that you do not get dashboard (or email) notifications about
either event
4. as a student, confirm that you get dashboard notifications about both
events
5. confirm that clicking on the dashboard link takes you right to each
event
6. confirm that you don't get any links to the advanced options page for
either event in calendar2
Change-Id: Ia0efcdbc7f8fa623cf0415ac630f80fee48a885d
Reviewed-on: https://gerrit.instructure.com/10369
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Tested-by: Jon Jensen <jon@instructure.com>
underscore has a throttle and debounce, it is included
in common now. so there is no reason to have another
library that does the same thing
Change-Id: I4a1ef5eb08d339c0099d5664db164c18ae10681a
Reviewed-on: https://gerrit.instructure.com/10306
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
add more structure to the turnitin_data hash on a submission to keep track of
what state things are in, so that we can present errors to the user as they
happen and provide a way to resubmit. there are three states: 'pending',
'error', and 'scored'.
submissions start out as 'pending', and can move to 'error' if anything goes
wrong in the submission process (either in creating the assignment, enrolling
the user, or actually submitting the paper). there are built in retrys, and the
error state only gets set if there is still an error after the retry limit. if
this succeeds, we stay pending until the score is successfully retrieved from
turnitin, at which point it is marked 'scored'.
this change is primarily in speed grader, although icons have been updated in
the gradebooks and submission pages as well. in the 'scored' state, (or without
a state) things should work exactly as they have previously - display a score,
which can be clicked to see the full report. in the 'error' state (indicated
with an exclaimation point icon), clicking the icon gives you more details
about the error and the option to resubmit. in the 'pending' state (indicated
by a clock icon), clicking the icon just explains that the submission is
pending.
test-plan:
- locate some submissions that were scored with turnitin before this change was
applied and verify that they still work as expected
- submit something new that will get sent to turnitin. verify that it initially
gets marked as pending, and then after 5-10 minutes has a score.
- submit something that will result in a turnitin error (eg: < 20 words,
password protected pdf). verify that it initially gets marked as pending,
then after ~30 minutes (to account for retries) is marked as an error.
- click the icon, and click the resubmit button. verify that it goes back to
pending.
- verify that the new turnitin icons for these submission in gradebooks 1 and
2 look correct and don't mess up the layout.
Change-Id: Ia5e1b04842de16aaa44d498eefe59ddb716dc014
Reviewed-on: https://gerrit.instructure.com/10125
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
closes: #7978
test plan:
with cal2 enabled:
* click on event in calendar, hit edit, click "more options"
* you should be at a new page.
* it should have transferred any new description,
start/end date you entered
* if it's for a course, you should see a checkbox
"different due date per section", if it's on your own
or a group cal, should not see that checkbox
* creating event should save properly so:
* verify that all events show up on calendar2
* when you go back to edit any of those events on
calendar the info should all load on this page again
* when you click "edit" on one of the section events
on the calendar it should let you edit the info for
all of the sections not just the one you clicked on.
with calendar 2 disabled:
* make sure you can still create events as you used
to be able to
Change-Id: I3491a7dbf4103db2f8ae95c9acbdc49597552d2c
Reviewed-on: https://gerrit.instructure.com/10141
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
when you require ['jquery'] you are now getting the
version of jquery that has our patches applied to it
you should not need to think about the patching as
you write code.
this also applies to jqueryui/dialog, that will return
the patched version of it.
test plan:
make sure javascript still works on our site ;)
Change-Id: I237fa8da5f93167140c4d42b80eb3ef17d95c1e6
Reviewed-on: https://gerrit.instructure.com/9878
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
Reviewed-by: Ryan Florence <ryanf@instructure.com>
This explicit confirmation step is an improvement on our
login-and-implicitly-accept workflow from before. And it allows us to do
the oauth workflow without forcing a logout, which is much more ideal
especially for embedded LTI tools that want to use oauth.
Eventually this dialog will contain more information on the app and the
permissions requested.
test plan:
As a client application, kick off the oauth workflow for a logged-in
user, verify the user goes straight to the confirmation screen. Verify
you only get a code back if they accept, and an error if they deny. Do
the same without a web session, verify you go to the confirmation screen
straight after logging in.
Change-Id: Idf9905b795979339aec0cb5e4e058f4507a81bac
Reviewed-on: https://gerrit.instructure.com/9804
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Whitmer <brian@instructure.com>
changes quiz editing UI such that you can't exceed 1000 questions. quizzes
that already have over 1000 questions can still be edited, but new
questions cannot be added. this limit covers both regular questions as
well as question groups (e.g. "pick 20 of the following questions"). the
changes only affect the quiz UI and have no impact on question banks, or
on quizzes or banks created/updated via import.
also doubles the Rack::Utils.key_space_limit to 128 KB so that (most)
existing large quizzes can be taken successfully. this sets a rough upper
bound of ~1500 questions for a quiz.
test plan:
1. on the old code, create a quiz with > 1000 questions (easiest via
question groups)
2. on the new code, confirm that you can edit and remove existing
questions on the quiz.
3. confirm that you cannot add any questions (either standalone or via
groups) until the total is below 1000 again
4. take a quiz with 1000 questions
5. confirm that you can submit the quiz without getting a 500 error
Change-Id: Ifa211ed5baa461351e747dac3266f77623626f3c
Reviewed-on: https://gerrit.instructure.com/10094
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
so that a plugin can require it from its init.rb, without pulling in
all of our other AR extensions
Change-Id: I1f72d5f23e1437049820860f52abab29c12b6248
Reviewed-on: https://gerrit.instructure.com/10191
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
if you want Backbone, require 'Backbone' --it will have
the patches we made to it's default functionality.
same for underscore, just require 'underscore' you should
not have to 'use!underscore'
Change-Id: I374d4efbc60ccb66a88299346a6e415c976fbef0
Reviewed-on: https://gerrit.instructure.com/10184
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
respect "hidden" flag such that we don't show parent events of section-
level events in the calendar or upcoming events.
when viewing the section-level event's details, show the section name.
when editing a section-level event, don't allow changing the title.
link to parent event when clicking "more options"
test plan:
1. create an event with section-level child events (currently only
possible via api or console)
2. go the course calendar (calendar2)
1. confirm that the parent event is not visible
2. confirm that the section-level events are visible
3. click on a section-level event
4. confirm that the section name appears in the details
5. edit a section-level event
6. confirm that you can change the date/times but not the title
7. click the more options link and confirm it takes you to the parent
event
3. go to the dashboard
1. confirm that the parent event is not visible in upcoming events
2. confirm that the section level-events are visible
Change-Id: I8eadc53b7c47922f753625930d94d4f08386c817
Reviewed-on: https://gerrit.instructure.com/10116
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
Reviewed-by: Cameron Matheson <cameron@instructure.com>
added a child_event_data attribute that can be set during create and
update for specifying child events. the initial use case is for section-
level events under a course. other context types will return an error
child_event_data should be an array of objects representing the child
events. each object must have a context_code and may have a start_at/
end_at, e.g. child_event_data[0][context_code]=course_section_1&...
when updating a calendar event, child_event_data will replace previous
child events (creating/updating/deleting, as appropriate)
to delete all child events when updating, set remove_child_events=1
when querying events for a given course (via index), child events for the
course's sections will now appear (limited to the user's visibility)
test plan:
1. create a calendar event via the api and specify child events
2. confirm that they were created correctly
3. confirm that the index action returns those child events when searching
by course
4. update the calendar event and change the child events
5. confirm the child events were deleted successfully
6. update the calendar event and delete all child events (via
remove_child_events=1)
7. confirm the child events are deleted
8. delete an event that has child events
9. confirm that the child events are deleted as well
Change-Id: If94b17a9c33ca3a56f7b97908c8c659e12364d8b
Reviewed-on: https://gerrit.instructure.com/10021
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
test plan:
* add a role override with the api as an authorized user
and verify that it is added and that it is correctly
returned;
* attempt to lock an override with the api as an authorized
user and verify that it is correctly locked;
* attempt to add a role override as an unauthorized user
and verify that 401 is returned;
Change-Id: I99f4dba11dcc121d4b2565e59d5ec1fc148e3289
Reviewed-on: https://gerrit.instructure.com/10083
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
affects: enrollments api
test plan:
* create a course and enroll a teacher and three students;
* as teacher, make api call to conclude student 1 enrollment
and verify that student is successfully unenrolled;
* as teacher, make api call to delete student 2 enrollment
and verify taht student is successfully deleted;
* as student 3, make api call to delete teacher enrollment and
verify that 401 is returned;
* as teacher, make api call to unenroll self. verify that call
fails unless teacher also has permissions to enroll itself
in a course.
Change-Id: I394d515bac0c5461827cd8c01be1fddcff29c309
Reviewed-on: https://gerrit.instructure.com/9770
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
count can be slow if there are a lot. also remove the "last" link
from api responses that skipped the count
test plan:
* go to a user's page with less than 50 page views; they should show
and it should not try to load more
* go to a user's page with hundreds to thousands of page views; they
should load on demand, and when you reach the bottom, it should
stop trying to load more
Change-Id: I934cd7260232b78c33ae5fc1be5e49b2ea686614
Reviewed-on: https://gerrit.instructure.com/10135
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
there is no need to as they only apply to the
gradebook history page
test plan:
* /courses/x/gradebook/history and make sure
everything is still styled right
Change-Id: I69d194090ab5c7afa1fd597aefa78d7189f81889
Reviewed-on: https://gerrit.instructure.com/9873
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Joe Tanner <joe@instructure.com>
refactored conversations pane, implemented ajaxy scrollable list widget,
partially backbone.js'ed conversation items, re-did fragment hash fu, and
made filter/scope changes update the page via ajax.
from an end-user perspective, the noticeable changes are:
1. filters/scopes update the page via ajax
2. the conversations pane appears to load more quickly now (we set it to
the full height from the outset, and things load in as you scroll)
test plan:
1. general regression test of conversations, specifically focusing on:
1. actions that remove a conversation from the list, e.g.
1. deleting it
2. deleting all messages from it
3. marking it as read when in the unread filter
4. archiving/unarchiving (depending on the view)
2. actions that update a conversation in the list, e.g.
1. adding a message should update the preview and move it to the top
2. deleting the most recent message should move it down in the list
3. sending a new message to an existing conversation should update
it (and possibly reposition it)
3. actions that should add a conversation to the list
1. starting a new conversation, provided that it should be visible
under the current filter/scope
2. if the conversation should not be visible (e.g. start a new
conversation under the archived scope), simply display the
"Message Sent" notification but don't show the conversation
2. test ajax loading of filters and scopes. confirm that back button works
3. test scrollable list component
1. confirm the scrollable list is big enough for all items in the view
2. confirm that items load as you scroll
3. confirm that jumping to the very bottom loads those items in a
timely manner (they should load before the skipped middle stuff
does)
Change-Id: Icb1e09f34c653b55c62de0c82ac0cfc172827520
Reviewed-on: https://gerrit.instructure.com/9612
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Zach Pendleton <zachp@instructure.com>
test plan:
* run Reporting::CountsReport.process; it should work
* add a slave db configuration as a child of the current
environment to database.yml; re-run the CountsReport
Change-Id: Iba08d6697cf0e864ecbc3a2829fcd7a134267bec
Reviewed-on: https://gerrit.instructure.com/10100
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Bracken Mosbacker <bracken@instructure.com>
affects: pseudonym/login api
test plan:
* create a user with two pseudonyms;
* as an unauthorized user, make api call and verify that
401 is returned;
* as an authorized user, make api call and verify that api is
deleted;
* as an authorized user, make api call to delete the last
pseudonym and verify that error is returned.
Change-Id: Ic80b0b77db365298150422a87494aedf3cb57359
Reviewed-on: https://gerrit.instructure.com/9765
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
like find_ids_in_batches, but returns a closed range of the ids,
instead of the actual ids so that whatever's iterating over the
table doesn't have to use a huge IN clause
test plan:
* run the specs
Change-Id: Id22c197a6e4d80db49cc6ec99bb3e79e6fb69523
Reviewed-on: https://gerrit.instructure.com/10066
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
start tracking root_account_ids more consistently for messages, and
aggregate them on the conversation. add a scope when masquerading such
that conversations tied to other root accounts are hidden. a masquerader
must have access to all root accounts a conversation belongs to in order
to see it (unless the masquerader is a site admin)
test plan:
1. enroll a user in courses under two different root accounts (let's call
them accounts A and B)
2. as the user, log in under the account domain for A and send some
messages
3. log in under the account domain for B and send some messages to
the existing conversations, as well as to some new recipients
4. set up an account admin with access only to B
5. log in as the admin, and masquerade as the user
6. ensure you can only see conversations created under B (none of the ones
that are solely A, or both A and B)
7. log in as a site admin, and masquerade as the user
8. ensure you can see conversations from both accounts
Change-Id: I4a26b8b8914fd531103bb92c3d4442de843d9986
Reviewed-on: https://gerrit.instructure.com/9767
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jon Jensen <jon@instructure.com>
in the new discussions we changed a key that used to have an interpolated value
to one that no longer has one. Since the spanish translation lags a bit, this
causes an error until the new translation is done.
test-plan:
- in a course that has a dashboard entry about a graded discussion topic
- switch course locale to spanish
- make sure the dashboard loads
Change-Id: Ia41fe4b40ec08ad5de78005e4b3a42d007c2c036
Reviewed-on: https://gerrit.instructure.com/9837
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
* merged Api::V1::Enrollment into Api::V1::User because of a circular
dependency
* adding enrollments and email fields to #user_json
* adding associated_user_id, updated_at, and locked fields to
#enrollment_json
/api/v1/courses/:course_id/users
test plan:
* create a course
* enroll a user twice in the course (e.g. a TA)
* call the api with 'enrollments' and 'email' in include[]
* verify that the user data includes an email and two enrollments
Change-Id: I2f09c72c0e60fb7d2cd5bc7b585834970ad7a7cf
Reviewed-on: https://gerrit.instructure.com/9607
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
allows course admins to view the course from a student perspective. this is
accessible from a button on the course/settings page. They should be able to
interact with the course as a student would, including submitting homework and
quizzes. Right now there is one student view student per course, so if the
course has multiple administrators, they will all share the same student view
student.
There are a few things that won't work in student view the way the
would for a normal student, most notably access to conversations is disabled.
Additionally, any publicly visible action that the teacher takes while in
student view will still be publicly visible -- for example if the teacher posts
a discussion topic/reply as the student view student, it will be visible to the
whole class.
test-plan:
- (the following should be tried both as a full teacher and as
a section-limited course admin)
- set up a few assignments, quizzes, discussions, and module progressions in
a course.
- enter student view from the coures settings page.
- work through the things you set up above.
- leave student view from the upper right corner of the page.
- as a teacher you should be able to grade the fake student so that they can
continue to progress.
- the student should not show up in the course users list
- the student should not show up at the account level at all:
* total user list
* statistics
Change-Id: I886a4663777f3ef2bdae594349ff6da6981e14ed
Reviewed-on: https://gerrit.instructure.com/9484
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
add the selective course copy back in and change it to
use the updated format for what items are selected
Test Plan:
* Copy some courses and selectively choose items
* Only the items you selected should copy
refs #4645
Change-Id: Id5043b4e5e4a285b1f5cefd2ab16473052026484
Reviewed-on: https://gerrit.instructure.com/9763
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
This adds the ability for ContentMigration to copy courses
by exporting to a content package and then importing that
package. For attachments it just creates a new Attachment
object instead of exporting/importing them.
The course copy API did not change.
The endpoints used by the course copy UI did change and this
commit doesn't allow selective copying, it only has the
option to copy everything. Selective copying will come in
another commit.
There are also various bug fixes for export/import
Test Plan:
* copy a course through the API
* copy a course through the Content Imports path
* copy a course through the Copy Cours button on the course settings page
* export a course
refs #4645
Change-Id: Ie577329ab7caaea8dfb9359542224a1a2657e167
Reviewed-on: https://gerrit.instructure.com/9742
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Reviewed-by: Simon Williams <simon@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>
affects: pseudonym/login api
test plan:
* create a user with multiple pseudonyms across accounts;
* make request to /api/v1/users/:user_id/logins and verify that
all of that user's pseudonyms are returned.
* make same request as unauthorized user and verify that 401 is
returned.
Change-Id: Ic932ce9bef6bcfbe3ecb3340f640f44fbf4115a4
Reviewed-on: https://gerrit.instructure.com/9718
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
no more maintaining spec/javascripts/supports/specs.js to tell the
runner which specs to run. instead, the runner is built from an erb that
determines the list of specs to run from the filesystem. this new way is
also plugin friendly by maintaining a plugin symlink to include plugin
specs in the spec/coffeescripts tree.
second, give the runner page to the phantomjs execution as a file:///
path rather than just a local path. the latter worked on the build
machine, but failed with the phantomjs installed viw macbrew.
third, clean up/out some slightly broken specs.
* ENVSpec fails when the specs are reordered by the dynamic globbing,
but is no longer necessary anyways (since ENV is global now)
* the 'specs/helpers/' path in TemplateSpec doesn't work with the new
setup, but just 'helpers/' does and is what it should have been using
before anyways.
* asyncTest is not reliable. once the specs started running in a
slightly different order (thanks to the initial point), they started
failing with asyncTest race conditions. use fakeTimers and
fakeServers instead when appropriate.
* found and fixed a minor bug in BackoffPoller while converting/fixing
its asyncTests
test-plan:
- run rake js:test; should run completely as before
- add a plugin with a spec in spec_canvas/coffeescripts then run rake
js:test again; the plugin's spec should be executed.
Change-Id: I9ce5a038829a9e747df26d878ce86dbb7da8c384
Reviewed-on: https://gerrit.instructure.com/9411
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Hudson <hudson@instructure.com>
closes#7775
Allows specifying the folder to upload to as a slash-separated string,
as well.
test plan:
upload to both the current user, and an allowed course, verify the
workflow for s3 and local files. verify you can't upload to course you
don't have permissions to, or another user.
verify that you can specify a folder, and the folder will be created if
it doesn't exist.
Change-Id: Ib9082f047c1c93824fe65decf4789606d82450c6
Reviewed-on: https://gerrit.instructure.com/9603
Tested-by: Hudson <hudson@instructure.com>
Reviewed-by: Cody Cutrer <cody@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>
* 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>
Cody Cutrer