enable debugging in rails 3 specs without '-d' option

Change-Id: I898645bb63d1bb76f888cbf23fe867d6d71c7229
Reviewed-on: https://gerrit.instructure.com/30018
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams  <jamesw@instructure.com>
QA-Review: James Williams  <jamesw@instructure.com>
add dynamic_form gem for rails 3

adds error_messages and error_messages_for helpers

Change-Id: I209ed14a0b764190b3f06e5d107a4261144a25a8
Reviewed-on: https://gerrit.instructure.com/30015
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams  <jamesw@instructure.com>
QA-Review: James Williams  <jamesw@instructure.com>
switch link_to block helper to rails 3 format

'<% link_to' to '<%= link_to'

Change-Id: I71fa45f9c59ce7cc685bc05242f4f22750ab43a6
Reviewed-on: https://gerrit.instructure.com/30014
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams  <jamesw@instructure.com>
QA-Review: James Williams  <jamesw@instructure.com>
converting @object notation to @model part 6/11

converting for:
favorites controller
feature flags controller
files controller
folders controller
grade change audit api controller

Contributed by github.com/mcgachey

Fixes SIS-146

Currently, some API objects are documented using the @object tag, and
others are documented using @model. The @model tag is preferred because
it provides more information in the machine-readable Swagger documents
generated by the API documentation build step. For example, the @object
notation does not give a way to specify that a model property contains
an instance of another type. This complete information is necessary in
order to build an SDK generator.

This change converts the @object notations into @model, adding missing
type information and correcting inaccurate data (for example, dates were
typed as "string" in the existing JSON documentation). Embedded types are
also separated out so that their format can also be documented - this
information was previously lost.

The change also makes two minor fixes to the HTML and JSON documentation
generators. The HTML generator is fixed so that a missing documentation
string is ignored rather than being shown as an empty comment, and the
JSON generator is modified so that the Model-level documentation and
required attributes are properly provided.

Note that the JSON generated here is not fully-complient to the Swagger
format. Swagger does not support a Map structure, but the Canvas API
uses (semi-)arbitrary key/value dictionaries in a few places. In those
instances the properties are typed as "map", but this is not a part of the
Swagger spec. Any cleaner alternative approaches here would be welcome.

Change-Id: I5d90bd33f393f5b55c6a4d50b7e92c87648b9ba3
Reviewed-on: https://gerrit.instructure.com/30000
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
converting @object notation to @model part 7/11

converting for:
grade book history controller
group categories controller
group membership controller
groups controller
migration issues controller

Contributed by github.com/mcgachey

Fixes SIS-146

Currently, some API objects are documented using the @object tag, and
others are documented using @model. The @model tag is preferred because
it provides more information in the machine-readable Swagger documents
generated by the API documentation build step. For example, the @object
notation does not give a way to specify that a model property contains
an instance of another type. This complete information is necessary in
order to build an SDK generator.

This change converts the @object notations into @model, adding missing
type information and correcting inaccurate data (for example, dates were
typed as "string" in the existing JSON documentation). Embedded types are
also separated out so that their format can also be documented - this
information was previously lost.

The change also makes two minor fixes to the HTML and JSON documentation
generators. The HTML generator is fixed so that a missing documentation
string is ignored rather than being shown as an empty comment, and the
JSON generator is modified so that the Model-level documentation and
required attributes are properly provided.

Note that the JSON generated here is not fully-complient to the Swagger
format. Swagger does not support a Map structure, but the Canvas API
uses (semi-)arbitrary key/value dictionaries in a few places. In those
instances the properties are typed as "map", but this is not a part of the
Swagger spec. Any cleaner alternative approaches here would be welcome.

Change-Id: I8ae7fbee715a0450223c6e773fa643c8b2ebf02b
Reviewed-on: https://gerrit.instructure.com/30001
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
Fix some incorrect `check_box_tag` calls

Fixes CNVS-11000.

There were some places where check_box_tag was being used to generate
markup like `<input type="checkbox" value="{:class=>\"checkbox\"}">`.
Just changing the calls to match the actual method signature.

Test plan:

1. This is tricky. The offending forms are in the OAuth2 authorization
   flow, so you'll need to point some third-party app's OAuth
   authentication at your local Canvas instance. May I humbly suggest
   Gallery?
2. When the third-party app redirects to Canvas for authorization,
   inspect the checkbox where it says, "Remember my authentication for
   this service". You should see a checkbox input with a class of
   "checkbox" and a value of "1".

Change-Id: I82a60cb8aed741815feb879c99d1e10cae48da77
Reviewed-on: https://gerrit.instructure.com/29726
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Marc LeGendre <marc@instructure.com>
QA-Review: Marc LeGendre <marc@instructure.com>
converting @object notation to @model part 8/11

