This will bypass a lot of extra rails requests on things like discusison
topic pages.
refs #9679
test plan: load a discussion topic with lots of user avatars of
different types, veryify they still display correctly.
Change-Id: I29829806da30410c6b938ff3bcf54329a58698c4
Reviewed-on: https://gerrit.instructure.com/13050
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Brian Palmer <brianp@instructure.com>
fixes#6233
test plan:
* add a file to a module
* upload a new file with the same name, overwriting the old one
* make sure the file still appears in the module
* make sure the new content is downloaded
Change-Id: Ic861cfd89aa30436f2abcf5d52e00efbcfb935e9
Reviewed-on: https://gerrit.instructure.com/12851
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
test plan: no visible change in behavior, attachments should still get
root attachments assigned when appropriate.
Change-Id: I866a81b6da81a744483fcadb2bff5b74d229619b
Reviewed-on: https://gerrit.instructure.com/13041
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Brian Palmer <brianp@instructure.com>
test plan:
* get some notifications for discussions, conversations, etc.
* delete the root account
* reply to the notifications via e-mail
* undelete the root account
* the replies should not show up
Change-Id: I2afe5de256cbd55ca360a4327150871ea40d7493
Reviewed-on: https://gerrit.instructure.com/12902
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
test plan:
* with a read-only slave environment
* create a new course
* go to the course
* it should not error
Change-Id: Ie0003cec2b684fca1400e6efbcca434a540d5c7a
Reviewed-on: https://gerrit.instructure.com/13032
Reviewed-by: Zach Wily <zach@instructure.com>
Tested-by: Cody Cutrer <cody@instructure.com>
test plan:
* visit several different courses
Change-Id: I19e8fbefba6164392269d6688df2c58d25e0f34b
Reviewed-on: https://gerrit.instructure.com/13027
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Brian Palmer <brianp@instructure.com>
* calendar events in the .ics feed
* searching for users in an account
* user's recent stream items
test plan: verify that these functions still work, both with and without
a slave db configured
Change-Id: Ia596d388642cc9df16e471472406d447a5eb1cf0
Reviewed-on: https://gerrit.instructure.com/13025
Reviewed-by: Zach Wily <zach@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Brian Palmer <brianp@instructure.com>
test plan: as a site admin, or another user who has no account
association but can view an account, visit an account that you aren't linked to.
you shouldn't see a page error.
Change-Id: Ib9544d188ff0e5cb3deb4753967fd69ab485b859
Reviewed-on: https://gerrit.instructure.com/13019
Reviewed-by: Bryan Madsen <bryan@instructure.com>
Tested-by: Brian Palmer <brianp@instructure.com>
fixes#9993; fixes#10034
we were caching the user's common account chain, but this was occasionally
caching all of the accounts loaded associations, which wasn't unmarshaling
properly.
the new strategy is to cache the global asset paths that should be used for
different contexts.
test plan:
- no visual changes in sub-account branding
- shouldn't generate any caching errors (these were intermittent and we never
had solid steps to reproduce)
Change-Id: I37cc58a609ed7f90d967d6ebde74e849c754c0e8
Reviewed-on: https://gerrit.instructure.com/13017
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#9995
also validates_as_url the redirect_uri, sometimes people were leaving
off the http:// part when setting up the key
test plan: set up a developer key with a given domain. kick off an oauth
request flow with redirect_uri equal to that domain, it should be
accepted. use a sub-domain of that domain, it should also be accepted.
use a higher-level domain, it should not be accepted.
Change-Id: I55510f463b1faa3339b9908f9941715d93de5a16
Reviewed-on: https://gerrit.instructure.com/12980
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
fixes#10007
when reordering content in a module, all the content has to be resaved with
its new position. each of these saves was touching the module, which could
cause a huge number of duplicate updates in a big module
test plan:
- reordering items in a module should have no visible changes
- tail the logs while reordering items
- you should only see one call of the form UPDATE "context_modules" SET
"updated_at" ...
Change-Id: I860c88dad3fd5fde63a2317dacf557acd02729ff
Reviewed-on: https://gerrit.instructure.com/12993
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#6347
* logs more information on ldap failures and passes it down to the browser in
the ajax response.
* fixes a crazy javascript bug where we were accidentally using a reserved
global var in webkit, 'status', which is a string, which interacted strangely
with our use of it as a boolean. this fixes the tester for firefox/ie
test plan:
(for #6347)
- use the tester in firefox and ie, it should work
(for error messages)
- one at a time, change the fields of a config, and run the tester
- you should get (slightly) more helpful error messages about what is failing,
based on status returned from the server.
Change-Id: Ic0837d7ff9f6283d615ddd4bbeef5a957dbd6553
Reviewed-on: https://gerrit.instructure.com/12880
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#9879
The profile nav link should only be shown when @domain_root_account has
profiles enabled.
Test plan:
* make sure caching is enabled
* go to to your user settings on an account with profiles enabled
- you should see a profile link in the sidebar
* switch to an account that doesn't have profiles
- you should no longer see the profile tab in the sidebar
Change-Id: If502829ef9d0bfa8117df82e241beb8cd61e03a9
Reviewed-on: https://gerrit.instructure.com/12935
Reviewed-by: Jon Jensen <jon@instructure.com>
Reviewed-by: Bryan Madsen <bryan@instructure.com>
Tested-by: Bryan Madsen <bryan@instructure.com>
fixes#9451
rack's request.scheme doesn't take x-forwarded-proto into account, so it
was returning http. Using request.protocol correctly handles ssl
termination, it just means we have to chop off the "://" part of the
protocol.
test plan: In an environment using ssl behind a load balancer, load the
avatar for a user that doesn't have one. verify that the gravatar
request redirects back to canvas using https, not http.
Change-Id: Ifb5f42e91379cfe591d29e07cd2ccf1f9d2b19fa
Reviewed-on: https://gerrit.instructure.com/12865
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
fixes#9872
on the course settings page, the 'end this course' button should not
display for courses whose terms have already ended.
test plan:
* create a course inside of a term whose end_at date has already
passed;
* visit the course settings page and verify that the 'end this course'
button is not visible in the sidebar.
Change-Id: I8f8ddc1cd495a3488fda6989de28d45abd67b6cd
Reviewed-on: https://gerrit.instructure.com/12893
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
disabling canvas auth also force-disables open registration, and
makes LDAP auth act like full delegated auth (CAS or SAML)
test plan:
* configure LDAP, CAS, or SAML. MAKE SURE YOU CAN LOG IN.
* go to account settings, and disable "Canvas Authentication"
* open registration should no longer show up on account settings
page (after saving)
* ensure you can no longer log in with your Canvas credentials, but
you can with LDAP, CAS, or SAML credentials.
* remove LDAP, CAS, or SAML from the account
* "Canvas Authentication" should no longer show up on the account
settings page, open registration should
* your Canvas credentials should start working again
* add LDAP, CAS, or SAML back
* "Canvas Authentication" should be back on in account settings
Change-Id: Ic7475623e5139bb545a87d8e5b1014dabaf4e854
Reviewed-on: https://gerrit.instructure.com/12850
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
test plan:
* enable optional MFA, and check the following:
* normal log in should not be affected
* you can enroll in MFA from your profile page
* you can re-enroll in MFA from your profile page
* you can disable MFA from your profile page
* MFA can be reset by an admin on your user page
* when enrolled, you are asked for verification code after
username/password when logging in
* you can't access any other part of the site directly until
until entering your verification code
* enable required MFA, and check the following
* when not enrolled in MFA, and you log in, you are forced to
enroll
* you cannot disable MFA from your profile page
* you can re-enroll in MFA from your profile page
* an admin (other than himself) can reset MFA from the user page
* for enrolling in MFA
* use Google Authenticator and scan the QR code; you should have
30-seconds or so of extra leeway to enter your code
* having no SMS communication channels on your profile, the
enrollment page should just have a form to add a new phone
* having one or more SMS communication channels on your profile,
the enrollment page should list them, or allow you to create
a new one (and switch back)
* having more than one SMS communication channel on your profile,
the enrollment page should remember which one you have selected
after you click "send"
* an unconfirmed SMS channel should go to confirmed when it's used
to enroll in MFA
* you should not be able to go directly to /login/otp to enroll
if you used "Remember me" token to log in
* MFA login flow
* if configured with SMS, it should send you an SMS after you
put in your username/password; you should have about 5 minutes
of leeway to put it in
* if you don't check "remember computer" checkbox, you should have
to enter a verification code each time you log in
* if you do check it, you shouldn't have to enter your code
anymore (for three days). it also shouldn't SMS you a
verification code each time you log in
* setting MFA to required for admins should make it required for
admins, optional for other users
* with MFA enabled, directly go to /login/otp after entering
username/password but before entering a verification code; it
should send you back to the main login page
* if you enrolled via SMS, you should not be able to remove that
SMS from your profile
* there should not be a reset MFA link on a user page if they
haven't enrolled
* test a login or required enrollment sequence with CAS and/or SAML
Change-Id: I692de7405bf7ca023183e717930ee940ccf0d5e6
Reviewed-on: https://gerrit.instructure.com/12700
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
make start tls the default if not otherwise specified in the API, and
the default for new integrations in the UI. still support booleans
in the API.
test plan:
* test non-tls, simple tls, and start tls LDAP servers
* ensure new LDAP settings default to start tls
Change-Id: I60b2f2d6cbdd32beff14d198c92efbfd6705b041
Reviewed-on: https://gerrit.instructure.com/12923
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Cody Cutrer <cody@instructure.com>
fixes#9966
refs #9901
there was a bug where policies for non-default channels were being considered
when deciding whether a default policy needed to be created, to show on the
communication preferences page.
also prevent an exception from being thrown when a user has no communication
channels, and visits the notification preferences page. We still need some
better UI here explaining why you can't do anything on the page.
test plan:
(for #9966)
- create a new user with an email, and setup some notification preferences
- add a new email address and retire the first one
- go to the notification preferences page
- you should have default preferences for the (new) default channel
(for #9901)
- as a user with no communication channels
- go to the notification preferences page
- it should not break
Change-Id: Iecd544571d6fece2a23c24b547ae434e8b57daae
Reviewed-on: https://gerrit.instructure.com/12952
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
This ensures that conferences on different shards won't accidentaly
share a voice bridge.
test plan: ensure that voice chat in Big Blue Button conferences still
works as expected.
Change-Id: I3e995943a33a2b18e6574c8f60f094e53f5a2753
Reviewed-on: https://gerrit.instructure.com/12945
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
fixes#9942
notifications is an unsharded table, so we can't join it again notification
policies. switch to include to get expected behavior
test plan:
- on a non-default shard
- change all of your notification frequencies
- they should stay changed.
Change-Id: Ife74a2124567381e3d1898f1d34ca09904d7376d
Reviewed-on: https://gerrit.instructure.com/12937
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
This adds an alternative method for uploading files by giving Canvas a
public URL in the first step, rather than uploading the file data directly.
test plan:
- create a course file via the API upload mechanism
- make sure the return values are as documented
- make sure the file was correctly uploaded
- create a course file via the URL approach
- make sure the return values are as documented
- make sure the file status endpoint returns valid responses
- make sure the file was correctly stored in Canvas
- repeat that process with a file that has at least one redirect
- repeat that process but creating a homework submission file
- try to create a course file with a malformed URL
- confirm that the appropriate error message is returned
- try to create a course file with a relative URL
- confirm that the appropriate error message is returned
- try to create a course file with a URL that doesn't return 200
- confirm that the appropriate error message is returned
Change-Id: I2dcf711347ec4ef26d767ae1c1fa0bb056986651
Reviewed-on: https://gerrit.instructure.com/12143
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
fixes#9873
The previous method for making this happen was just setting scribd_doc
to nil on the attachment before serializing it (wut?), but
Attachment#scribd_doc is overridden to return the root_attachment's
scribd_doc if there isn't one on this attachment.
The new strategy is to just use our filter_attributes_for_user stuff to
remove the secret info if the user doesn't have permission.
test plan: Upload a pdf or something, set it as locked, link to it from
a wiki page. As a student in that course, you shouldn't be able to
preview the document in-line. Then copy the course. In the new course,
you also shouldn't be able to preview the document in-line.
Change-Id: I66dc3a55a4e0371337846eb82179e6638a7d3852
Reviewed-on: https://gerrit.instructure.com/12921
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#8221
test plan: no user visible changes in behavior, so this is a regression
test. repeat this test plan once for s3 files and once for local
files:
* verify file uploads on /courses/X/files and /dashboard/files
* upload to other folders
* upload multiple files
* zip uploads
* weird characters in filenames, duplicate filenames
* verify other places we upload files like content imports and sis
imports
Change-Id: I01b7805eb947097b250bf9be944a9347ecc4ff5e
when users sign up via open registration, they can use canvas before
confirming their email address (and setting a password). since we show
a "Configure Communication Preferences" button, it makes sense to let them
actually do it (instead of getting a big scary warning). notifications
won't actually be sent until the communication channel gets confirmed, so
we warn them about that.
test plan:
1. sign up as a teacher via /register
2. when you get to the dashboard, click the "Configure Communication
Preferences" button
3. you should see notification preferences
4. you should be able to update them
5. you should see a reminder to confirm your email
6. the "re-send email" link in the reminder should work
Change-Id: I585a69b8667ef82eb2e4c3005179bc14377e467b
Reviewed-on: https://gerrit.instructure.com/12911
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Ryan Shaw <ryan@instructure.com>
store whether the new user is a teacher/student/observer (if specified)
test plan:
1. sign up as a teacher/student/observer
2. it should work
3. the user record should have the correct initial_enrollment_type
Change-Id: I6200d677f2da946b05d6f90c89617b3476ed390b
Reviewed-on: https://gerrit.instructure.com/12873
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
fixes#8377
preventing student view enrollments from being inactive allows the fake student
to view/use the course as a regular student would before the term starts.
test plan:
- in a course in a term that hasn't strated yet
- enter student view
- you should be able to post to discussions
Change-Id: I31e92fc654b7dd9c79872714f26daef35ac3ec49
Reviewed-on: https://gerrit.instructure.com/12839
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
test plan:
- consult the Pages documentation; ensure it renders properly.
- exercise the following endpoints:
- GET /api/v1/courses/:course_id/pages
- GET /api/v1/courses/:course_id/pages/:url
- GET /api/v1/groups/:group_id/pages
- GET /api/v1/groups/:group_id/pages/:url
- verify students can't see hidden pages
- verify permissions are respected
Change-Id: I2911e42a3c276301a0170917871c6648aded4a79
Reviewed-on: https://gerrit.instructure.com/12838
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
fixes#9829
users without any enrollments weren't included in
User.messageable_users, but messaging yourself should always be allowed.
Test plan:
* log in as a user without any enrollments
- Go to your inbox. You should be able to message yourself by
searching for your name.
OR
- Go to your profile page on an account with profiles enabled. You
should be able to see your profile.
Change-Id: If5182d807fe2f3150999d442d30202c22dffa4d1
Reviewed-on: https://gerrit.instructure.com/12819
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
test plan
* create quiz statistics_csv for anonymous survey
* results should not include user information
Change-Id: I1c7c9047fde337b7af0ae8f7bae6f0abb70a76e3
Reviewed-on: https://gerrit.instructure.com/12822
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Cody Cutrer <cody@instructure.com>
The user was getting marshalled when caching the profile tabs.
Test plan:
* Go to your profile page on an account with profiles enabled
* The profile tab should still work
Change-Id: I60b4882859396fd3e9cc63416b75ae831f7fe4f0
Reviewed-on: https://gerrit.instructure.com/12804
Reviewed-by: Brian Palmer <brianp@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#9634
test plan:
* saml should still work
* some problematic SAML IDPs (e.g., shibboleth) should now work
Change-Id: Ie4307d0bc5490af5117055b0b342f5b4e3266984
Reviewed-on: https://gerrit.instructure.com/12731
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
fixes#9768
test plan:
* create two accounts via SIS that reference each other (you'll need
to add the first account two times, once valid, the second changing
its parent to the other account)
* one of the accounts should cause a warning about a loop
Change-Id: Ieb1710a1d0b7d11c652d8e000dcf33b63d2b187f
Reviewed-on: https://gerrit.instructure.com/12749
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Adds an infrastructure for using statsd (configured with
config/statsd.yml) and uses it to track a few basic stats. Stat names
are appended with the hostname.
test plan: without statsd enabled, make sure no errors are raised when
doing requests. add a statsd.yml configuration, restart the server, and
verify that stats are sent over UDP to the given host/port (this could
even be checked without statsd available, by monitoring UDP traffic)
Change-Id: Ie8c3ece7e08ff48616ffd968069bd760300e4fd2
Reviewed-on: https://gerrit.instructure.com/12673
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Simon Williams <simon@instructure.com>
Test plan:
* Go to a group's page
* There should not be a 'Settings' link in the sidebar
* Appending /edit to the URL should result in a 404
Change-Id: I7c2115f6c42d420c306aa312d2c7ec319d08b115
Reviewed-on: https://gerrit.instructure.com/12747
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
allow teachers/admins to link observers to students in courses that have
not yet been published
test plan:
1. create a course, but don't publish it
2. add a student
3. add an observer
4. confirm that you can link the observer to the student
Change-Id: I48871d569533afc355db39ff52849a2c4b8b6a49
Reviewed-on: https://gerrit.instructure.com/12739
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Zach Wily <zach@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
fix issues in the new course roster management UI around admins who are
not enrolled in the course. specifically, we now:
1. show admins the sections the users are enrolled in
2. allow admins to manage the sections users are enrolled in
3. allow admins to re-send invitations
4. allow admins to add students to an observer
test plan:
1. as an account admin, go to the course settings page for a course you
are not enrolled in
2. confirm that you see the section(s) that each user is enrolled in
(below the email address)
3. confirm that you can add/remove users' enrollments in particular
sections
4. confirm that you can re-send invitations (both for those that have and
haven't accepted)
5. confirm that you can add/remove students to/from an observer
6. as a general regression test, perform steps 2-5 for a teacher that is
enrolled in the course
Change-Id: I3c67896e941000689860b8c0924df33bdd48f921
Reviewed-on: https://gerrit.instructure.com/12738
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
When a new user visits /profile/communication, load the
system defaults for frequency settings.
Test Plan
=======
* Create a new user and visit /profile/communication.
Verify that there are default settings loaded.
* Verify that after adding a new communication channel
that defaults are not applied.
* Verify that changing a setting and reloading
preserves the user-selected value and is not
overriden by a default.
Change-Id: I9d87b316510fd08bdf40380e05b327bed7e0e95c
Reviewed-on: https://gerrit.instructure.com/12720
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#9669, fixes#9713
Test plan:
* for #9669
- Go to the users tab of the settings page for a course
- Add a unexisting user to the course
- Add an observer to the course (if there isn't one)
- Open the link student dialog (still on user settings page)
- Search for the previously added student - the student should show up
* for #9713
- In a course with some student groups defined, go again to the users tab
- Open the edit sections dialog for a student
- click the button on the right of the input, no student groups should show up
- search for a group, none should show up
Change-Id: Iacc6aa9be109983fd53520bc547a62cb9482be89
Reviewed-on: https://gerrit.instructure.com/12702
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Previously, the rewritten Notification's page was deleting any
entries set to "never". However, some entries and code revert to the default behavior if no setting is recorded. This just makes each "never" setting be explicitly stored if set by the user.
Testing Plan:
============
* As a student set all notifications to "Do not send me anything"
* As a teacher create a new conference
* As a teacher go to Calendar -> Scheduler -> and create an appointment group
* Check the notification messages for the student
* Ensure that the student does not receive a notification message. (/users/x/messages)
Change-Id: Idbe4ad0d8b0394217787b5684161ab5987123e60
Reviewed-on: https://gerrit.instructure.com/12706
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
change the the list of recently logged in users to be loaded
asynchronously and paginated via the api.
test plan:
- navigate to /courses/:course_id/statistics;
- click on the 'Students' tab;
- verify that the most recent students have
loaded;
- in a course with > 25 users who have logged in, and some of
whom have multiple pseudonyms, view the same page
- verify that while scrolling, more students are loaded automatically
in until all the students in the course are present in the list.
Change-Id: I10ea92e0a286ce117ec0e957a91c8c347b89e751
Reviewed-on: https://gerrit.instructure.com/8404
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
fixes#9700
filter sensitive information from the data that is saved for an error report.
also add a few extra fields to the view, such as request_context_id and form
parameters.
test plan:
- make an action with the api that will cause an error report to be generated
- go view that error report
- it should have your access token filtered out
- it should have a request context id field
Change-Id: I3c4d0d8002b6f502fdeb9e4dd40f3fd5d51dc04d
Reviewed-on: https://gerrit.instructure.com/12625
Reviewed-by: Simon Williams <simon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#9722
it should indicate that it is for changes to course pages
and assignments.
test plan:
- go to profile > notifications and hover over the "Course
content" text
- it should say "for changes to course pages and assignments"
Change-Id: I52de267b00787d475c83e66c1143ad0de8ea3000
Reviewed-on: https://gerrit.instructure.com/12688
Reviewed-by: Cody Cutrer <cody@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#9724
test plan
* take a quiz
* download quiz statistics
* csv should have sis_id and section info for each student
Change-Id: I1e207987771e07eae78b0e2e7422b3c88cad13ca
Reviewed-on: https://gerrit.instructure.com/12681
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jeremy Stanley <jeremy@instructure.com>
fixes#8181
users with :view_all_grades permissions were able to see
gradebook1, but not gradebook2. this change gives them permission
to load the page as well as permissions to make the api calls
necessary to get all of the gradebook2 page data.
test plan:
* create a new account-level role with only permissions to
view all grades;
* navigate to an existing course's gradebook;
* verify that the page loads and data displays as expected.
Change-Id: I9e5f01e889126eb6675095bafe5510be5045009e
Reviewed-on: https://gerrit.instructure.com/12555
Reviewed-by: Jon Jensen <jon@instructure.com>
Tested-by: Jenkins <jenkins@instructure.com>
fixes#7435
previously the assignment_groups api was returning weights for
assignment groups, even when the parent context wasn't using
those weights.
now we return null for weights unless the context is currently
weighing the assignments by group.
test plan:
* create a course with two assignment groups that have values
for group_weight;
* set the course's group_weighting_scheme to 'equal';
* make an api call to AssignmentGroups#index and verify that
group_weight returns as null;
* set the course's group_weighting_scheme to 'percent';
* make another api call and verify that group_weights are
properly displayed.
Change-Id: I27f86e6f7fff13fa4d1e8d9c985cd06371cf7bd9
Reviewed-on: https://gerrit.instructure.com/12523
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Brian Palmer <brianp@instructure.com>
Refs #8066, refs #9643.
Fix notification problem where making a 'category' frequency change
did not change the settings for all the notification events in the category.
Changed notification check box text per product's request.
Added new unit-test spec for updating multiple notification settings
for the same shared category.
Testing notes:
==============
Multiple Notifications in the same category should be updated when
the category displayed is changed. For instance, "Due Date" has
two notifications in that category.
One is "Assignment Due Date Changed" and the other is "Assignment Created".
There are two different ways to verify this. One is more technical but
easier to verify. The other is all UI driven but more complicated.
Technical Approach
------------------
* Find all notification IDs in the category "Due Date":
id_list = Notification.find_all_by_category('Due Date').map(&:id)
* Find the CommunicationChannel for a given email address:
channel = CommunicationChannel.find_by_path_and_path_type('jimbo@instructure.com', 'email')
* Find the NotificationPolicy entries for the category and channel:
channel.notification_policies.scoped(:conditions => {:notification_id => id_list}).all
* Make a change to "/profile/communication" settings for "Due Date".
* Re-run the last query for listing the 2 NotificationPolicy entries. They should
both be updated to have the new frequency.
Non-Technical Approach
----------------------
* Make a change to trigger each event in the "Due Date" group. (listed above in Testing Notes).
* Verify that changing "Due Date" to a setting like "Daily" and triggering
the event that the notification is done as "Daily".
* Change the category frequency to something like "ASAP" and trigger the two events
in the category and verify that both are respected as "Immediate/ASAP".
Change-Id: I9e0473c92206b2ec43ba1c1a6a0ec4c62cdae115
Reviewed-on: https://gerrit.instructure.com/12562
Tested-by: Jenkins <jenkins@instructure.com>
Reviewed-by: Jon Jensen <jon@instructure.com>
Cody Cutrer