converting for:
notification preferences controller
outcome groups controller
outcome results controller
outcome api controller
page views controller

Contributed by github.com/mcgachey

Fixes SIS-146

Currently, some API objects are documented using the @object tag, and
others are documented using @model. The @model tag is preferred because
it provides more information in the machine-readable Swagger documents
generated by the API documentation build step. For example, the @object
notation does not give a way to specify that a model property contains
an instance of another type. This complete information is necessary in
order to build an SDK generator.

This change converts the @object notations into @model, adding missing
type information and correcting inaccurate data (for example, dates were
typed as "string" in the existing JSON documentation). Embedded types are
also separated out so that their format can also be documented - this
information was previously lost.

The change also makes two minor fixes to the HTML and JSON documentation
generators. The HTML generator is fixed so that a missing documentation
string is ignored rather than being shown as an empty comment, and the
JSON generator is modified so that the Model-level documentation and
required attributes are properly provided.

Note that the JSON generated here is not fully-complient to the Swagger
format. Swagger does not support a Map structure, but the Canvas API
uses (semi-)arbitrary key/value dictionaries in a few places. In those
instances the properties are typed as "map", but this is not a part of the
Swagger spec. Any cleaner alternative approaches here would be welcome.

Change-Id: Ie2f42a8c3544b53e1b08ba35c7a3382afba2ab0f
Reviewed-on: https://gerrit.instructure.com/30002
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
converting @object notation to @model part 9/11

converting for:
profile controller
progress controller
quiz questions controller
quiz reports controller
quizzes api controller

Contributed by github.com/mcgachey

Fixes SIS-146

Currently, some API objects are documented using the @object tag, and
others are documented using @model. The @model tag is preferred because
it provides more information in the machine-readable Swagger documents
generated by the API documentation build step. For example, the @object
notation does not give a way to specify that a model property contains
an instance of another type. This complete information is necessary in
order to build an SDK generator.

This change converts the @object notations into @model, adding missing
type information and correcting inaccurate data (for example, dates were
typed as "string" in the existing JSON documentation). Embedded types are
also separated out so that their format can also be documented - this
information was previously lost.

The change also makes two minor fixes to the HTML and JSON documentation
generators. The HTML generator is fixed so that a missing documentation
string is ignored rather than being shown as an empty comment, and the
JSON generator is modified so that the Model-level documentation and
required attributes are properly provided.

Note that the JSON generated here is not fully-complient to the Swagger
format. Swagger does not support a Map structure, but the Canvas API
uses (semi-)arbitrary key/value dictionaries in a few places. In those
instances the properties are typed as "map", but this is not a part of the
Swagger spec. Any cleaner alternative approaches here would be welcome.

Change-Id: I0604516bb3d6cad94e99c98309db3ff6d0b2c19c
Reviewed-on: https://gerrit.instructure.com/30003
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
converting @object notation to @model part 10/11

converting for:
role overrides controller
sections controller
sis imports api controller
submissions api controller
submissions controller

Contributed by github.com/mcgachey

Fixes SIS-146

Currently, some API objects are documented using the @object tag, and
others are documented using @model. The @model tag is preferred because
it provides more information in the machine-readable Swagger documents
generated by the API documentation build step. For example, the @object
notation does not give a way to specify that a model property contains
an instance of another type. This complete information is necessary in
order to build an SDK generator.

This change converts the @object notations into @model, adding missing
type information and correcting inaccurate data (for example, dates were
typed as "string" in the existing JSON documentation). Embedded types are
also separated out so that their format can also be documented - this
information was previously lost.

The change also makes two minor fixes to the HTML and JSON documentation
generators. The HTML generator is fixed so that a missing documentation
string is ignored rather than being shown as an empty comment, and the
JSON generator is modified so that the Model-level documentation and
required attributes are properly provided.

Note that the JSON generated here is not fully-complient to the Swagger
format. Swagger does not support a Map structure, but the Canvas API
uses (semi-)arbitrary key/value dictionaries in a few places. In those
instances the properties are typed as "map", but this is not a part of the
Swagger spec. Any cleaner alternative approaches here would be welcome.

Change-Id: I6c878eaeab2f41a15a5a323abe35ae6c7d9287dc
Reviewed-on: https://gerrit.instructure.com/30004
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
converting @object notation to @model - Part 1/11

Contributed by github.com/mcgachey

  app/controllers/account_authorization_configs_controller.rb
  app/controllers/account_reports_controller.rb
  app/controllers/accounts_controller.rb
  app/controllers/admins_controller.rb
  app/controllers/appointment_groups_controller.rb

Fixes SIS-146

Currently, some API objects are documented using the @object tag, and
others are documented using @model. The @model tag is preferred because
it provides more information in the machine-readable Swagger documents
generated by the API documentation build step. For example, the @object
notation does not give a way to specify that a model property contains
an instance of another type. This complete information is necessary in
order to build an SDK generator.

This change converts the @object notations into @model, adding missing
type information and correcting inaccurate data (for example, dates were
typed as "string" in the existing JSON documentation). Embedded types are
also separated out so that their format can also be documented - this
information was previously lost.

The change also makes two minor fixes to the HTML and JSON documentation
generators. The HTML generator is fixed so that a missing documentation
string is ignored rather than being shown as an empty comment, and the
JSON generator is modified so that the Model-level documentation and
required attributes are properly provided.

Note that the JSON generated here is not fully-complient to the Swagger
format. Swagger does not support a Map structure, but the Canvas API
uses (semi-)arbitrary key/value dictionaries in a few places. In those
instances the properties are typed as "map", but this is not a part of the
Swagger spec. Any cleaner alternative approaches here would be welcome.

Change-Id: I0fc0ffaf06b072ebc9ff1e8644c655712c5c7469
Reviewed-on: https://gerrit.instructure.com/29994
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
converting @object notation to @model - Part 2/11

Contributed by github.com/mcgachey

  app/controllers/assignment_groups_controller.rb
  app/controllers/assignment_overrides_controller.rb
  app/controllers/assignments_api_controller.rb
  app/controllers/authentication_audit_api_controller.rb
  app/controllers/calendar_events_api_controller.rb

Fixes SIS-146

Currently, some API objects are documented using the @object tag, and
others are documented using @model. The @model tag is preferred because
it provides more information in the machine-readable Swagger documents
generated by the API documentation build step. For example, the @object
notation does not give a way to specify that a model property contains
an instance of another type. This complete information is necessary in
order to build an SDK generator.

This change converts the @object notations into @model, adding missing
type information and correcting inaccurate data (for example, dates were
typed as "string" in the existing JSON documentation). Embedded types are
also separated out so that their format can also be documented - this
information was previously lost.

The change also makes two minor fixes to the HTML and JSON documentation
generators. The HTML generator is fixed so that a missing documentation
string is ignored rather than being shown as an empty comment, and the
JSON generator is modified so that the Model-level documentation and
required attributes are properly provided.

Note that the JSON generated here is not fully-complient to the Swagger
format. Swagger does not support a Map structure, but the Canvas API
uses (semi-)arbitrary key/value dictionaries in a few places. In those
instances the properties are typed as "map", but this is not a part of the
Swagger spec. Any cleaner alternative approaches here would be welcome.

Change-Id: I450539cb5311778038c6179dd46ec06aa6c71791
Reviewed-on: https://gerrit.instructure.com/29995
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
converting @object notation to @model - Part 4/11

Contributed by github.com/mcgachey

  app/controllers/content_migrations_controller.rb
  app/controllers/context_module_items_api_controller.rb
  app/controllers/context_modules_api_controller.rb
  app/controllers/conversations_controller.rb
  app/controllers/course_audit_api_controller.rb

Fixes SIS-146

Currently, some API objects are documented using the @object tag, and
others are documented using @model. The @model tag is preferred because
it provides more information in the machine-readable Swagger documents
generated by the API documentation build step. For example, the @object
notation does not give a way to specify that a model property contains
an instance of another type. This complete information is necessary in
order to build an SDK generator.

This change converts the @object notations into @model, adding missing
type information and correcting inaccurate data (for example, dates were
typed as "string" in the existing JSON documentation). Embedded types are
also separated out so that their format can also be documented - this
information was previously lost.

The change also makes two minor fixes to the HTML and JSON documentation
generators. The HTML generator is fixed so that a missing documentation
string is ignored rather than being shown as an empty comment, and the
JSON generator is modified so that the Model-level documentation and
required attributes are properly provided.

Note that the JSON generated here is not fully-complient to the Swagger
format. Swagger does not support a Map structure, but the Canvas API
uses (semi-)arbitrary key/value dictionaries in a few places. In those
instances the properties are typed as "map", but this is not a part of the
Swagger spec. Any cleaner alternative approaches here would be welcome.

Change-Id: I4b5dc36833cc6899c1b390fa7cf665b5942fe886
Reviewed-on: https://gerrit.instructure.com/29999
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
converting @object notation to @model - Part 5/11

Contributed by github.com/mcgachey

  app/controllers/courses_controller.rb
  app/controllers/custom_gradebook_column_data_api_controller.rb
  app/controllers/custom_gradebook_columns_api_controller.rb
  app/controllers/discussion_topics_controller.rb
  app/controllers/enrollments_api_controller.rb
  app/controllers/external_feeds_controller.rb

Fixes SIS-146

Currently, some API objects are documented using the @object tag, and
others are documented using @model. The @model tag is preferred because
it provides more information in the machine-readable Swagger documents
generated by the API documentation build step. For example, the @object
notation does not give a way to specify that a model property contains
an instance of another type. This complete information is necessary in
order to build an SDK generator.

This change converts the @object notations into @model, adding missing
type information and correcting inaccurate data (for example, dates were
typed as "string" in the existing JSON documentation). Embedded types are
also separated out so that their format can also be documented - this
information was previously lost.

The change also makes two minor fixes to the HTML and JSON documentation
generators. The HTML generator is fixed so that a missing documentation
string is ignored rather than being shown as an empty comment, and the
JSON generator is modified so that the Model-level documentation and
required attributes are properly provided.

Note that the JSON generated here is not fully-complient to the Swagger
format. Swagger does not support a Map structure, but the Canvas API
uses (semi-)arbitrary key/value dictionaries in a few places. In those
instances the properties are typed as "map", but this is not a part of the
Swagger spec. Any cleaner alternative approaches here would be welcome.

Change-Id: I517fe9e0ae7132ffecbf606dec32f08879db43e9
Reviewed-on: https://gerrit.instructure.com/30006
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Rob Orton <rob@instructure.com>
Product-Review: Rob Orton <rob@instructure.com>
QA-Review: Rob Orton <rob@instructure.com>
fix user#courses_with_primary_enrollment for rails 3

also fix with_each_shard

Change-Id: Ideb8371e3e36059aeca8ca1b756ca9e9188f1116
Reviewed-on: https://gerrit.instructure.com/29978
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: James Williams  <jamesw@instructure.com>
QA-Review: James Williams  <jamesw@instructure.com>
spec: rails3 group category spec

Change-Id: I00e5b38cbeccae41fddbd73366f0173e0bce0595
Reviewed-on: https://gerrit.instructure.com/29960
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Jon Willesen <jonw@instructure.com>
QA-Review: Jon Willesen <jonw@instructure.com>
spec: fix external_tools_controller_spec in rails3

Change-Id: Iab9cdcead5036b18542cb02720057b62ab103cd2
Reviewed-on: https://gerrit.instructure.com/29970
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Product-Review: Jon Willesen <jonw@instructure.com>
QA-Review: Jon Willesen <jonw@instructure.com>
translate sis source_course_ids in migration api

test plan:
 - use the API to copy a course referred by sis_source_id

fixes CNVS-10959

Change-Id: I2297e86969dbc630f75a6ce856a3603b919fd62b
Reviewed-on: https://gerrit.instructure.com/29795
Tested-by: Jenkins <jenkins@instructure.com>
QA-Review: Nathan Rogowski <nathan@instructure.com>
Reviewed-by: Mark Severson <markse@instructure.com>
Product-Review: Jeremy Stanley <jeremy@instructure.com>
remove while(1) from API responses to application/json requests

fixes CNVS-11055

No browsers currently include Accept: application/json on requests for
<script> resources. It would be unreasonable for them to do so,
as even JSON-P uses application/javascript. Therefore, I believe
that application/json will remain a credible signal that a request
is not JSON-hijacking CSRF.

https://developer.mozilla.org/en-US/docs/HTTP/Content_negotiation#Values_for.C2.A0_scripts

test plan:
  * make an API request with and without the header
    Accept: application/json
  * verify that while(1) is prepended to the response
      iff the header is not present
  * smoke test Canvas pages which use Ajax

Change-Id: Iae830a4870175cae2b627227c85a5f1cc7801f69
Reviewed-on: https://gerrit.instructure.com/29882
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
QA-Review: Steven Shepherd <sshepherd@instructure.com>
Product-Review: Braden Anderson <banderson@instructure.com>
fix update in migration

Change-Id: Id53a495deecc002aefdba1440b309cd19ca7cc77
Reviewed-on: https://gerrit.instructure.com/30034
Reviewed-by: Rob Orton <rob@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
prevent NoMethodErrors when generating quiz statistics

Test plan:
  - Create a quiz with an essay question.
  - As a student, take the quiz but leave the question blank.
  - As the teacher, you should be able to generate item analysis
    and student reports without an error page.

refs CNVS-10773

Change-Id: Id8670751fb10a1faf89f1d3377a6426cf4b25d17
Reviewed-on: https://gerrit.instructure.com/29891
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Derek DeVries <ddevries@instructure.com>
QA-Review: Myller de Araujo <myller@instructure.com>
Product-Review: Stanley Stuart <stanley@instructure.com>